Key ideas
- Content doesn’t mean the same thing to everyone.
- In order to communicate effectively, we have to agree on language and meaning.
Jeff Eaton is a co-founder of Autogram, a partnership of content management and design systems experts. He helps large organizations understand, model, and manage their content. His solutions sit in the overlap between design, communication, and technology.
I met one of Autogram’s co-founders via a hundred-page spec document from one of our clients. It had a whole section on the philosophy of how the project approached taxonomy. I said, ‘This is the best document I’ve ever read from a client.’ They told me who wrote it, and I put a pin in that. Two years later, when we actually met, I told her, ‘Your document? Oh my God—that was the best thing ever!’
Jeff revels in the details of things most people either overlook or find uninteresting. For him, those are the things that are the most important. When he works with clients, he likes to focus on the language they use and dismantle unconscious assumptions of what words mean.
We try to work with clients to figure out not only which of their teams is in charge or what vision everyone needs to rally around, but what is the language they’re building for the organization? What are you putting together? They don’t just need a vocabulary of pieces; they need a shared understanding of what things mean. What does this piece actually do? What function does that role actually have? In terms of content, why choose this versus that? You have to make sure everyone is on the same page and that there is a shared understanding of what you’re trying to accomplish.
Understanding what we do and why—and the implications of both—are critical in terms of content and design systems. Jeff likens it to Maslow’s Hierarchy of Needs: When we agree on the language around a project, product, or piece of content, then it’s easier to think about who is building the product and for whom. Jeff believes language is the basis for the system upon which everything else rests.
The amount of work that it takes to express thoughts that we don’t have good words for ramps up dramatically. Making sure we’re on the same page with everyone scales up immensely, and it takes a huge amount of work to recognize what we’re even talking about. Language is a tool that makes things much easier, like having the right tool for a particular job radically alters how difficult the job is.
Jeff believes content architecture, CMS assembly tools, and design systems need to operate in agreement with each other but often don’t. They may work with each other but the component pieces don’t always work together effectively.
We come across scenarios where clients hammer multiple design components into place because they need to do X, but it’s really not what they want. Or they’re using this for X but it’s really meant for Y. Those are symbols of conceptual language-like tools that are hammering against each other rather than working in conjunction. We help them figure out what they’re doing, what they’re building, and what their goals are.
There is more to content management, design systems, and architecture than meets the eye. Jeff works hard to make sure his clients understand and adapt to this ever-changing landscape.
Links and important mentions
Stream episode 34 now, or subscribe on your favorite podcast platform below.
Episode transcript
Note: This transcript may contain some minor wording and formatting errors. Apologies in advance!
Todd Nienkerk: Welcome to The Future of Content. I’m your host, Todd Niekerk.
Every episode we explore content—its creation, management and distribution—by talking with people who make content possible. Our goal is to learn from diverse perspectives and industries to become better creators.
The Future of Content is brought to you by Four Kitchens. We build digital content experiences for ambitious organizations.
Today I’m joined by Jeff Eaton from Autogram, and we’re going to be talking about, in Autogram’s words, “the tangly intersection of content, architecture, design systems, and governance in large organizations.” So it’s a lot to cover. Welcome to The Future of Content, Jeff.
Jeff Eaton: Hi, Todd. It’s great to be here and always a pleasure to chat. I know we’ve known each other for years and years and years and years. CMS and content space. It is fantastic.
Todd Nienkerk: Yes, Drupal-ers everywhere.
Jeff Eaton: The we’re thick on the ground.
Todd Nienkerk: Yeah, that’s right. So thank you for joining me. You have in the past—what it’s been a year-and-a-half that you co-founded—
Jeff Eaton: Yeah. Yeah. August, August 2020.
Todd Nienkerk: Yeah, awesome. And that’s right in the height of everything. So yeah, it’s pretty bold timing.
And so you co-founded this with Karen McGrane and Ethan Marcotte, correct? And the three of you are all very well-known for what you do in this space, and it was really interesting to see the three of you come together. So how did you come together and what is your goal at Autogram? What are you trying to do that other agencies either aren’t, or are missing out on, or aren’t doing very well?
Jeff Eaton: That is— That is— Wow. What a question.
Todd Nienkerk: How do you differentiate yourself?
Jeff Eaton: So our sort of origin story, you know, Karen and Ethan and I have known each other and crossed paths for like years on and off. And I think in different combinations, we’ve worked together on different projects for quite a long time. I think, you know, I joke around that, I think it was back in like 2007 or so that I first met Karen just via a hundred-page spec document from one of our clients that was handed over and it had a whole section on the philosophy of how taxonomy is being approached on this project. And I just said, “Oh my God, this is the best document I’ve ever received from a client.” They were like, “Oh yeah, yeah, Karen McGrane put that together,” and I was like, “OK, I’m putting a pin in that.” And like, two years later, when we actually met, I was like, “Your document? My God—best thing ever!”
So, yeah, you know, like the three of us have crossed paths in a bunch of different ways and even on client projects, when I was working at Lullabot, you know, there were some that, you know, the three of us actually all ended up working together on, you know, a number of years back, we sort of we ended up— The three of us got together and just as a fun sort of side thing did a redesign for The Toast, a blog that was very popular among hip librarians, kind of. It was a blast.
Todd Nienkerk: That’s something you could really, like seriously nerd out on. You are a bunch of content people and data structure people working for those people.
Jeff Eaton: Yeah, I mean, it wasn’t a librarian blog, but like that sort of felt like the core demographic.
Todd Nienkerk: Like information sciences and—
Jeff Eaton: And like weird hipster, hip like internet culture stuff, literary references.
Anyways, yeah, it was a fascinating project. It was great working with them. And also it was the first time like the three of us had gotten a chance to sit down with a couple other people we knew sort of do the, you know, “makeover treatment” on a small project, and that was a lot of fun.
But, you know, over the years, we’ve kept in touch and sort of either, you know, brainstormed or done the, you know, “sit down for drinks and kick around questions about weird problems we’re encountering after a conference” kind of thing. And for probably about the last several years, all three of us had been talking with each other about this weird intersection of problems that we were seeing from different angles across a bunch of different large clients. Like Karen, a lot of her work has been with, you know, governance and process and like some content. You know, content strategy is such a broad umbrella. A lot of the work that she’s done over the years has been in helping large organizations sort out what they’re doing and what all of their content in motion actually looks like for, you know, across 17 different brands that they’re trying to coordinate or whatever. So like the organizational process and how you govern all that stuff as it’s moving.
My background has been in the information architecture and content architecture side of things, you know, figuring out how to structure this stuff so you can effectively repurpose it across, you know, a bunch of different platforms. How do you get that to the CMS and make that work well? Ethan’s background is in design. He literally wrote the book on responsive design, which I think was so inspiring for me when it came out because it wasn’t just about a particular design technique. It was like a philosophy of how you approach a whole class of challenges that was coming up.
Todd Nienkerk: And it was also one of those turning points in our industry where people realized that there isn’t a one-to-one relationship between their content management system, whether that’s an actual CMS or just a bunch of flat HTML files or whatever, and what the person sees on the other end is that there are different experiences, and it’s not as subtle as like, well, they’re looking on it on this at this thing on Internet Explorer at the time or versus Firefox versus Chrome,. It’s vastly different screens that have different ways of inputting data. And how do you handle things that are too small to read on all that stuff, right?
Jeff Eaton: And what is an approach other than just, “Well, I guess we build 50 now,” you know. Like, how do you tackle that new kind of multiplicative problem? And like over the past several years in particular, one of the things that we realized as we talked that all of us had been seeing was this growing frustration in a lot of large organizations that like doing the right thing on a project by project, team by team basis, like, oh, we’re going, we’re, you know, doing a decoupled CMS and we’re putting in a design system, and we’ve got our inventory and we’ve got a new process for how we approve our new content.
And, you know, at an individual level, each team could say we’re doing good work, but like it wasn’t coming together for organizations, you know? And sometimes that’s a matter of scale. Sometimes it’s a matter of clashes between organizational cultures and stuff like that. But it started us thinking about like, OK, is there something going on here beyond just, yeah, change is hard? And one of the things that we started teasing out was that in a lot of different organizations, there’s a tension between the needs of like, you know, core messaging and communications and what it needs to prioritize and how it needs— The way that it conceptualize is what’s being done in an organization as you’re putting stuff out there.
Then on the pure CMS or technical delivery and infrastructure side, there’s usually like a whole nother view of things, a different vocabulary that’s being built out. And then on the design side, you’ve got another one entirely that’s often being created. And, you know, I’m sort of working towards the, “You gotta get them all together in the same room and on the same page” thing, which isn’t really novel, you know? We’ve all been saying that in 10 different ways to, you know, everybody we can meet. But in particular, like this inflection point of new technologies, new approaches, the eagerness of organizations to embrace more structured content in order to facilitate better cross-platform and cross-channel publishing, and the arrival of an enthusiasm about design systems— all of these things. Like more modular and API-driven ways of constructing the technical side. Structured content as a way of creating and managing and organizing your stuff. Design systems as a way of conceptualizing and planning out a growing, evolving, you know, approach to the presentation side of stuff. On paper, all of these things felt like they should be like, you know, like milk and cookies, you know? They should just go together perfectly, and yet they weren’t. It ended up being this huge just titanic struggle to actually make those things work together effectively.
And it started us thinking about how those things actually have to work together, how they have to understand each other. Like, what are you actually building when you say, “Oh, we need modular software components, and modular content components, and modular design components?” Well, what are the implications when you start, you know, throwing those things together? Who conceptualizes the breakdown? Where are the lines between the pieces? How do you envision new pieces being added and what does that mean? These were questions that we weren’t really seeing those individual, siloed communities of practice tackling because everybody’s sort of trying to get the kinks ironed out in their, you know, portion of things. But then in large orgs, where this isn’t just being done, it’s pilot programs, you know, it’s actually being tackled at large scale, those kinds of collisions and those kinds of mismatches between the way that a designer doesn’t just break down the page visually, but like conceptualize the thing being built. When that doesn’t match the way the structured content architect imagined things being built and how the organization assembles and creates things, it doesn’t matter that each team can document and produce and cycle on their particular artifacts. When it comes together, there’s going to be all kinds of incredibly frustrating mismatches and collisions.
All of that is to say, by the way, that was like that was the ongoing conversation we’d been having for several years and started chewing on “What would it look like to focus on this?”
Todd Nienkerk: And that’s what struck me about you. When I first read about the three of you getting together to do this, my initial reaction was like, “This is brilliant, because they’ve figured out like, here are three people who do these three things on every project.”
There’s some kind of weird like— There’s at best, a handoff. And at worst, a crazy collision and confusion. And like you said, like taxonomy to a developer is different than taxonomy, to an information architect is different to— Right? And these three people who have these three areas of practice are coming together into one spot to try to figure out how they can all be working together simultaneously. And so I wonder from a like— I don’t know if it’s an industry thing or the way that teams are built or the ways that organizations run or whatever, why do you think these divisions exist? Is it because people get interested in and specialize in one of these— Let’s say there three areas, let’s say there’s information architecture, content strategy and front end. Let’s just say that those are the three just for the sake of trying to put our heads around something.
Is it that people just are like, “I just really like frontend development and like, I’m not really interested in these other two things.” Or is it that the way that our industry works, we’re encouraged to go into these channels, but maybe it’s actually all the same thing and that there’s a new kind of role emerging.
Jeff Eaton: I thank you for teeing that one up.
Todd Nienkerk: That was unintentional, but I’ll take it.
Jeff Eaton: So, you know, before we actually started the start of the episode, we were just sort of chatting about that idea that a small, like cross-functional team like, you know, sits in the same room, whether it’s a physical room or like a Slack channel every day and like just, you know, “Hey, it’s the four of us against the world, we’re making a thing.”
We were talking about how it’s counterintuitive, how much a team like that can accomplish, and how tight and coordinated the vision can be compared to a giant enterprise team that’s like, you know, divided into six separate silos and coordinates it once-every-Wednesday meetings. And I think that a lot of it is the scale of the things that we’re trying to do today is just so much larger than, say, you know, ’90s-era web projects. And the challenge there is that, you know, we’re trying to build not just artifacts now, but systems capable of producing artifacts.
Todd Nienkerk: Oh, that’s so true. Like, it’s never “built me a landing page”. It’s “build me a CMS that can let me build landing pages.”
Jeff Eaton: And that specific example is actually one of the things that we’ve been talking about a lot. We call it high-volume, high-variance content. Our industry as a whole has figured out how to do high-touch bespoke things like “the special page for the quarter, you know, for the yearly announcement”-type stuff. Sure, you throw a designer at it, you treat it as a special case in the CMS and you know you make something special and you roll it out and then highly templated pages CMSs they’ve got that down pat. You know, everybody knows how to, in some fashion, throw templated even variable kinds of information. You know, there’s lots of approaches to do that. But then you’ve got this middle zone of, “Yeah, but we need an editor to be able to do it” or “We can’t really throw designers at it, but they need to be able to build out different stuff.”
Todd Nienkerk: And “We want a writer to be able to design it.”
Jeff Eaton: Yes. And like the magic tipping point is where suddenly that’s not the home page or, oh, we need that for each one of our four core sectional overviews or something like that. But like, that’s just a kind of thing that gets produced and we need these things that are highly variable, they fit with the rest of the site and we need to be able to repurpose them and push them out to different channels. But like, it’s not a template, it’s almost like an expressive language or like a box full of Legos that we need people to be able to just put stuff together with.
And the lift for making a system like that that actually works with those different kinds of needs turns out to be really tremendous. It’s tough. And I mean, that combination of high variance and high volume, you know, you can’t just throw designers at each one and you can’t afford to just shove them all into templates. Or there aren’t quite enough of them, or there isn’t quite enough similarity to simply break down hard-and-fast templates, switching rules to cover every case. And there might be a new one that arrives tomorrow. And the need for the organization is to be able to turn something around in three weeks, not start gathering requirements and talk to the dev team about when they can push a new build that makes it possible to start building that thing. How do you navigate that? A lot of organizations have been saying things like, “Oh, well, I guess we’ll just throw Squarespace at that part of our site,” or, you know, “We’ll just tell the, you know, tell the design team to just keep firehosing one-off widgets out into our library of widgets so that we can do what we need.” And a year later, there’s like, well, now we’ve got 6,000 page components, only one percent of which have been used more than once.
Todd Nienkerk: Or worse, they’re not even using a design system or components, right? They’re just generating a bunch of pages, and now they have—if they’re working within a CMS—they’ve created a whole bunch of content types or templates or post types or whatever, or if they’re working in flat files. If you want to make one update because Legal said you can’t say this or that? Well, do you do a search ‘replace’ on, you know, 500 different HTML?
Jeff Eaton: And the solutions to this, interestingly enough, end up looking very different if like, depending on whether the design team or the CMS dev team or the marketing team is told, “OK, you’re the buck-stops-here team. You choose the solution to this.” They end up looking radically different.
You know, and what we’ve tried to work with clients on is figuring out not just which of the teams is in charge, which, you know, which vision does everyone else sort of have to bend their universe to fit, but rather figuring out, organization-wide, what’s the language that you are building for your organization? What’s the stuff you’re putting together? Because this sort of combinatorial challenge with assembled content of the landing page problem, but now it’s more than just landing pages, it’s actually kind of language-like rather than just, you know, component-assembly. It’s, you know, you need not just this vocabulary of pieces, but a shared understanding of what they mean. What does the rotator actually do? Not just technically, but for us. When we decide what to do on a page, why do we choose this versus that? Making sure that everybody’s on the same page, not just the designers or whatever on that, making sure that there’s a shared understanding of what the problems these different components are trying to solve. Why would we do an interview versus a whitepaper? Do we understand why we’re doing that stuff and what the implications of that are? The result is moving past, just like here’s our vocabulary of building blocks, but also like the grammar of how they fit together and what roles they serve in the thing we are building.
Todd Nienkerk: It’s like a hierarchy of needs in that when you’re able to all agree on like, you know, food, safety, shelter, or water, right, then you can start to think about like, well, OK, we don’t have to worry about, well, who the hell is going to build this page? Like, do we send it to a designer or do we send it to a developer? Do we send it to a copywriter? Like, well, you’ve got that figured out, you have a process for that or you have a system in place that helps, you know, people with a much broader variety of skills handle this stuff. Now you can start wasting your time—wasting your time—utilizing your precious time, thinking about stuff from a business perspective and thinking about it in terms of, “Well, like why are we doing this and why is it important to our bottom line? And what are we trying to get out of it rather than like it’s the whole planning versus reacting thing,” right? It elevates you to a place of planning.
Jeff Eaton: And I mean, I think, you know, every one of these communities is sort of chewing on these questions themselves.
It’s like the shift from “I’m a developer and my job is to make VB script that spits out HTML” to architecting solutions to complicated problems like that’s a journey in and of itself. And I feel like, you know, yeah, that moving up Maslow’s hierarchy of needs idea is interesting because this was something that, you know, there weren’t necessarily enough pieces in place for a lot of organizations to be ready to chew on it in this way. And, you know, even with a lot of our clients, you know, they may be excited about that. But you know, there’s always a giant pile of, you know, under-the-hood work to iron out before everybody can actually like, realize that vision. But that idea of helping organizations build not just the library of visual components or the list of content types or the pile of CMS widgets or the list of APIs that they expose—but figure out what’s the big picture, what’s the language we’re constructing here? What do we envision people being able to do with it? And what do we want to facilitate and like, how do we see this evolving over time? A year from now, when some new need arises, what’s the approach we believe will facilitate to solving a new problem that arises? Like those kinds of things, focusing on those questions is really, really exciting, and it’s honestly, it’s like it’s a thrill to be working with Karen and Ethan on this stuff because, you know, each of us coming at it from from the different angles of our backgrounds, it, you know, it’s a blast.
Todd Nienkerk: Well, on that note, let’s take a short break, and when we return, we will keep talking with Jeff about content architecture, design systems, governance, and how all these three things sort of intermingle and are sometimes substituted for the other and all of that. It’s a really interesting, tangled mess and we’re going to try to sort through it, so we’ll be right back.
[break]Hey, everyone, I wanted to quickly tell you a little bit about Four Kitchens. You probably know that Four Kitchens makes websites, but we do so much more than that. Our team of Web Chefs can help you make better use of your content, scale your web team and create world-class digital experiences. For example, we’re in the middle of helping a university build a digital publishing platform that will power more than a thousand websites.
To find out more about how Four Kitchens can help, visit us at fourkitchens.com. Now back to the episode.
Todd Nienkerk: Welcome back to The Future of Content. Our guest today is Jeff Eaton, partner at Autogram. Jeff, I would like to know more about how, earlier in this conversation, you mentioned how we’re all searching for a common language. And how— Let’s say let’s use taxonomy. For example, let’s talk about taxonomy in the context of working on a WordPress site. So taxonomy—
Jeff Eaton: a.k.a, “tags.”
Todd Nienkerk: a.k.a. “tags,” but they’re also categories. So they’re categories and tags in WordPress, right? Drupal has a taxonomy, and that’s a whole thing. And that means something in those CMS and for those CMS users, admins, maintainers.
But in the world of information architecture taxonomy has a tiny related, somewhat related concept, but is very specific about how you categorize content that isn’t necessarily the same manifestation that you find hardcoded into these CMSs. So when we say “taxonomy,” a frontend developer is going to hear one thing because they’re working in their CMS, an information architect is going to hear another, and a content strategist may hear another thing entirely. How do we bridge the gap between just the words that we use as the beginning of a way to combine these different aspects of our industry and skill sets and silos?
Jeff Eaton: Boy, that’s an excellent question. It’s funny because one of the first times that Karen and I ever worked together on a project directly was years back, if Buzzer rings a bell for you. Way back, God bless it.
But I very distinctly remember this conversation where she was coming, you know, she was bringing a bunch of design, content strategy, information architecture stuff. I was, you know, the Drupal nerd in the room. And there were a bunch of conversations about how to build out a content model to solve a couple of different problems, and then on the flipside, how to give users the ability to like, slice and dice the information on, you know, on the site. And I made some comment about, “Oh, well, you know, we can’t really filter and organize stuff like that because that’s a field, not taxonomy.” And in the Drupal world that, you know, that makes sense. It’s like, “Oh, well, it’s this particular bit of data, Drupal thinks of that as taxonomy information,” but that bit of information, it’s just some fields you put some information into. So there’s a whole bunch of support tooling for filtering and sorting and organizing that doesn’t come along with it by default.
And she just sort of shook her head and said, if you’re using it to organize things, it’s taxonomy. And I just I remember the sort of, “Oooohhh” moment where like—
Todd Nienkerk: Because your mental box was “Drupal has a thing called taxonomies, and there are parent terms and child terms, and they can be related in these ways. And these modules can be installed to create these kinds of relationships and filters and whatever.” Whereas she’s saying, “Look from an information sciences standpoint, anything you use to categorize or sort anything is a taxonomy.”
Jeff Eaton: Yep, and that was like one of those mind-blowing moments that, I think for me early on, helped me get the idea that, you know, on the implementation side of the CMS, a lot of things that we think are hard and fast are really how we happened to implement a particular concept in the moment that code was being built out, and treating it as like synonymous with that thing or the idea we were trying to get at or the need that was being filled, like there’s a big danger in, you know, collapsing those things into the tool I am familiar with to solve Problem X.
All of that to say like, I think that’s actually where a lot of the communications and vocabulary problems come into play. It’s not even like, “Oh, this team doesn’t get what people are talking about” or “This other group isn’t knowledgeable about the right way to talk about these things.” It’s more like there’s so many different ways that different disciplines tackle overlapping sets of challenges and problems that it’s very easy to miss the underlying challenges that everybody’s sort of, you know, swarming around and see my team’s take on it or what the tool I’m working on, what it bites off in this problem as the problem itself, not something we’re all approaching from different angles. I think that like that was a hard pill to swallow early on because, you know, once you start figuring out things have names, making sure everybody uses the right name for everything is like a burning passion.
And sort of on the other side of that is the realization that, well, maybe the names are less important than making sure we all understand each other. And, you know, and we’ve just we’re just wrapping up with a client that, you know, had this problem in spades, where there’s like 15 different ways to talk about different slices and subsets of their information ecosystem. And no one was ever really clear how much of that was. Are we using the same word for different things? Or are we just talking about different things? Or are we talking about slightly overlapping stuff and using different handles to get that? And it’s a huge effort to push through those fuzzy-edged confusing questions, because nine times out of 10, you can get away with just sort of hand-waving over the differences in the scope of a discussion or a project or whatever. But the fuzziness accumulates over time, and eventually, you look back and you’re like, “Oh, we’ve been doing this for 10 years, and honestly, we’re not quite sure any of us is even talking about the same thing” after like, you know, 10 rollouts.
Todd Nienkerk: There’s this oddly human problem of— And this part is a bit of a tangent, but it relates to something I mentioned on this podcast several times in the past, which is, to be the person who enforces naming conventions is a very unenviable position because you become that like weird, pedantic, like, you’re just the jerk. You’re the jerk who is like, “We don’t call it that. We call it, actually, it’s this thing,” right? And everybody hates being that person. We’re interacting with that person. But it’s so necessary because, and this is the thing I’ve mentioned several times in the past. Psychologists and linguists are coming to realize that the way that we think about language is a little bit backwards. So common sense might dictate that language is a representation of a thought that exists. So you have a thought and you use language to construct a way to convey that thought to somebody else or just out into the world—out of your head. But in fact, it’s the opposite. And it is language that is the scaffolding around a concept or an idea hangs. And if you don’t possess the language, you don’t possess the thought yeah, and thought simply doesn’t exist.
Jeff Eaton: The Sapir-Whorf hypothesis. That’s that idea. And you know, there’s what’s called like the weak and strong version of that hypothesis. The strong version of it, which is like you just literally can’t think things that you don’t have words for, has pretty much been abandoned. But what’s called the weak version of the Sapir-Whorf hypothesis, which I’m probably butchering the pronunciation. I apologize to both Sapir and Whorf. The amount of work that is necessary to express thoughts that you don’t have good words for ramps up dramatically and the effort necessary, and making sure that you’re on the same page with everyone, scales up just immensely. And oftentimes it takes huge amounts of work to even recognize, “What am I talking about here?” I mean, its language is a tool. Ultimately, it’s, you know, human beings invented language as a tool because man, it makes certain things so much easier. And it’s like having the right tool for a particular job radically alters how difficult it is. And yeah, that’s it. So that fascinates me too, because we’ve talked about this idea of getting the team coordinated around using a shared language to talk about things. And I sort of think of that as like language about stuff like, you know, the language of accounting, you know, has certain jargon and stuff like that.
Todd Nienkerk: Gross doesn’t mean icky, it means topline.
Jeff Eaton: Exactly. And you know, and those exist as a convenience for practitioners to work with each other quickly. And that’s great. There’s also the flipside of it, though, is the language of something. Like the language of cinema is, you know, there’s the language about cinema, which is how critics might how critics talk about things, right? But the language of cinema is like, what does a close-up shot do? How is it used to communicate meaning when a filmmaker is actually constructing a series of shots? What does it mean to have a narrator say something as someone’s walking down the street versus having a character say something? What does it mean? And you know, that’s what people talk about, like the language of cinema. And it takes language-like things like film or whatever to tackle that language and there’s a distinction between them, because once you get to there, what you’re working on is not just shorthand ways for practitioners to talk to each other, but like the actual toolbox of things that a practitioner uses to communicate to an audience who aren’t necessarily practitioners. This isn’t like we’re describing the film. This is the film itself.
Todd Nienkerk: And so, for example, your close-up example is really good, and it just so happens that I studied psychology and film. So we’re right at the intersection of my early 20s interests.
Jeff Eaton: And Dan Olson, the host of the Folding Ideas YouTube channel, actually has a fascinating little explainer video on a concept called ludonarrative dissonance, which is like games, criticism, and analysis.
It’s like when the mechanics of a game disagree with the message of a game. Let’s say you’ve got a game and the storyline is all about how capitalism is destroying the world, but the mechanics of the game has you collecting coins for doing stuff. Unless you’re doing some sort of real weird irony thing, you’ve got a fundamental collision between the messages that the mechanics are communicating and the message that the story is communicating and like that tension is there and it can exist in cinema too.
Like if you’ve got a script that you’re like. In his video, he uses the movie Transformers 2. I think as an example where, like Megan Fox’s character on paper, as the script outlines, is an incredibly competent machinist and mechanic who, you know, basically saves the day dozens of times and is hyper-competent and is the core of agency, right? Yes, and yet in the film, as shot, she’s eye candy—like long, lingering shots, walking up her legs as she, you know, fixes Bumblebee the Transformer, you know, stuff like that. And there’s a deep disconnect in what the film, what the visuals are saying—
Todd Nienkerk: Because the language film takes those kinds of shots and it conveys to you: Sex symbol; this is something that should be wanted. Maybe there’s not a lot of depth. And yet the script is written that this is an intensely deep character.
Jeff Eaton: Exactly. And there’s a tension there. The question isn’t, is it bad or is it good? That’s a whole nother kind of, you know, that’s a whole other school of criticism. But it is possible to look and say, well, these are two languages.
There’s the dialogue, the story, the script, there’s the visual language that’s there and they are colliding. They are not on the same page. And that is what we have been finding is more and more organizations that have like a design system that’s been built by one team, content architecture that’s been ironed out by another team, and CMS assembly tools that have been built by another team, even firing specs and feature requests over the wall back and forth. Oftentimes they are not in agreement with each other. They may work with each other. Just like, you know, Transformers is a complete and functional film. It, you know, it is there. It does exist and is, in fact, a movie. But its component pieces aren’t working together effectively, and they’re in disagreement.
And you can find that in so many scenarios where like, “Oh, well, they sort of hammered those six design components into place because they needed to do X. It’s not really what they want,” or, “You know, how we’re using this for X, but it’s really meant for Y.” Those are all symptoms. They’re like, you know, the like in software development. It’s called “code smell”—the signals that something’s not right under the hood, even if it hasn’t broken yet. Like, those are symbols of different conceptual language-like tools that are kind of hammering against each other rather than working in conjunction. And it’s a fascinating thing to try to start teasing out what the shared things they’re trying to do are that can be coordinated around. It’s fun.
Todd Nienkerk: And you’ve done a really good job bringing us back to your work with Autogram and what I find so interesting that the confluence of content architecture, design systems, governance, all these things, you know?
Design systems being used by a certain type of skill set, but then these other tools being used by another and how do we find how do we work together more simply? Looking to the future, do you see that these differences are going to fade away and that we will coalesce? Do you see that there will be a fourth entrant into the ring? And if so—
Jeff Eaton: Kind of, but I have no idea what they’ll call that fourth entrant. But you know, I think who owns that probably depends on the organization, depends on like, you know, what they’re doing, what they’re building, what their goals are, what makes who makes sense to sort of shepherd, not the script, not the shooting, not the storyboard, but the story. Like the showrunner. Like for a show, the showrunner’s job is not to write every episode. The showrunner’s job is not to, you know, coordinate every shot. It’s to make sure that all of those are working together effectively for the show. And I think that role for digital projects in some teams, it’s like the product manager or the product owner.
But like, you know, organizations that have those roles, it feels like oftentimes they’re just, you know, just keeping their heads above water, you know, trying to be glorified project managers for, you know, in a lot of organizations.
Todd Nienkerk: But they don’t necessarily have the authority to speak on behalf of the vision of the organization, or the business outcomes, or whatever.
Jeff Eaton: Right. And I think recognizing that is something that needs to be clarified and articulated and understood and like tended to—you know, gardened, so to speak—for an organization, especially one that’s operating at a scale where it takes lots of different, you know, the actual realized version of that messaging takes lots of different forms and, you know, has long-term repercussions. We’re going to keep this stuff around for a decade and we’re going to have to live with it. You know, I think it’s becoming more and more apparent that that needs to be there. Oftentimes, a content strategist who’s brought in to help ends up owning some of it just because they’re doing a bunch of auditing and trying to start writing up guides. But like that doesn’t necessarily at least from what we’ve seen, content strategist rarely ends up having visibility, let alone authority into how the design systems team inside of an organization is conceptualizing the visual vocabulary of how we create things and how we create new things. But getting everybody onto the same page and making sure that we’re all working towards solving certain kinds of problems, communicating certain types of messages, different kinds of things that we care about emphasizing or tailoring to, you know—knowing those kinds of shared purposes matters a lot. And it’s not something you get simply from picking a team and saying, “OK, everyone has to use your system.” You know, you can get lucky, but you don’t necessarily get that unifying, showrunner-like approach to things from just saying, OK, the directors, you know, they’re the cinematographers in charge of everything.
Todd Nienkerk: I’m really glad that you came back to the film metaphor, and perhaps we should leave it with this final thought. It’s occurring to me, I spend a lot of time thinking about our industry as a whole and how, you know, it’s not very old as far as industries go. It’s not like accounting, which began, you know, when numbers and counting systems were invented and people needed to track debts and quantities and logistics and all that stuff. This has been around not long—
Jeff Eaton: And even with numbers we know in history when we came up with the idea of zero.
Todd Nienkerk: Yeah. Yeah, exactly. So, you know, let’s be generous and say that our web design industry really got started in earnest in the ’90s. So we’re still looking at between 20 and 30 years that we’ve even existed. It’s nothing in the grand scheme of things. But you look at filmmaking. And so I wonder back in the day, I feel like I should know this because I did go to film school, but the late 1800s, that the Lumiere brothers and all that stuff happened. Let’s say it’s late 1800s or so. That was a time that was dominated by a different paradigm, so theater, right, and so lighting techniques and makeup techniques and the way scenes were constructed, and of course, there wasn’t dialogue, but they relied heavily on music and title cards and all of these things. It was all of these other skill sets that suddenly had to come together in a space and do a thing that they’d never quite really done all together before. And now we look at the film industry and it appears, as somebody on the outside—and I bet somebody in the industry would tell me I’m way off about this—but it seems like they’re pretty well-organized and they figured out like there are pretty defined roles. And if you look at the language—not the language of cinema, but like the language internal to the Filmmaking Act—the language about filmmaking and cinema, they have these great terms.
There’s like the grip and the key grip and the best boy and like PA one and PA two and squibs. And like, you know, squibs are the little things of blood that pop, there’s a name for that! Of course, there has to be a name for that so that nobody gets confused and screws up an expensive shot where things blow up and break and people are put in danger. So you would better know that that thing I’m going to attach to you is this little capsule of blood that’s going to explode. They have developed over the decades and decades and decades a language, and I bet at the beginning of all of this when they were all getting together and the cameras were basically still being invented, and film was still being refined as— By film, I mean, the actual cellulose silver nitrate product that—
Jeff Eaton: Let alone the industry and the media.
Todd Nienkerk: Yes, I bet there was all kinds of confusion. Like, well, who is responsible for lighting? You know, like, OK, is it the director? Is it whoever? I don’t know how theater works, so I know that there are lighting people in theater. But I mean, that’s sort of a stage director, but there isn’t a stage director in film.
Jeff Eaton: And the person in a film who’s in a shoot who’s responsible for making sure that there’s continuity from shot to shot. I forget the name of it. Like, you know, somebody moved that Starbucks cup on the desk. You know where you were about to—
Todd Nienkerk: “Yesterday when we were filming the scene, you were holding that in your left hand.” You know, that’s somebody’s job.
Jeff Eaton: And there’s actually— Once again Dan Olson of Holding Ideas has an episode on this, but there’s a Russian filmmaker from the 1920s, I think it is who actually ironed out all kinds of like— He took the first stab at articulating even things like a reaction shot where somebody is on the left side and they’re talking, and then you cut to somebody on the right side responding to them and then you go back like that pattern of how you do a conversation in film. We don’t even see that anymore. It’s just how you do it, and it feels weird if somebody does it in a different way. Ironing out those kinds of practices is a process, not just something that springs fully formed from, like objective reality in the medium.
And I do think, like as a practice broadly, we’re still chewing on answers to a lot of those kinds of questions. And every single time we hit some sort of big “Aha! This is the next tool that’s going to solve the problem,” you know, we unearth the next round of head-scratching challenges, since it’s actually being used to communicate complicated stuff.
Todd Nienkerk: Yeah, yeah. Thank you so much, Jeff, for your time. I truly appreciate it. It’s always fun talking with you and has been for years and years and years, but especially today. I really appreciate it. How can our listeners learn more about you and Autogram and what you do?
Jeff Eaton: Well, I mean, you know, the easiest way is to go to our website at autogram.is. “Autogram is”—that’s enabled a whole swath of novelty URLs for us. We’re on Twitter @auto_is. But most of us, you know, you know Karen McGrane and Ethan’s on Twitter as @beep and I’m on Twitter as @Eaton will often be there just weighing in on random, you know, technical or cultural issues of the day and shitposting or whatnot. So, yeah, you know, if you’d like to just strike up a conversation about something interesting, Twitter is great. If you’re interested in the kind of stuff we do tackling these problems with organizations, check out the website at autogram.is. And I think, you know some of the stuff that I’ve put together and about the stuff and talks and stuff like that, I think some of that is linked on my own website at eaton.fyi
Todd Nienkerk: And that’s E-A-T-O-N.
Jeff Eaton: Dot-fyi. Three cheers for novelty TLDs.
Todd Nienkerk: I know, right? Somebody decided to turn on the money-printing machine over at ICANN or something and like, Oh great, now I have to register all these? Thanks.
Well, on that, I’d love to hear from you. Yes, you, dear listener. What do you want to learn about the future of content? What are your favorite top-level domains? Feel free to send show ideas, suggestions, or examples of the content you create. You can email me at future@fourkitchens.com. We’re also on Twitter @FoCpodcast.
To learn more about Four Kitchens and how we can help you create, manage and distribute your digital content, please visit fourkitchens.com. And finally, of course, everybody’s always telling you: Make sure to subscribe to The Future of Content so you don’t miss any new episodes.
Until next time, keep creating content.
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!