We’re Done With Dumb Content
For the entire history of the web so far, we’ve generally handled content in two ways.
- Basic, one-size-fits-all pages, or
- Complex, custom pages
We thought this made website planning easier. As it turns out, it’s just made it dumber. The conceit of this approach is that for any content or content arrangement that can’t be done using a basic content area and its friendly WYSIWYG editor, we can create a custom template with its own set of fields and logic. In the old days, when most content was quite at home in a single column of text with the occasional image here and there, the idea that special content could have its own definition in the CMS and its own, unique template seemed quite sophisticated. We were crafting this content just so. Had we known better, we would have called it “artisanal.” Maybe then it wouldn’t be so obviously outmoded today.
Of course, it would still be dumb.
No single name — no matter how trendy — would change the fact that, over the years, we’ve accumulated a long list of distinct types of content. Each one comes with its own conventions, both in terms of the specific information it contains as well as the manner in which it’s presented. A blog post, for example, may have many of the same informational attributes as an article, a whitepaper, or a case study — a title, author, publication date, abstract, text, images, comments, etc. — but it usually has a visual format of its own. In fact, it is often the visual attributes that most clearly differentiate one type of content from another.
That the list of content types has grown is not a problem, really. Each one meets a unique need and wouldn’t exist if differentiation wasn’t useful. The problem exists with the formats. The basic, one-size-fits-all page isn’t really suitable for any of the types of content we care about. So we’ve created a unique template for each one. There is the problem: template bloat. The more templates that exist, the more rules we have to follow when we create content, the more logic we have to keep track of within the CMS, and the more production work we have to do to create and maintain them. After all, with so many specific layout decisions being made before much content is created, the likelihood that we'd later feel restricted by our custom templates and want to change them is very high. Template bloat is inefficient, expensive, and most importantly, frustrating.
There is a solution. Six months ago, it existed as a sketch in my notebook. Now, it’s a core part of our CMS. Many of our clients are already using it and loving it. I want to show you how it works. I suspect that if you're not already, you’ll never think about content the same way again.
First, I need to dig deeper into a few things — like templates and design and expectations — which is going to take some time. If you're in a hurry and need to cut to the chase, go ahead and skip down to the heading "We Need Modular Content." But promise me you'll come back and read the whole thing, OK?
Content Management or Page Management?
Content management and page management are two completely different things. Unfortunately, most of the time when we're using a CMS, we're entering content into page-specific field sets. We're giving the page what it wants.
I'd been thinking about this more lately, after having used our new system — the one I'm going to show you later in this article — because I now had an experience to compare with what I've been used to for years. Having been far too close to CMS development for years, it suddenly became clear to me how real that user frustration I've always heard about truly is. In fact, just the other day, Mark Boulton put it quite well:
So many content management systems are designed for developers first and content creators second.— Mark Boulton (@markboulton) January 8, 2014
Huge swathes of the CMS industry are out of touch with how people are making and editing content.— Mark Boulton (@markboulton) January 8, 2014
Mark is absolutely right.
How we think about the architecture of content management systems inevitably trickles down and influences how we think about the formatting of content. The CMS tends toward analytical organization of content — types with differentiated fields, structure, and logic — but we think in terms of narratives. Simple, human, story-based content structures based upon a flow from need to experience to outcome. This is an obvious mis-match. When we plan the information architecture of a website — itself a highly analytical process — we anticipate what the CMS can do and we align our planning to those capabilities. That's where our type-orientation comes from. It's the technology reaching back into the planning and creative processes, when it should be waiting to respond to what those processes produce.
Here's a pretty simple example of that: I use WordPress for my personal site. It’s a breeze to set up. I had the entire structure created and configured just how I wanted it in a matter of minutes. But while creating the structure of a site like mine is relatively simple — which seems like a good thing — I’m quite limited in terms of what I can do with the content my site will contain. It was the easiest box in the world to build, but as it turns out, it’s a pretty small box. That's great for WordPress developers. It keeps the variables low and the stability high. And ultimately, it's OK for me, too. I don't have much need for more than the one-size-fits-all content type. But it doesn’t even come close to what my clients need. They need much more than a simple box. My guess is you do, too.
By the way, this is why your house looks different from my house.
Uh oh. I'm about to make a websites are like houses analogy. What the heck. I’m going to do it.
Imagine you're designing a new house.
Now imagine that — after the bedrooms, bathrooms, living room, kitchen, and dining room — you only had one spare room in this house. You might use it as a guest room, a home office, a nursery, storage, or something else. It's up to you. Now having that spare room sounds pretty good, right? But what if you only had one chance to choose and arrange the furniture for this room? I don't know about you, but I'd probably hold off on buying any furniture and arranging this room until I had a better idea about what I was going to use it for.
This is the dumb, one-size-fits-all approach to content. When we don't know what to plan for, we make our baseline the simplest thing. That seems reasonable enough, but when we don't make specific design decisions for the space in question, it can become anything. Most designers are not happy with that.
OK. Back to your imaginary house.
This time, imagine you can have as many rooms in your house as you want. You can have your guest room. And your home office. And your nursery, your music room, your dojo, your room for dreaming up new rooms. You can have all the rooms. This also sounds pretty great. Except that you'll quickly end up with a very large, strange, and nearly impossible to maintain house.
This crazyhouse is the template-bloat approach to web design. Sure, it sounds ridiculous, but the trouble is that large, sprawling, and strange content houses don't seem so absurd in website planning meetings. On the contrary, they seem like the right thing to do. They even look very professional, what with all their neatly arranged boxes and arrows.
I took inventory of all the prototypes we've built over the last year, and I found that the typical template count was somewhere between 15-20. That is not including generative screens like thank-you pages, alerts, or steps in an e-commerce funnel — the sorts of pages that can be covered by a good style guide. These are unique templates that anticipate unique forms of content and arrange that content in all sorts of combinations. Each one of these would need a unique layout, so we're talking about 15-20 composition files that a designer would have to produce and take through approval. (That is also not including the alternate versions of these templates designed for mobile devices.) Having seen personally how the production process has become longer, more expensive, and more stressful in recent years, I'd say that 15-20 templates is way too many.
We need to trim the fat. Something called modular content is going to help us do that. More on that in a bit...
So, to review, reasons why designing unique templates for every type of content we create is wasteful and needs to stop include:
- Content creators are forced to think about layout too early. Thinking about how content will look is generally less productive until you are already clear on what the content is, why it's needed, who it is for, and a variety of other practical considerations having to do with who creates it and how often it's produced.
- Designers' workload increases significantly. In addition to having to create many unique templates, each one requires a review and approval process that makes following a narrowing funnel of design decision making much more complicated.
- Content management is too difficult. Content management systems tend toward analytical organization of content by type, which means that as the types grow in number, the methods of connecting them become more complicated and labor-intensive (e.g. Create a new page, save; create a slideshow, save; create an image, save; associate the image with the slideshow, save; associate the slideshow to the page; save. etc.).
- Maintenance is too expensive over the long-term. The chances that you would want to change the layout — or even a small detail within a particular layout — after you've become accustomed to creating content is beyond high. It's practically a guarantee. But with 15-20 different templates, the cost of the developer's work to implement that change could be way out of scale with what you expect to pay.
But what about ______ ?
I know. There are many examples you want to show me right now that are completely blowing your mind but that you know can’t possibly be the result of the dumb or dumber way of content management. They're not built on a one-size-fits-all content bucket, nor are they some sort of complicated content type aggregator. They're... something else. Something new. Something that almost seems the result of some kind of web magic.
Well, you’re right, there is a third way. It's not dumb. It's custom — very custom — and I need to take a moment to get into a bit more detail in order to explain just what I mean by "custom" in this case. It's necessary because, unfortunately, this third way is the form of content that is framing this entire conversation. It’s stuff like this, from Globalpost, this, from Pitchfork, and the Grandfather of them all, this, from the New York Times. That last one — the New York Times Snow Fall piece — made such a splash that creating media like it is now referred to as "snowfalling."
These pages marry the beauty, detail, and diversity we’re used to from print to the responsiveness and interactivity we’re used to on the web. Many of them are simply works of art. But darn it, they are thorns in a designer’s side. Why?
Reasons that snowfalling is setting a bad example for web design:
- It is distracting. Content like the New York Times and Pitchfork pieces represent an imbalance of design for attention — it's design for spectacle. How many people who viewed the Snow Fall page actually read all the Snow Fall content? I wonder. It is clear that there is an important delineation between the two. I have my doubts that 3.5 million people actually read the thing. Now, would either story have been satisfying and effective without the glitzy HTML5 effects? Yes. That means they didn't really need them.
- It is expensive. Snow Fall reportedly took 6 months and a team of 16 people to make. Was this a worthy investment? Plenty say no. But that's not the point. The New York Times can do what it wants. The point is this: Who among us has such a wealth of resources? Who among us can wait that long to produce content? Right.
- It is custom. Custom with a capital "C," people. Custom, as in, not CMS-able! These pages are the result of a team of writers, designers, and programmers sitting very close to one another for a long time and making something spectacular. Whether it’s a single page, or a series of pages, is irrelevant. These are unique media; the structure and the content are inseparable. Even if you were to copy one of these pages to reuse for another piece of content, the relationship between text and image, how and where interactive elements are placed, and the overall layout in general would probably be entirely redesigned for the purposes of whatever piece of content is being produced next. In other words, these are not templates. They are the antithesis of a template.
Incidentally, I asked Jon Lax of Teehan+Lax — who produce beautiful case stories in similar (but entirely appropriate as far as the degree to which their design contributes to the reading experience is concerned) fashion to the news and media pieces I’ve referenced — what it takes to produce them. Jon Lax replied:
@chrbutler it takes a team of about 4 (2 designers/1 dev/1 partner) about 2 weeks 100% to create one. But each one gets a little easier— J.La (@jlax) December 20, 2013
I don't know what your hourly rate is, but let's just say that good content — the stuff of Teehan+Lax's ilk — is expensive. You must make your own assessment of how much time and/or resources you're willing to put toward your content. If Snow Fall inspires you, great. If Teehan+Lax inspire you, even better. But know this: You will never produce content of that caliber without making a commensurate investment.
And you will not find a CMS that just "does" that sort of magic, either.
Making Peace with the CMS
Their analytical faults aside, content management systems use templates for a good reason. They do this so you can have a simple tool to "add this" or "add that," which is built upon your having already determined what "this" and "that" are, which, in turn, makes adding "this" and "that" a lot like filling out a form. It's supposed to be like that so that you can do it over and over again and know what to expect. CMS tools are like mad libs. They’re set up so that content entry is simply a process of filling in the blanks. Title here. Abstract here. Content here. Images here. Video here. And when you fill in those blanks, the CMS puts that stuff where you expected it would be. When you add a video, it will be either on the left or right of the page and text will wrap around it because that's what you told the system to do. When you add an image, it will either display “full bleed” across the content column, or align left or right because that's what you told the system to do. These rules and expectations are what make a template a template, and templates are — for better or for worse — the currency of the CMS. They are what make content production possible for people who either don’t know how or don't have the time to design things in Photoshop and then build them with code. If you can’t commit to rules, fine. But then you are looking for something custom — something that will not scale without writers, designers, and developers to make that happen.
Unfortunately, I haven't met many designers that understand all of these things — the fundamental restrictions of the template and the custom nature of Snow Fall — and aren't still frustrated by having to conform their creativity to content management systems. I can't tell you how often I have to deconstruct creative expectations set by media like Snow Fall. I get the frustration. But just because you want something you can see right before your very eyes doesn't entitle you to ignore all the practical aspects of how that thing works or was created in the first place. Designers, it is our responsibility to give deep thought to how content will be created, how it will be managed by way of whatever CMS has been chosen, and how it will be sustained over the long-term.
It is simply irresponsible to design a website without giving serious thought to content management.
This is why so many designers and developers feel that snowfalling isn't such a good thing after all. It sets expectations so high that reality can rarely be anything other than a creative downer.
At this point, a few of you might be thinking, "But what about Medium?" Content produced on Medium is beautiful. Medium lets you compose stunning pages similar to Snow Fall with about as much ease as I could ever imagine. How do they do it? Doesn't the existence of Medium show that everything I've said so far is bogus? In short, no. Here's why:
Here is a page I created on Medium in about five minutes. You’re going to need to sign in/up to view it, so if that’s too inconvenient, here’s a screenshot:
Looks great, right? And it's kind of fancy, like my own little Snow Fall, right? No, not really.
- Medium is a content management system with one template. You can add text and images in various — albeit darn fancy combinations to one page. That's it. Medium does not produce content like Snow Fall because (a) it is a content management system — recall that Snow Fall is a custom piece of media with no CMS behind it — and (b) it is specifically a blogging platform that keeps its content close. If you put it on Medium, it stays there.
- Medium's template only makes sense for Medium. If you were to copy Medium's template, you would have a page with no header, no navigation, and no calls to action. Designing a beautiful page is a whole lot easier to do when you don't have to think about how that page fits into a larger, more complex information architecture.
- Most importantly, Medium is not your website. It's Medium's. Anything you put there belongs to them. Medium is a CMS like Blogger was a CMS. It's a system for creating and adding content to a platform that hordes your content.
So we can all stop drooling now.
Don't get me wrong. Medium is very cool. The user interface is about as minimal and intuitive as I could imagine page-editing to be. Medium excels because it’s simplified what many users want out of the content creation experience. They've made it stable, streamlined, elegant, and standardized. It’s a CMS with one nifty content template. But comparing it to a CMS used for business purposes is obviously not an apples-to-apples comparison.
So to wrap up, content management systems work with templates. They can have one template or many. If you can't do what you want with the templates — if they're holding you back creatively or technically — then you either have to standardize that thing and create a new template for it or go rogue and leave the CMS to create something custom at a greater cost in time and money.
No wonder designers hate content management systems.
If we are going to make any progress with content for the web, we are not going to do it by creating a new template or even a new type of content. We are going to do it by changing how content management systems work.
That's where — finally — modular content comes in.
We Need Modular Content
Creating content today requires an incredible amount of planning, work, and flexibility. At the forefront, we need to spend a lot of time thinking through strategic considerations in order to make a plan that suits our audience and goals. The work to produce the content we've planned for is considerable. Every word and image take time to craft. But, as necessary as it is today, flexibility — to change what we say, how we say it, and to whom — is often the thing that puts enormous pressure on the work. This is especially the case when there are technological barriers to being flexible — like that the template won't let you do that thing you want to do because when you designed that template you didn't know you'd ever want to do that thing.
We need a way of handling content that takes some of that pressure off — that doesn't expect us to have planned for every possible thing we might want to do and manifest those million details in a complex and feature-bloated template. We need something that enables us to be creative at the right times and not have to resort to custom solutions outside of the CMS. Lots of people are working on solving just this (we're not the only ones), but we've got a long way to go.
We need our CMS to provide content creation tools that:
- Prioritize content without deprecating design. But unlike some of the snowfalling we've seen, we need something that helps us maintain a balance of design for attention. What you’re communicating is too important to be undermined by flash. You need a tool focused on supporting your thought leadership.
- Offer a real return on your investment. That means they make creating and managing content easy and enjoyable enough that you’ll actually do it as regularly as you planned to. And that it will get easier over time.
- Reduce template bloat, scale well, and provide stability.
We need modular content.
Remember that sketch I mentioned earlier? Well, after reflecting upon all of this — the struggles we have with designing web content, the pressure we feel from outside influences, and the stress of trying to keep up with them while not going broke designing millions of new templates and banging our heads against the limitations of the CMS — I drew a picture of what I thought the ideal "template" might look like for our platform. I slept on it. The next day, I thought a bit more about how a "template" like that might work within a content management system. I thought about what it might do well, and what limitations it might have. I put all this up on a whiteboard.
Then I talked to Dave. He liked the idea. He even thought of ways to get rid of some of the limitations I thought might be necessary. (So note, the limitations I listed on the whiteboard do not apply. That's why you always talk to Dave!) I suggested that we start working on a proof of concept and regroup in the next few weeks. Dave agreed. A few days later, he surprised me with a fully functional proof of concept. It was useful and stable enough that within a week or two, we were already using it on some existing client projects. Meanwhile, I worked with Lauren to get a standard prototype built that we could use to demo this thing to the rest of our clients.
Our little team of three had taken our CMS to the next level — and completely changed our approach to content planning — in less than a month. Amazing. Now that it's part of our toolset, every single one of us is contributing to improving it.
So here's what it is and how it works. As it turns out, it's not a new "template" after all. Its a new way of building content.
How Modular Content Works
Rather than one open content area — in which you could put text and images using a WYSIWYG — or a template that has pre-determined text and media "buckets," modular content allows you to add any content — text or media — in blocks. It supports building pages ad-hoc, adding text and media as you need it in a variety of combinations. After you've stacked a bunch of these content blocks, you can re-sort them any way you like. It's basically content Legos.
To be clear: the example above isn't showing every possible combination of text and media in a block. You have full control over these combinations. You can create blocks simply containing full-width text, or text in two-columns, or text and images (in all kinds of orientations), video, text and video, slideshows, or slideshows and text.
Some more examples would probably help to get the picture.
Each of these pages — whether as simple as a text article or as complicated as a landing page chock full of text and media — could be assembled in just minutes using modular content blocks in the CMS. This means that modular content can be used to create any or all of the following "types" of content we typically create using individual, unique templates:
- blog posts
- long-form articles
- case studies
- landing pages
- employee bios
Sounds simple enough, right? Of course, most content management systems sound like they're simple to use until you actually get in there and try to use them. In this case, I think what we've put together is about as simple as it could be. Here's a peek at how it works:
I think modular content is a pretty exciting step forward for the web, web design, and content management. It can change so much of what we do, which is a great thing! With modular content, you don't have to commit to where images or text or any other media will appear on a page until you are creating that page! You don't have to worry about catering your content to a structure that already exists. You can just create.
While this introduces major efficiencies into the information architecture planning process — with modular content taking the place of many individual templates that would otherwise have been designed — there will still be plenty of content that will need unique templates. For example:
- You'll still design unique templates for home pages
- You'll still create style guides for list and grid arrangements that support all the pages that aggregate other content, like blogs, articles, videos, products, etc.
- You'll still design templates for content that has much more complex attributes and extensive information architecture needs — things like product pages that might include tabbed interfaces to layer information, reviews, order forms, and logic that pulls in other product information based upon user behavior or product metadata.
But for all the content we create that is Taco-Belling text and media, modular content is a perfect fit. You can take all the time you'll save by not having to worry about unique, complex templates for that content and put it toward careful and thoughtful design elsewhere.
This won’t be the last time we rethink content for the web. It certainly isn’t the first. And really, it’s not an invention so much as it is a way to finally make possible what most content creators have already invented in their minds and were bitterly disappointed to find out that their CMS couldn't do. Let's all work on this problem.
*Note (01/13/2014): After seeing a few comments on Twitter, I wanted to bring greater emphasis to the fact that this article is not about claiming to have invented modular content. Modular content exists in the minds of every content creator out there. The problem is that it doesn't fit through the doorway of most content management systems that those creators are using. This article is about that, and our particular solution to the problem. As the comments string clearly shows, we're not the only ones working to find a way to make modular content a CMS reality. We are less interested in claiming ownership over ideas than we are in serving our clients well. This is just one way we're trying to do that.
* Note (01/15/2014) A lot of people have been commenting/asking how they can implement this type of content approach on their own, non-Newfangled site. While the example we show is unique to our (non-licensable) CMS, there are several plugins available for WordPress and Drupal that, when installed and configued, provide similar functionality.
Perhaps the most feature-rich out-of-box option, is the Divi WordPress theme. If you’re a developer, and want more control over the block types and templates, take a look at the “Flexible Content Field” option, an add-on to the Advanced Custom Theme plugin. Both of these are paid solutions, but the cost is negligible compared to the benefit they provide. For Drupal, you can check out the Layout project. It’s a bit more “rough” than the two WordPress plugins I mentioned, but offers a greater level of granularity.