Jeff Eaton: Content Modeling – Episode 100

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS

Jeff Eaton looks at content modeling two ways, both the traditional boxes-and-arrows way and the title-case Content Modeling way.

Thinking about how you’ll structure and organize your content will always be important.

But the real power of content modeling emerges when it rises to a higher level and accounts for the shared understanding the people across your organization have of your content. Jeff calls this more sophisticated approach “The Content Model.”

We talked about:

• his work with Karen McGrane and Ethan Marcotte at Autogram
• his definitions of content modeling: 1) a relatively simple boxes and arrows approach and 2) The Content Model, a higher-level, big-picture look at your content and the shared understanding of it in your organization
• “what we talk about when we talk about content modeling”
• the truth behind the old joke that “the real content model is the friends we made along the way”
• the inevitability of spreadsheets in content modeling work
• some of the benefits of content modeling:
  • communicating consistently across different teams
  • getting clarity around how to structure content for various end uses
• how taxonomy and ontology practices can help bring order out of chaos
• the lack of agreement among content modelers about standards in modeling terminology
• the importance of stepping back and thinking about what you want your content modeling to do for you

Jeff’s bio

Jeff helps large organizations understand, model, and manage their content. Whether he’s fixing problems with CMS architecture or editorial workflow, his solutions sit in the overlap between design, communications, and technology.

Jeff’s website is eaton.fyi. He can also be found online at Twitter and LinkedIn.

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 100. You can look at any organization’s content through two lenses: either as a fairly simple body of work which you can contain in boxes and connect with arrows, or as a complex and nuanced ecosystem that shows the shared understanding of your content across your organization. Jeff Eaton finds value in both approaches to content modeling, but his most impactful work always includes a rigorous and robust accounting of the systems that drive the content.

Interview transcript

Larry:
Hi, everyone. Welcome to episode number 100 of the Content Strategy Insights Podcast. I’m really happy today to have with us Jeff Eaton. Jeff is a partner at Autogram, the legendary new digital agency along with Ethan Marcotte and Karen McGrane. But welcome Jeff, tell the folks a little bit more about what you’re up to at Autogram.

Jeff:
Well, it’s a pleasure to be here, especially for the monumental 100th episode, the entry into triple digits. So at Autogram, we’re basically a consultancy agency. We focus on organizations that are building and maintaining complex content systems, communications oriented systems, and are facing challenges both with their governance models, how to transition from a rigid template-oriented approach to a more fluid compositional approach, and how to grapple with questions like transitions to decoupled and headless approaches and omni-channel and multi-channel stuff, and the role of design systems and what they’re doing, that cluster of interrelated concerns is something that we’ve found as very rarely being dealt with holistically. But you start talking on one of them and yeah, the sweater starts unraveling and you find out that they’re all related.

Larry:
No, the way you just said that and it’s not like they’re buzzwords, those are actual things happening in the discipline . . . to handle content, right? Yeah. We were talking before we went on the air and we were getting a little worried, this could go forever, but today we’re going to focus this part of the conversation on content modeling. Because I think that’s such an important… That’s one of the undergirding practices of this approach that you all are taking there that helps you actually accomplish this with your clients. Tell me a little bit. Tell me about, how do you define content modeling? I know that’s a big one, but how do you define it? And, yeah. And we’ll take it from there.

Jeff:
So I like to say that there’s sort of two ways that you can define content modeling. There’s the very simple reductive definition which I would say is, identifying and standardizing the types of different content you are publishing, what their purpose is, and how they differ from each other, what properties they have. Like what bits of data actually live on a podcast versus a product sheet versus an event or something like that and then the relationships that connect them. Having defined all those free-floating things, how does an event connect to a product or to our podcast? Do we see there being inherent between them either in how we define them or how we use them? That’s the simple scenario. And I think a lot of people, we can imagine sort of the boxes and arrows, diagram of your company’s content model.

Jeff:
And it maps very, very nicely to that sort of way of thinking. You’ve got your things, you’ve got their properties, and you’ve got the arrows that talk about how they relate to each other. But more broadly, I think of The Content Model in title case as the big picture of your content and the purposes that it’s being used for, and the shared understanding that all of your different teams have about that content. None of the individual artifacts that we end up creating during that content modeling process are the perfect canonical version of quote, “the content model.”” That boxes and arrows diagram that we talked about is only a very thin like view of it. It’s good for conveying certain things, but if you start talking about, oh, well, what are the rules that govern that is a headline, is it always text?

Jeff:
Do we allow certain kinds of formatting in there? What things are allowed to be images versus a reference to a DAM asset or something like that. There’s all of these squirrely ripple-effect questions that you find yourself asking, well, is that the content model or is that the data model or does it matter? And ultimately, I think that whether you’ve got a giant spreadsheet in which with a sheet for every type of content and a row for every property, or you’ve got diagrams, or you’ve got heavily annotated wire frames, or you’ve got like UML that captures all kinds of stuff, regardless of what artifacts you’re generating in order to communicate about that stuff, the content model, what we talk about when we talk about content modeling is the shared understanding that all of the teams have, so that when an important question gets asked or an important decision has to be made, the judgment calls and the understandings that they have are compatible with each other.

Jeff:
So that when the development team says, oh, we’ve got to expose this in JSON for a Swift application that someone’s writing to run on a watch, the judgment calls they make in that process are compatible with the ones that the front-end development team is making when the React components are being built or something like that, or the editorial team is making when they ask for tweaks and customizations to the CMS so that their workflow is improved. It’s less about everyone has a single magical choke point that every idea passes through and more about what does everyone need to understand? What does everyone need to be on the same page about in order for those questions to be answered consistently? And for everyone’s understanding to be compatible for the work that’s being done, which obviously turns it into a very fuzzy and very open-ended kind of thing. But that tension between the big-picture world of content modeling and the reductive, we need to make a diagram of our content types, I think a lot of the confusion about it lies in that tension.

Larry:
I love that you brought this up early, usually somewhere in the episodes, usually towards the end of the interview, it’ll come up with like, “Yeah. Content strategy, it’s always about people and communication.” And you put it right at the front, so thanks for doing that.

Jeff:
The real content model is the friends we made along the way.

Larry:
Oh, I forgot that. That’s one of your most famous tweets and it’s-

Jeff:
I think Kristina Halvorson has said that a couple of times too. And I know a couple of folks who’ve made that joke and it’s sort of a joke, but it really is true because it’s almost impossible to keep all of the different artifacts in organization perfectly in sync, and a lot of them are just different ways of looking at the sort of underlying shared understanding that we have.

Larry:
Yeah. That’s really interesting to me too because that makes a thousand percent sense that like that title case content model where you… So how does that manifest in practice? How do you… It’s easy and it seems not easy enough. No, but I mean, it seems it’s like simpler enough early on in these initial-

Jeff:
How does that translate to some deliverables?

Larry:
Exactly. No I’m talking like a… Sorry. I’m like one of those mean executives now.

Jeff:
No, no, no. I think it’s a really important question because there’s value in that expansive definition because I think it helps us step back and realize how much we can miss if we’re just always focused on like, well, we’ve got to produce that particular document that we always know we’re going to bang out. And it helps us step back and see the bigger world that they live in and identify questions that we may not be asking or not addressing, but also once we step back and zoom out like that, it can become a lot fuzzier and more difficult for anyone involved to say, okay, so what are we going to have at the end of this? How will we know we all have this shared understanding other than everybody just feels like we kind of get it more?

Jeff:
And I think that the process still generates a lot of those artifacts. There’s no way you’re going to get around, some wireframes have to be put together. And you have to explain to people, yeah, these 10 bits of content that you have, this is how they’re going to get used, this is how they’re going to get shown to people and in a couple of different contexts, or you’re never going to avoid having a giant spreadsheet somewhere. Someone out there may have managed to do a large digital project without a giant spreadsheet full of content types, but I’ve yet to meet them.

Larry:
Well, on that, let me ask you-

Jeff:
But I would say one big thing is that it’s helped us focus on very early on in the process zeroing in on, what are the really important questions that you are not confident your different teams can answer consistently. That idea of the consistent answers, teasing out those differences of perspective or the misunderstandings about what team A means when they say X and what team B means. That stuff is one of the earliest challenges that informs what kind of artifacts are going to be most useful and what kinds of things are going to be most effective. Because if it’s so patently obvious that everyone on the team already knows the answer and already has the same answer, that’s great, but usually it’s teasing out those collision points or those friction points where you really find where a lot of value in the modeling process is going to be.

Larry:
Right. Does this get into governance? Those collisions and things often you need something, right?

Jeff:
It absolutely does. I mean, and that’s why that expansive definition of content modeling is, I think, it eats every other practice. The running joke is that any discipline eventually figures out a way to define itself such that all other disciplines are part of it. And I’m cognizant of that problem, but at the very least, I would say that the title case Content Modeling is at least the stuff you need to be concerned about and the stuff you need to think about when trying to produce a content model or document a content model.

Larry:
Yeah. Thanks. And I would love to continue down that road, but I also want to get back to just the sort of the practical benefits of modeling. There are so many good reasons to do it. And I think it’s becoming more important. You mentioned headless and decoupled, kind of the arrival of that. That seems to be one of the drivers, but can you talk a little bit about… We talked about this sort of the highest level implementation kind of deliverables about this, but getting down into the weeds just a little bit deeper about the sort of technical and procedural benefits of modeling and how you make that happen.

Jeff:
So this is actually an example I just walked through in a fair amount of detail, so it’s fresh in my mind but… Well, so I guess, what are the values of thinking about it as like, we can answer questions consistently across different teams. One of the values of that answer to what are we trying to accomplish with the content modeling is that, most of the time when people are experiencing real pain around their content, some of it’s due to, hey, our systems are old and they can’t do X and Y and Z, but often it’s about continuing ongoing collisions between different teams not being on the same page about what’s expected, or what needs to be built, or how something will need to be used, or what should be put in a particular field, or things like that.

Jeff:
And the seven buckets down the bucket brigade line, things break because of that kind of confusion. And focusing on this idea of, where are these disconnects happening? What do we need to dig into to get everyone on the same page and understanding each other, and talking about the same things in compatible ways that immediately connects it to a lot of the felt problems that we ended up seeing with a lot of our clients. But like at a very concrete level, where’s the modeling stuff come in? We just relaunched is a, it’s very tiny example, but we just relaunched the Autogram site a couple of months ago. Ethan Marcotte did a new design and very exciting stuff. And one of the things that we wanted to do is we had press clippings and articles and stuff like that, that we wanted to weave into sort of a newsfeed, but we wanted it to feel a little more conversational. Less like, here’s a link list, and more chatty, I guess.

Jeff:
So we, in our initial designs, had this sort of nice, Karen and Ethan appeared at this event and talked about blah, blah, blah, and here’s a link to it. But it was all structured content. We had links with a venue and title of the event and stuff like that. And it was all really nice. We had these little structured bits of data that we could pipe into these templates and the minute we actually tried to roll it out live, none of it worked. I mean, it all displayed in the templates correctly, but it was literally just grammatically incorrect. And we started realizing, okay, we’ve painted ourselves into a corner here where we’ve come up with an idea that it’s very easy to articulate and design and store all the perfect bits of data, but breaking down like a press mention, or an appearance, or something like that into structured data is a lot easier than figuring out the complexity of how to reassemble it correctly in all of the different possible ways.

Jeff:
Even things like the join words that need to be placed between the list of people who are involved and the thing that was created, because you’re a guest on a podcast, but at an event and stuff like that. So suddenly we see there was this ripple effect of metadata that we needed to capture about what kind of venue is this? What sort of thing is this? Just so that we could generate a little sentence of text that said, Jeff appeared on Larry’s podcast. And it was very rewarding. It was a lot of fun from a deeply nerdy perspective, but it made it obvious that even just breaking it up into pieces and saying, “Ta-da, we have structure now” wasn’t sufficient, because that was sort of a neutral, platonic form of the structure and we needed to capture more of the actual meaning around, well, what do we mean by this field? What should be going in there?

Jeff:
Is if we’re going to be using it in these five different ways, what other invisible information do we need so that we can inform all of the stuff that we thought could be just done automatically, but we’ve got all these decisions around. And content modeling, it’s the process of teasing those things out, not just looking at, say an article or a landing page or something like that, and drawing boxes around stuff and saying, okay, here’s how we’re going to chop it up. When you start looking at things like multichannel and omnichannel use of content, or trying to tackle the question of effective content reuse in different contexts and stuff like that, understanding like… You know me, I love language metaphors here, but not just the vocabulary of pieces that we have to build our content out of, but the grammar that binds them together, what things can go together and what things make sense together. And if we change how they relate to each other, how does the meaning get altered in the final content that we’re creating?

Jeff:
That’s the meaty stuff that I think if you can start teasing that out and start communicating about those things, even beyond just the technical details of, what boxes are we going to have what data in, it can make a huge difference.

Larry:
I love that. That we’re inventing a new grammar with contemporary content modeling practice. But it completely makes sense because we’ve kind of gone from this era of… Like if you do a… I’m doing this all the time, because I’m talking a lot about modeling. And when you do searches, you often come across these balsa wood planes and cars or clay cars, and it’s like that’s one way of modeling. Is like, you take an exacto knife and you carve something out.

Jeff:
Yeah.

Larry:
But this is more like sitting down with a big old pile of Legos and stacking things up in different ways until it looks right.

Jeff:
I think the Lego analogy is a perfect example. Because the you’ve got all these bricks, but the system of interconnections between them is where the magic lives in that.

Larry:
Yeah. So we talked a little bit, but I think the concept of metadata has come up but we also talked before we went on the air about, like I’ve had it in my mind that there’s clean line between structuring content and associating metadata with it. And you’re like, “oh, you naive man, here’s the what’s actually going on. Talk more about that.

Jeff:
So, there’s like the practice of taxonomy and ontology, or systems of organizing things. Like, we’ve got all this stuff, how will we categorize it and create order out of the chaos. And I think there’s a certain extent to which that can be pursued sort of as its own parallel effort to the creation and authoring and structuring of the content itself. But in real world application of content, the lines get fuzzier because things like, is content type a property of the piece of content, or is it a taxonomy that you use to organize? Like, where is the boundary line between the taxonomy about, and the properties of. And many, many years back, Karen McGrane and I, one of our earliest conversations, she sort of blew my mind when I was talking about some technical distinctions that meant we could or couldn’t filter and sort based on certain properties.

Jeff:
And I said, oh, well, those are taxonomy, so we can do that with them. But these are just some properties of our content. And she shook her head sadly and she’s like, “If you use it to organize your content, it’s taxonomy.” It’s like, no matter what you think of it when you’re designing the set of items or the labels, if you’re using it in that way, functionally it is doing the work of taxonomy. And I think that fuzziness is what’s interesting.

Larry:
Yeah. No, I love… And human beings are just natively fuzzy and doing all this stuff in a way that honors our humanity and the content, but lets machines do it. It’s never going to be super tidy, I mean, I guess. Right?

Jeff:
You know me, I love me the language metaphors, but one of the horror stories I just heard last week from one of the hosts of the Lingthusiasm podcast about linguistics is, the case of the long hundred. As it turns out, prior to about the 14th century or so, the word hundred in a bunch of Germanic languages meant what we would now call 120. So saying a hundred, meant 120, and 200 meant 240, which hilariously also meant that 500 meant 600. And it was really the popularization of Arabic numerals and the fact that they’re base 10 consistently from end to end, but you can’t really… It’s base 10 full stop. That was really what sort of crushed the popularity of what’s now known as the long hundred, but there was a window of time where it was a complicated question what 500 meant.

Larry:
Well. Hey, this brings up another question I wanted to ask you about now, this is a good place to begin. You mentioned earlier, like universal modeling language that programmers use to tidy things up, and now you’re talking about this standardization of like, well, what does a hundred mean? Is there anything like a universal content modeling language or other kinds of standards or guidance around like… I think for example about like, what do you call the smallest thing in your CMS? What do you call the smallest assembly? What do you call different content types? Is there any agreement among modelers about…

Jeff:
I don’t think so. I mean, I’ve heard lots of ideas proposed in the grand tradition of standards, the best solution to competing standards is to make yet another one. That’s a problem that is… It’s not exclusive to content modeling either, the design system world wrestles with the very same problem. There’s certain popular nomenclatures, like Brad Frost’s Atomic Design, there’s atoms and there’s molecules and stuff like that. But even Brad has said, that’s a helpful metaphor because explaining the idea of component systems, not the language to articulate that stuff. And I think that’s one of the challenges, is that how different organizations, what content they’re dealing with and how it interacts with their domain model and how they are trying to assemble and utilize these things has a dramatic impact on things like what is the smallest unit and what is the way that they connect to each other and stuff like that.

Jeff:
So I think the better we get at finding the patterns that are common, I think we’ll be able to do that as an industry. But I think to a certain extent, there’s always going to be variation from project to project in the same way that like, there are common features among languages, but that doesn’t necessarily mean that like the word for horse is the same across every human language.

Larry:
Now I’m re-conceptualizing a lot of this as like literary genres or something like, oh, that’s just how you do a romance novel, and that’s how you do detective fiction.

Jeff:
Yeah. They’re like genres of content more than there is a fixed specific model for a particular kind.

Larry:
Yeah. Now this is great. God, I could keep going forever, but I can’t believe this Jeff … We’re already coming up close to time, but I always like to give my guests a chance, is there anything less, anything that’s come up today or just on your mind that you want to share with the folks before we wrap up?

Jeff:
I think I would probably say that the biggest thing that stands out for me these days is, again, that that intersection of decoupled and headless delivery systems for content and structured component oriented like conceptualization of your content, like what are the things and how do we… What are the canonical forms that we have and what makes them up? And then the design systems side, the more you can step back and think about what job you want the structure to do for you and what you’re hoping to accomplish with it, and treat the structure as a way you’re accomplishing those jobs, rather than some sort of a big slider with a purity level indicator like, “Well, we’re sort of structured, but not as much as we ought to be.”

Jeff:
It’s like, if it’s accomplishing what you need your structure to do, then you are well-structured, if not, then you need to think about it. You can have the most incredibly granular and semantically precise model and storage mechanism, but if the way that it’s been built and the way that it’s been conceptualized, it doesn’t meet the organizational and the usage needs that you have, more structure doesn’t mean right structure.

Larry:
Got it. That circles right back that thing you said early on about the shared understanding.

Jeff:
Yeah.

Larry:
And yeah, I think it gets to the point of like, this process of modeling helps you do that. There’s like you have a language around this and ways to agree on that.

Jeff:
Yeah.

Larry:
Well, thanks so much, Jeff. This has been great. Oh, one very last thing, what’s the best way for folks to stay in touch if they want to follow you on social media or just get in touch with Autogram?

Jeff:
Well, I’m @eaton, E-A-T-O-N, on Twitter. And I’m always sounding off on a variety of topics. But you can also check out our website at Autogram.is. Autogram is. And we’ve got… I guess we’re semi-frequently updating it with links and conversations about some of these topics. But yeah, it’s usually either Twitter or the Autogram site. Those are both great places to find what’s going on.

Larry:
Great. And I’ll put those in the show notes as well. Well, thanks so much, Jeff, I really had fun talking to you.

Jeff:
Always a pleasure. Thank you.