Episode 11: Model Your Content (w/ Jeff Eaton)

Hello, this is the Web Project Guide podcast. And this is Episode 11, Model Your Content. I'm Corey Vilhauer, director of strategy at Blend Interactive and co-author of the Web Project Guide. Later on, we'll talk to Jeff Eaton, digital strategist and a partner at Autogram and general content modeling expert. But first I'm joined by the other web project guide co-model Deane Barker.

Co-model. Co-spokes model or something that starts it.

No, you're a co-model. You are Senior Director of Content Management Research at Optimizely. Hey Deane.

I am. Hi, Corey. I am so excited about this episode because Jeff Eaton is a long-time friend and Jeff knows content modeling in-and-out and likes to geek out on it to the same extent that I do.

I have a real quick question for you before we get into it, Deane.

Hit me.

When is the first time that you discovered that you really enjoyed, or were sort of in love with the idea of content modeling?

Yeah, probably something like my mother was a secretary her entire life. She hated the term administrative assistant, she literally went to secretarial college. She was the most organized person I've ever known. And so I inherited my love of organizing, I think, from her. But I always look at content modeling as mastery of information. If you look at a large book, like the one we wrote for instance, a lot of information in there, but I love the idea that there's a hidden structure behind it. You can peel back the curtain and there are different pieces that makes sense. And you can take it apart like a little machine and put it back together another way. I love the idea of structuring content. And some of the things we get into with Jeff during the interview, is how do you avoid doing that too much, hammer the soul out of the content. It's the hidden language of information, it's the language of content and I enjoy it for that reason.

Yeah. I was a kid who was a kid but I was college I guess, but I was the person who needed to make sure that every field and element of my iTunes had the right names, had the right spellings. I had to group everything. I hated-

Album covers.

Album covers, everything had an album cover. I would enter in the times of the songs if I needed to. This was definitely during the day in which most of that stuff was secured illegally through Napster. And it was just the Wild West of organizing in fields and you've got artists named something else and that's when I was, I wish I could do this for a job. And it turns out I ended up doing that somehow.

How are you?

This is going to be my favorite interview with you.

Well, let's get into it. Jeff Eaton is a digital strategist and partner at Autogram. Autogram is focused on the intersection of content architecture, design systems, and governance in large organizations. But first this episode of the Web Project Guide is brought to you as always by Blend Interactive. Blend interactive is a web strategy design and development firm, dedicated to building great websites. Blend's been guiding teams through complicated web projects for 17 years and we are always looking for our next big project, so visit us at blendinteractive.com.

(03:23)
All right, let's welcome our guest Jeff Eaton. Hi Jeff.

Hi. It's a pleasure to be here. I mean, I think this is probably conversation number six million that the three of us, or some combination of us, have had about this stuff, but I think this is the first time we've all been here for a podcast conversation and I'm really excited about it.

It's going to be really good. Go ahead, Deane. Deane's going to ask you so many questions that go off topic that I'm going to try to reign him in.

No, I just want to say that this is Jeff returning the favor. I've been on his podcast twice when you were at Lullabot.

Yep.

And then Jeff and I go way back to a dinner in New York between me, Scott Le Roy Karen McGrane, and Jeff.

That's right.

At the end of the dinner, I ordered a dessert called the chocolate box, not knowing what it was, and it was literally a box made of chocolate.

I recall. I mean once it arrived, it seemed obvious.

It's like that scene from Arrested Development where says dead pigeon on a bag. I don't know what I expected, but yes, Karen and I ate the chocolate box and it was delicious. And then Jeff, you and I got together somewhere in Chicago, downtown Chicago once. And we had dinner way out in Oakbrook Terrace. Cause you live way out in the burbs and Jeff, you and I share absurdly irrational passions for modeling content.

And the general world of CMS nerding. I like to think of it. It's rich territory for a conversation and spreadsheets and nerding. And I mean, you can't see it on the podcast, but I'm actually wearing my, I hope you like spreadsheets t-shirt.

Excellent shirt.

I use the spreadsheet metaphor all the time to explain.

Oh yeah, everybody has worked with spreadsheets at some point. So it's easy to sort grab an anchor.

Your types are your worksheets, your rows are your objects, and your columns are your properties or your fields.

Jeff, I use your definition of a content model in almost every situation in which I have to define what a content model is.

Oh man. Which one? Cause I'm pretty sure that I've given nine.

Well, what's your favorite one?

So I like to think that there's sort of two ways of talking about a content model. One is the baseline definition is it's "A content model defines what kinds of things you are going to be publishing, what they are and what they're for, and then what pieces make up those things and how they connect to each other. The things, what those things are made of and then how they relate to each other." That's the baseline. And that could be very high level. It could be a napkin with a couple of boxes on it with article and landing page and category page sketched on it. And some arrows connecting them and at a very base level, that's a content model. And the purpose of that is so that everyone gets what it is we're all working on and what that means and what that requires.

(06:44)
When we say article, we mean a thing that's created for this purpose. It is meant to be used in this context and it's always going to have X and Y and Z. And if it has A and B, they're going to be this much text or a photo or a link to another article or something like that. Ironing out those details of when we say this type of content, we mean this. That's really the heart of it. The problem is that getting there and getting to that shared consistent understanding often means particularly in larger projects or organizations, where there are multiple teams involved in producing the stuff, it means figuring out how to articulate the boundary lines and the similarities between lots of different organizations.

(07:39)
A word can be completely appropriately used in very different ways, by three different teams. Like the concept of a customer in internal support documentation for a web project or for a web product, a customer might be people who subscribe to that web product. The reader is a customer, but they might be dealing with their own customers. Like the person who is the customer of your product might be using it to engage with their customers. So now you have two radically different meanings for this same word, and you've got to figure out how you're going to do that. It's not that you need to find the correct and proper one. You need to figure out how are we going to navigate these collisions? How are we going to negotiate a shared language so that things make sense.

That's a great definition. I teach content modeling at the university level and that makes my spreadsheet analogy seem a little silly.

Well, but realistically a spreadsheet is where most people actually interact with a content model. Like those artifacts, we've got a diagram, we've got a spreadsheet, we've got a copy deck for the writers. Those are the places where this sort of big fuzzy, shared understanding of things, actually materializes for the people who do the work day to day. So they matter a lot.

We model content for search, and for templating, and for data validation, and for all sorts of reasons. But one of the goals, we say, of modeling content is breaking it down. So it could be reused like remixed and reused. Unfortunately, what I found is that customers don't tend to do that. And we have had conversations on this podcast with some other people about how content reuse is still kind of the white whale of our industry, that we're still trying to get people to buy into. And I just wanted to get your feelings and that you and I, as content modeling, people could sit back and get very academic about content reuse and breaking it down so we can mix and match it. But we can't seem to bring our customers along to that same understanding. Why do you think that is?

So I think there's two sides to that. One is what expectations we bring to the word reuse. When we say content reuse in an academic nerdy information, architecture sense, a lot of people that you talk to will say, oh, that means we create the canonical piece of content that describes our company for, and it might appear on an about us page or it might appear in a brochure. It might appear in all kinds of places and reuse is driven by making a properly defined, properly broken down thing that can be used anywhere you want to talk about what is this company? And that's the canonical concept of content reuse. And that's really tricky. It's easy to say, but it's really hard to make happen because oftentimes organizations and individuals, they want to talk about a given idea in different ways in different contexts. So there's actual nine canonical ways of describing X.

(11:12)
And that's where I think a lot of reuse in the real world runs a ground, but there's also what I think of as small R reuse for content. And this is actually where I think the day-to-day work drudgery of maintaining a real website is full of opportunities for content reuse. It's things like when we having an upcoming event, we want to be able to show it in the sidebar and we want to show it in our news section and we want to be able to show it on the front page when it's the day of.

(11:54)
And man, it's a huge pain for our site maintainer to go in and update the sidebar on all the pages where it matters and update the front page and make sure registration is closed down once it's too late to register. Again, the growth work of maintaining stuff means that a simple piece of content or a simple thing that your organization is doing that you need to publicize. One thing changes about it. And now you've got 30 pieces of content that actually need to be updated. So when I think of reuse, it's not just that academic sense of we have one source of truth for what the description of our company is or something like that. It's also all of those different places where real web production means stuff gets remade over and over and over and updating it is hugely time consuming and repetitive unless a good content model is backing the page by page publication of stuff.

The trick is I think to get people to coalesce on a content model without breaking them out, that monologue, was lovely. And I just got absolutely absorbed in that, but how do you lead the customer down the path? How do you get from spreadsheet, rows, and columns to the much deeper philosophical, common language vocabulary aspect of it and you at Autogram and myself and Corey when I was back in my services days, we have to get people to articulate models all the time without freaking out about it. And how do you lead someone down the path to say, "Okay, all your domain knowledge, this wonderful amorphous massive information in your head, how do we turn that into a spreadsheet?" I mean at Autogram, this is sort of what you do. How much do you go back to your lovely monologue before? And then my spreadsheet rows and columns analogy. Where do you fall in the middle of that spectrum?

So there's a conference talk I've sort of been working on for a while and the only-

-there's a lot of conference talk you've been working on for a while?

That's true. That's true. But the working title of this one is Nobody Cares About Structured Content, And So Should You?

That's so true.

And I think especially inside of amongst practitioners who have we got religion, we know that it's important to iron out this stuff and make sure that it all before the CMS goes and gets customized. And before the designers go off and come up with their stuff, you got to get the model right because structured content matters for remixing, for reuse, for this, and for that. But nobody outside of us cares about the concept of structured content, full stop.

They only care about what it can get them.

Exactly. That's the kicker. They care about different things. And this is where I think the question of, so what decisions, when I'm making the content model, are important. That's where this comes in the kind of content model that you make. If your priority is making sure that every product that it gets created is utterly consistent and fully accurate and easy to vet and stuff like that is different than the content model you're going to make, if the priority is making sure that department heads have full creative control over a department landing page. Those aren't right or wrong questions, they're goal questions. To what end are we making this stuff kinds of questions. And sometimes there are goals that are incompatible with each other. We want content that is absolutely an utterly remix-able and repurpose-able in every possible platform on every possible device. And we want non-experts to have full creative control over how they appear in every place.

We'll get right on that

Yeah. There are a lot of very difficult conflicts there and there may not be a usable content model that solves every one of those problems, but understanding those Why questions and those To What End questions, I think can help us stay out of the unnecessary knife fights around. But no, that's the wrong way to model X. I don't think there are wrong content models. There are just counterproductive content models, models that don't serve the needs as effectively as they could.

Okay. But let me throw this at you. To what extent do you have a consultant balance the customer's stated current need with what you know they're going to need down the road? Because you can just watch customers paint themselves into a corner. Put themselves in a model that makes sense for them right now. But given your expansive history in the industry, you know in three years it's going to be a problem.

I mean, honestly, laying out those sorts of this is what's going to happen in two years. And that's the best way to approach that. Arguing against certain decisions, not from a that's the wrong way to do it, but rather you need to understand what decisions you're baking in by doing it this way and what the cost of those decisions is going to be if X or Y ever changed in the future and they probably will, based on history. I think there's a guy named Grady Booch. Who's one of the-

One of the legendary object-oriented programming guys. He wrote, he was the gang of four, that wrote the book.

He helped design the UML modeling language. For a certain type of nerd, I don't know how much more prestigious you can get than that. But one of the fascinating things he said was that architecture is the sum of all decisions about a system that are costly to change. If it would be expensive in time or money or resources to change this decision, functionally it's architecture, whether you want to call it that or not. And no matter how cool or meaningful it feels to diagram something, if it's essentially free to change it later, or it isn't going to hurt you, it might be wasted time to spend all of your energy nailing it down. And I think that's where that idea of over-modeling and creating unnecessarily detailed models of highly specific, tiny bits of content, it can sometimes veer down that path. If that changes in the future, it's not actually going to be that hard to alter.

Okay. So let's get real practical for a second. What do you think is the relative value of, there is in some systems an emphasis on migration APIs, which a migration in general terms is when you change a content model and then you have to convert all the content from one model to the other. I know that Driple has some ability to kind of change its model. Does the existence of a competent migration API takes some of the pressure off, we can fix it and post is what all the videographers say, right?

So that touches on something that Autogram would been talking about for a little while. It was really one of the initial challenges that Ethan and Karen and I, the three partners at Autogram were encountering in a lot of our projects that got us talking to each other and ended up resulting in us forming Autogram. I tend to call it the problem of high variance, high volume content. And the idea is that in the world of web and digital publishing, we are pretty good at high volume content that's the same. It's like, "Oh, we get the database set up, make templates, and fire hose that stuff till the cows come home." And then we're pretty good at high variance content, the "Well, we're going to have to bring in a designer and we'll make a special page for that." And it's just understood that's how the homepage works or that's how this landing page for the special project we're doing works, but we've only got six of those or after a year we've only got 12 of those or, oh, we've only got, and it creeps over time.

(21:40)
The challenge that I'm seeing a lot of is organizations where that need for high variation content is starting to expand to the point where they are also high volume content, where there is enough of that high variation stuff that they need. A meta model or something goofy to start capturing all of these special things we're putting together. And in some ways it's like the square space model. What you get is just a bunch of pages and then a bunch of different blocks or types of components that you can mix together, whatever kind of page you want and then link them all together. And that gets you that high variation, we can do any number of these we want. And it works very well with the growing emphasis on design pattern libraries and reusable, visual components and stuff like that.

(22:44)
But the challenges, and this comes back to the migration question you mentioned. If I say, "Oh, well, now we need to migrate to a new content model", six of those components are going away and they're being replaced by eight new components with slightly different things. You may have the logic to move any individual component in your content model to a different kind of component and not lose any data or break anything. But you've probably, given time and lots of pages being produced, worked yourself into a scenario where every individual component being migrated isn't necessarily going to preserve the intention and the goal that each one of those page authors was working towards. You've kept all of the data. You've made all the diagrams line up, but the intentions that those people were working towards when they built those pages out is now broken and there's no information in the model or in your database or whatever about what those intentions were.

(23:51)
And that's where it's very easy to use a highly structured, very rigorous content model and work yourself into the same place that our old days of, we just made a lot of HTML pages. And then when the design changed, we just had to go back and remake them all. Those kinds of anything pages full of components, over time, very easily work into that same sort of spot. And I think that's a real problem. There are various ways to say it, salve for that. But a lot of the solutions currently being touted as how you get whatever you need, they produce that. What you have is a bunch of anything pages filled with stacks of components, but you don't know what that anything page was supposed to be without asking the person who made it. And that's just a CMS driven version of the old, how did this HTML page get made and what do we have to do to rebuild it?

Well, this goes back to the idea of narrative flow, the whole is bigger than the sum of its parts. I always found this during content migrations, if they have these composed pages, which were visually composed by dragging blocks and arranging them on a page, you're not going to migrate that page. I mean, that's not, first of all-

You're going to remake it from scratch.

Yes. The technical challenge of migrating from one component library to another component library is very, very painful. And second of all, when it gets in the other one, you move the data across, but it may just not be right. And all of that, stuff's got to be manually checked.

I've talked about the language problem of content modeling. And I think this hits it. It's a language by definition. Is it just a dictionary full of words. It's not just the components, the pieces, it's also this idea of grammar and the actual communicative intent that is being worked towards. And you can have a perfect one-to-one dictionary that lets you translate word-by-word, but it doesn't necessarily mean you get the grammar of how these things are supposed to fit together. Or when you move to a new language that just going word-by-word is going to be effective in getting your meaning across. And I think that's where a lot of these design component assembly oriented CMSs can lead people down a path of very dangerous assumptions.

With clients, content modeling is the most difficult thing to explain, to get anyone to understand. The Web Project Guide ultimately is a book about demystifying the internet, not the internet, but demystifying how a website is made.

It's the how a bill becomes a law song, but for websites.

Yes, exactly. And it's like content modeling is the one point where everybody's brains get a little scrambled and it's because you have this idea of language and it also has to then tie into the sort of technical aspect of how does that language turn into something that a robot or a machine can move where it needs to move. And everybody's very used to writing things in a word document, or they're used to writing things where they don't have any boundaries whatsoever. And that's kind of where we run into so many of these issues, is like, you need those boundaries. I've really struggled with how to demystify the idea that listen, the web is unending. You can do really whatever you want on it, but there also are invisible boundaries that you have to run into at all points.

That's actually where Mark Baker's book structured writing has been really helpful for me because so much of what it talks about isn't technical structure like templates or databases or CMS content types. It's about thinking about the kinds of things we write in terms of their natural structure of meaning and rhetoric. And that's where if somebody's used to writing say weather advisories, they may not think of it as a structured type of content.

(28:22)
But if you're able to step back from the technical terminology, talking to them about, how long should a weather advisory be? What things do you always have to make sure you mention? What shouldn't be in there? Those kinds of questions are working towards a content model, but they're not what people think of as a content model. They're usually just thinking of it "Oh, well, that's what that is. Well, that's how you write one." And I think that's the best on ramp that I've been able to ever find for walking people through this process. It's making sure that the mental map they have of what constitutes X or Y or Z gets translated effectively so that they're not trying to write what they've always written, trying to create these things that have a natural shape, but then trying to hammer them into some other form that the CMS expects of.

And if you have this content, what are the things you wish that content could do? If you were writing a weather report on paper, what do you wish it could do? "Well, I wish it could go to the very specific people that it needs to go to." "Well, okay, we can do that. That's categorization." "I wish that there was something that would really quickly summarize this for somebody who doesn't need to read the whole thing." "Sure. Okay. That's a hidden summary field that you only see on a listing page."

Or if it's severe enough, we'd like to show it at the top of every page so that people always see it. It's like, oh, well that means we could have a severity property or a given warning and that kind of stuff. And I think that's where that nobody cares about structured content. They care about what it enables and making sure that the focus stays on that stuff. That goes a long way.

Yeah. It's language, but it's language with benefits. It's language with, think language plus.

Yeah. Well, I mean, nobody cares about language either. They care about communicating.

So should you?

100%, you're absolutely right. Yeah.

Yep. We could talk about this literally all day.

It's true.

Just we can fall down these rabbit holes. Content modeling is such an endless area of fascination. I wrote a book about it and at the end of the book, I talked about high context areas of study and low context area of study. People study wine and they study coffee and they just study cheese because there's so much context, there's so much variation. Nobody studies diet Coke because every diet Coke is the same. And I feel like content modeling is the wine or cheese of our industry. It's so incredibly high context. And there's so many different variations and subtleties and requirements that it's as complex as Cabernet. God, that sounds elitist.

Deane, what is the web equivalent of the diet Coke then?

Blog, a word-

A blog. Yeah.

Right. Or blog is a blog is a blog. I don't want to say WordPress, but I mean like a blog. For a long time, I was back in the golden age of blogging, moveable type days. There was a title of summary and a body and that was pretty much it and everything.

Everything else was gravy that whatever you were doing specially added on.

It was a custom field.

Let's be honest. Anything extra from that was going to be broken in about six months anyway. Going to do an update.

I promise I'll keep this digression as short as possible.

No, you won't.

Fair. One of the things that issue of the high context stuff. One of the reasons that I think it's challenging is that oftentimes during content modeling, we're trying to talk about two things. And this comes up when we talk about ironing out a common language. That idea comes up a lot when we talk about the value of it. But there's two ways you can talk about it. There's language about, and language of. You can talk about cinema using specific kinds of language. What words are we going to use to define different types of movies or different types of stories, but then there's the language of cinema and that's things like what does a long distance shot communicate? How does that get used? What does a close tracking headshot do when you are actually making a piece of film?

(33:07)
And that's where that language problem that's very interesting comes in and where that assembly driven webpage composition is tricky because if people are just thinking about it as slamming together visual pieces to make a webpage, it's very easy for the results to become inconsistent. But if you're thinking about it as these are things I can use together to communicate something, they're the building blocks of the bigger stuff I'm trying to get across. What you're talking about isn't just the names that we put on things. What do we name this field in the CMS, but also how do people assemble them together to create meaning and communicate stuff? It's like that. What words do we use when describing different parts of the practice of cinema and then the language of how do those parts get assembled by directors or cinematographers to communicate a message? It's like that language about and language of.

It's like the micro and the macro, right?

Yeah. How they get applied and how they get named.

What are you working on now? What else can we pitch for you?

So obviously Autogram working with a couple of different clients right now on some interesting, "Hey, so we're merging with another company and we've got two design systems and what should we do?" Or, "We're re-platforming our CMS and we know how we're going to do that technically, but it's also unearthed some complicated questions we have about where does our content even come from? How do we plan these things?" Those are the kinds of things that we often work on with clients.

Give us 30 seconds of background on autogram. So who it is and tell the story of what an Autogram is cause that's [inaudible 00:35:09].

Okay. So Autogram is a partnership between myself, Karen McGrane, one of the longstanding figures of the information architecture in UX and design communities, and Ethan Marcotte, he literally wrote the book on responsive design and helped advance that concept and bring it together from a drifty cloud of techniques that people were using maybe 10, 15 years ago, he turned it into a word that people could connect things to and start going there. And he's worked on a lot of different design system and visual design based projects.

(35:57)
And as I sort hinted at earlier, the three of us have known each other for years and worked on a couple of projects here and there, but also just hung out and talked shop about this stuff for a long time. And what we were finding was that increasingly all three of us from the different perspectives that we focused on were all encountering the same kind of challenge where different best practices or technical solutions were being pitched to organizations we've worked with. As the solution, you need a design system, or you need a better CMS, or you need a new NAV system or something like that, or, you need agile teams on the purely technical side.

(36:45)
And on the other side of difficult, expensive transformation projects or whatever, a lot of these organizations weren't really feeling like they got what they were promised. And in most cases it's like you could look at and say, okay, well that's because there were all these underlying questions that you need to get good answers to or figure out before these technical things are going to actually pay off for you and the place where this was happening most frequently was those page building and site building tools that promised to unify your editorial production, your design system and this and your that. And on the other side, what they had was a pile of anything pages with 80 different components on each one and no way to sort out what and helping orgs pick through those questions, come up with an approach that actually worked for their language.

(37:53)
Not just some generic Esperanto approach to content is where our focus has been. And obviously no plan survives contact with reality. So we've gone off on fascinating, different sort related projects with a bunch of different clients, but that's really the heart of what we're focusing on. That intersection of structured content for multi-platform or multi-output publishing design systems. Organizations with complicated multi-teams that have to work together to get this stuff made. That's sort where our sweet spot is, helping folks iron out the overlap and figure out the stuff that needs to be working well before throwing a new CMS at it or throwing a new design system at it or throwing tokens or whatever is really going to solve the problem. So, that's what we enjoy.

As somebody works for a CMS vendor. It's very much in my best interest that people throw new CMSs at things.

Oh, I love me a new CMS. Don't get me wrong.

Tell us what an Autogram is.

So an Autogram, it's sort of a linguistic novelty. It's a sentence that enumerates its own components. Like this sentence contains five Ts, 12 As, no Zs, but now it contains one Z because I said Z.

The paradox of the autogram.

Right. And you can create an autogram, but it almost requires knowing the end point before you start, it's very iterative. It's almost impossible not to encounter questions halfway through that first you to reevaluate everything. And it seemed very familiar to the shape of these projects.

Knowing the end before you start. So back to Corey's question, what are you working on? What are big projects that you have going on? What can we help you promote?

So obviously there's clients that we're working with that we will be able to talk about it in a little while, but if there's anybody out there who's interested in chewing on questions like "How do we get our design and development and content and marketing and support teams on the same page with their 19 websites?" and "How do we bridge the gap between them?" Or "We're trying to roll out a design system. And we discovered we have three." Things like that.

(40:52)
Or "We are trying to put together an education section to our website and we need tools for people to build out new sections of the site ad hoc and make their new dream fly without developer intervention. But we also need it highly structured because it's going to be fit into our app and it's going to live on the website and it needs to be on mobile." Those kinds of questions are where we live and getting those cross-disciplinary challenges sort of ironed out and clearly understood and everybody on the same page, that's what we like. Sometimes that means workshops, sometimes that means four months of interviews and innumerable diagrams and spreadsheets, but that's sort the kind of stuff we do. We're also working on an interesting project right now for ourselves to help with the inventory and analysis process for really large multi-site web ecosystem.

Digital estates is, the new hotness that-

Oh, I like that. Yeah.

Your digital estate.

Yes. It's digital village, even for some organizations. But so many of the tools that are out there are either purely built for SEO or they're really just sort for people who want to scrape product listings off of Amazon and pop up their own site. And we're working on one that's more focused on extracting meaningful structural information and organization, specific insights about how the complexity of a page maps to the team that creates it or how two different ways of organizing the website can serve different audience tasks differently. Things that make it easier to arrive at answers to those kinds of questions that there's usually a lot of grunt work and spreadsheet wrangling involved in it. And we're just building some tools that help move from "I've got an idea" to "we've got some good information on what the results of that would be" to tighten that loop so that there's more opportunity to try different ideas during that iterative process.

Well, this by far longest episode we've ever had, I could literally talk about this stuff forever. Corey, you didn't give much to say this time.

Nope.

Jeff and I have had these conversations for ages and at one point, Jeff, we need to come back to the idea of our CMS on conference.

It always.

We have always had this dream of in fact, this is what we met in New York to talk about. We've had this dream about a long weekend, somewhere on the side of a glacier and Iceland or something and just a weekend with a bunch of content modeling nerds and sit and talk about content modeling. And we're going to call it a Summit for the Ages and write a position paper or something. It'll be like the DaveOps for nerds. Builderberg. I think we call it nerd builderberg.

Nerd the Berg group.

We will get this done one day.

Until then. Thanks Jeff.

Always a pleasure.

Jeff. It was wonderful. Thank you very much.

Thank you.

All right, Deane. We're back. We made it through an hour of interview. Not all of it made the podcast I suspect, but-

Literally could have talked to him for another hour. I mean, Jeff thinks about it when he bought up the structured writing book. I just fell in love with Jeff all over again. That's a great book that I just read last year and Jeff and I think very similarly about content modeling and it's primacy really in the management of content and it's pitfalls and oh, goodness, I could talk to Jeff forever. And one day Jeff, we are going to do that on conference where we sit on the side of a glacier in Iceland and talk about content modeling because that's what you do when you sit in a glacier.

If you have ever, Deane, wanted to dive into the world of tabletop role playing games, Jeff is also the person to do that with. He has this fascinating background in knowing every game and how the pieces fit together at an almost analytical level. And I've played a game with him where he was the dungeon master. It was a game in which three of us were old women pattered off of Angelo Lansbury. We were all solving a small town mystery and it was one of the most fascinating, fun things I've ever done in my life. So I don't want to blow it up Jeff's spot, but you should reach out to him and join role playing games with him.

You're going to regret saying that to me because the fact is when I was in high school in junior high, I was heavily into tabletop role playing games. I loved tabletop role playing games for the same reason why I love content modeling, which I mentioned in the intro is that I think that tabletop role playing game games are the structure and skeleton behind a narrative. Because essentially what you're doing is you have modeled a narrative with a role playing game. You have a system of tracking time and you have a system of tracking money and you have a system of tracking combat. And I still to this day buy role playing games, not to play, but just to read. In fact, right now I am collecting all the things that were issued for the James Bond 007 role playing game that came out in the eighties. I like James Bond, but also I just love reading how they structured it, how they structured a narrative, how they put rules around it. And my God it's content [inaudible 00:46:44].

(46:43)
I wrote a blog post. I know it's going to shock you, but I wrote a blog post and the blog post literally called our computers just expensive dice because I was talking about how fact that computer is modeling information, essentially processing information and role playing games, we're modeling and processing a narrative. So wow. You now regret bringing that up don't you?

Well, no. I mean you've just now helped me understand that content management systems, if it's built correctly are just really complicated role playing games. They're just what they are. You have this limited potential to create really anything that you want within a system. And it's the system itself that actually gives you that unlimited ability to create stuff because it provides rules. So you don't go all over the place.

We're building structural systems for content. Whereas role playing games are structural systems for a narrative.

Yeah. Wow. That's our show. That's it. Thanks to our guest Jeff Eaton, partner at Autogram and the only person I know who actually uses a 3D printer for its intended use, which of course is printing D and D figurines. He's doing great stuff at Autogram. He's got podcasts where he talks about a hundred things that aren't even web related. Anyway, he's a wonderful person. The Web Project Guide is a product of Blend Interactive, a web strategy design and development shop that builds websites and guides teams through complicated web and content problems from content strategy and design to CMS implementation and support. We are dedicated to making great things for the web and this is one of those things. Deane did you know this month marks the one year anniversary of the physical version of the Web Project Guide. And we think you should buy one.

To celebrate that everybody should go out and buy a copy.

And you can still buy them. You can get it directly from us at order.webproject.guide or for our international friends, head over to Amazon and you can get more realistic shipping. This is episode 11 of the Web Project Guide, which also corresponds with chapter 11 of the book model your content. You can read the full text of this chapter at the site itself, webproject.guide/model, where you'll find some great articles and posts and books and other things that helped us write that chapter about content modeling. And if you like this episode, we really think you'll like our last episode, which was with Lisa Maria Marquis. And it was about information architecture and organizing content. This is the part of the outro that I usually use to ask for five star reviews on Apple podcasts or Spotify or wherever you possibly rate podcasts. But I'm not going to ask that this week. I'm also not going to tell you that it really helps us get more eyes on the podcast.

I'll get them Corey. Good job.

I will tell you, I really appreciate those reviews personally and professionally. So we will thank you for that. And that's what we got this month. Subscribe and check us out next month. We're going to talk about the art and practice of web writing and until then, go do amazing things.

Good luck.