in Digital Media

Your CMS Sucks. Here’s Why That Matters.

My last post diagnosed some of the problems that can get in the way of good content strategy. I argue there that one of the main culprits is a lousy content management system, which leads to:

  • Content that isn’t adaptable across platforms.
  • Processes still driven by the needs of print.
  • Enterprise content management systems geared toward facilitating the sharing of documents.
  • Online CMSes that are uniformly hard to use.

There are no one-size-fits-all answers to the problem. But last week’s An Event Apart conference helped to point me in the right direction. I remarked at the time that there seemed to be a nice convergence between Kristina Halvorson’s advice to add page tables to content strategy and Karen McGrane’s call for a better-designed CMS. Having had a few days to process, I’m even more certain that there’s some real there there. First a bit of context.

Page Tables: Wireframes for Content

Most designers are familiar with the concept of page templates, which are usually wireframes that show page layout and functional requirements. When it comes to content, though, page templates typically features variations on lorem ipsum. (Samuel L. Ipsum is my personal favorite.)

Halvorson encourages designers to add page tables to their documentation. As she explains them in Content Strategy for the Web:

The page table tells you everything you need to know about the content on a specific website page (or content module)—from the objective and source content to the content recommendations and their implications, including requirements for creation delivery, and maintenance.

Example Page Table

Page tables go beyond design. They tell the users precisely what content will appear in each part of the page. For those managing relatively small sites, there’s a page table for every page. Those managing larger sites (e-commerce or news sites, for example) will have a page table for each type of product—a template that explains exactly where each piece of content lives. A page table more than just a display of the different content areas on a page. It is a description of the actual content for each of those content areas.

(Note: Page table example is from Attention, Message, Action.)

Content Management: Write Chunks, not Blobs

For many organizations, simply having some page tables would be an improvement. The real power of a page table, though, lies in the way that they can inform our content management systems.

McGrane’s AEA presentation discussed the case of NPR, and its philosophy of Create once, publish everywhere. NPR manages this feat by structuring its content. Authors write in chunks rather than in undifferentiated blobs. And that writing in chunks starts with a CMS that requires chunks rather than blobs. Check out the (blurry, but legible) peek into NPR’s content management system.

NPR's content management system

Isn’t that a thing of beauty? Authors creating structured data. That data is then fed into an API which in turns pumps delicious xml content to, to the iPhone app, to affiliate websites, to iTunes, to the NPR mobile site, and so forth. Because the content is media-agnostic, it’s ready to get ported into anything…including whatever that Next Big Thing turns out to be. 

From Content Strategy to Content Management

Here’s where the real power of page tables come in. All those lovely page tables that explain exactly what content goes in what section can be used to build content management systems that break our content into chunks.

In a nutshell, a content management system like NPR’s, when paired up with a robust set of page table templates, allows metadata to replace art direction. Content creators will no longer design documents. They will create content. The CMS will do the organizing for the content creators: Creators decide what things are important, put those things into the correct fields, and then let the template—not the CMS—arrange the display.

That does mean giving up on controlling how my content appears on the web. But, then, it’s not clear that we ever really had control over how our content appears online. With the advent of tools like Readability and Flipboard, we have even less than we used to.

We can’t control appearance. But we can control importance. Metadata allows us to prioritize content, and it allows us to communicate those priorities across platforms that we don’t control.

For any of this to work, those priorities have to be baked into the process. And that means building them into a CMS that your creators can actually use.

Write a Comment


  1. For those who have been working with API-driven (or data driven) applications, this is not a new school of thought. Twitter sort of took us out of the mentality of using the service exclusively through a single interface, and it has helped drive the platform. This has a lot to do with the architecture behind it, but a lot of developers are starting to realize the importance of serving data to everything outside of the application.

    What bothers me the most is that issues with the traditional CMSes out there are well documented, and pretty much everyone knows that something needs to change. Unfortunately, nothing is really happening. I’d love to see some of these thought processes applied to something like Drupal 8, but after talking with Karen at the conference, it looks like it has been spelled out for the developers. Something has to give.

  2. I suppose in an ideal world, all clients would have the exact same needs and have a fundamental understanding of data structure and how it’s presented on a plethora of devices and syndicated content platforms.

    The reality is, the majority of clients *want* complete control over what they can put on a page and exactly where they want to put it.

    I don’t see how the above example CMS can serve that requirement in any shape or form, without absurd levels of complexity. I’m thinking about this, however – there’s some inspiration gained from reading this and the previous article.

    We’ve *tried* to educate clients about structure, about conformance to a more rigid approach to positions of items in a layout, about the ability to share data across different platforms – but the client pays the bills. If they want a video in-between two paragraphs of text, that’s what we end up providing.

    Most CMS systems suck because ultimately, the client demands control – “we’re paying for this, we want to put a PDF download *anywhere* on our page, complete with icon, pop-up window and instructional video!”

    So we furnish them with wysiwyg editors where they shove in blobs and try our best to educate.

    From my perspective – probably because standing at the coal face, with the thin edge of the wedge pointed in my face – what you propose seems theoretical for most purposes – or does it?

    Probably the best example of a flexible bespoke CMS system I’ve used, is one where the client can shift chunks of data around in a page layout – whatever that data may be. A download, a video, a paragraph of text or an image.
    Taking that one step further, perhaps there *could* be a method to achieve what you propose – but I can’t see it taking any of the complexity out of managing data in a CMS.

    The ultimate CMS system would be one which offers complete flexibility of data layout in addition to the “Create once, Publish everywhere” approach.

  3. Nic,

    I agree entirely that there’s nothing particularly new about the concept of separating content from presentation (which is really all this boils down to.) The whole promise of the CMS was precisely that: Eliminate the hand-coding of pages, get the content into a database, and let CSS take care of the presentation.

    I think that the real problem isn’t with the developer community or the design community. It is (as Matthew says) with the end users who want their CMS to behave exactly the same way that Word behaves. That seems less like a technology problem and more like a people problem. We can make the technology a little (okay, maybe a lot) more user-friendly, but all the UX in the world won’t help unless we can also get content creators to stop thinking “Word Document.”

  4. Matthew,

    I’m totally with you. I am in-house. I’m fully aware that the problem isn’t in getting the developer on board, it’s getting the content creators on board.

    Just last week, as I tried to explain to someone why I can’t surface content inside PDF files differently on different parts of our website (at least not without a great deal of custom scripting), I was met with the rejoinder: Well I can type all these things into Outlook and it says that it’s HTML. I don’t understand why you can’t just do that on our website.

    But I totally agree that this is what clients want. But they also (at least around here) want to be on the iPhone and ePubs. And they want people to read all their stuff. What they’re discovering (very slowly) is that throwing up 200-page PDF files isn’t accomplishing those goals. My team is really small, so we are legitimately in a position to say, “Look, you can have complete control over how your content looks and provide it in exactly one format (one that, incidentally, no one outside of our walls is using to access our content), or you can give up that control.”

    The only place where I’ll take issue is with your last paragraph. I think it will (eventually) sink in to clients that end users get to control how content appears. It may take some time, but I think that eventually content creators will agree to give up the art direction part of their job and focus purely on content. Eventually.

  5. It’s good to see I’m not alone in facing what can only be seen as a serious lack of education client side – and it’s up to us to try to educate them.

    It’s also Account managers who require education, to try to prise them away from that really old ‘Websites for Dummies’ book they enjoy quoting from.

    The idea that the internet is a moving platform – quite literally – really hasn’t dawned on a great many people – as usual, they are exceptionally far from the cutting edge.

    In many agencies, there’s still a desperate clinging to web being given the same treatment as print – the fear of ‘losing control’ of the data, the design, the layout.

    The insane mantra “It must look the same across all platforms”

    What Joe proposes in this series of articles would completely sail over the heads of the current accepted methodologies that many agencies hold – just when they thought they were getting a grip on this web design malarky, along comes a host of exceptionally talented individuals collectively pushing the boundaries of what the internet represents and how best to present content.

  6. Correct me if I’m wrong, but I think Django already solved this problem. Use a thoroughly tested web framework to write models of real-world kinds of data. A news article (like NPR above), a photo, a video, an audio file, a government document, a drink special, a politician, whatever else you want to examine. Fill up each record with lots of data. Remember to use one-to-many or many-to-many relationships in your models to properly normalize it.

    That takes care of the site structure, but yes, sometimes you want a photo stuck in the photo model to appear inline in the content of your news. Django Inlines app solves that by looking up and inserting objects from other models directly in the “content.” This makes sure all the RSS description data stays intact. Likewise, you can write simple views with Django’s ORM (or just extend the already written generic views!) to spit out data for an API to the iOS or beyond. Or CSV. Or tab delimited. Or plain text. You can do PDFs with another library. We can, should, and need to move beyond the Web.

    To anybody who still sticks to Drupal or WordPress, there will come a time when you wil have to acknowledge that data and the relationships between data cannot be predetermined and the fundamental assumptions of any CMS on your data will ultimately create a detrimental, lackluster user experience over time.