Yesterday at Web Directions South in Sydney, I gave a talk about Adapting to Responsive Design. I didn’t talk about media queries, responsive images or fluid grids (yes, I know – that’s not like me). Instead, I talked about some of the other things that responsive design challenges: process, business, advertising and content. In the fifteen minute segment on content, I very briefly touched on something I’ve been thinking about for an awfully long time: content management.

The first content management system I worked on was in 1995. It was built in Hypercard, it didn’t publish to the web – in fact, it didn’t publish anyway other than a local, hacked together network in university. Never-the-less, I was pretty happy with it. Fast forward ten years and I’m working at the BBC in Wales working on the design of a new content management system that will drive all of the websites the BBC produced in Wales – for English and Welsh language. I was part of a small, three person team: a designer (me), a developer and an editor. Together, we created a system designed around reusable content objects with really great meta data. Of course, back then, the content objects were being slotted into a fixed width page template according to the editor’s wishes.

Fast forward to today.

Dumb content. Smart Systems.

My friend, Karen Mcgrane, talks about adaptive content. If you haven’t seen her talk of the same name, go and watch it now, then come back.

Go on.

Seriously.

Okay? Good wasn’t it?

Now, when Karen talks about adaptive content, I don’t think she’s actually talking much about the content being smart enough to respond to its environment. It’s not content’s job to know how, when and where to be used. That’s the job of the content management system and the business and display logic to say: ‘hey, you there! Bit of content! Yes, you! So, in this instance, you need to display like this’. The content goes: ‘oh, ok’. See? Dumb content. Smart System.

What Karen is talking about is a system that can display content gracefully in given circumstances based on some content management rules. As she points out, this relies on a few things:

“adaptive content you need to create multiple sizes, you need to have meaningful metadata attached to it, and it needs to be written for reuse”

She cites NPR as an organisation who has taken this to fruition with their publishing methodology: COPE: Create Once Publish Everywhere.

Daniel Jacobson, then from NPR – now Netflix, says that:

“The goal of any CMS should be to gather enough information to present the content on any platform, in any presentation, at any time”

He goes on to explicitly describe the difference between Content Management Systems (CMS) and Web Publishing Tools (WPT):

“WPT’s capture content with the primary purpose of publishing web pages. As a result, they tend to manage the content in ways focused on delivering it to the web. Plug-ins are often available for distribution to other platforms, but applying tools on top of the native functions to manipulate the content for alternate destinations makes the system inherently unscalable. That is, for each new platform, WPT’s will need a new plug-in to tailor the presentation markup to that platform. CMS’s, on the other hand, store the content cleanly, enabling the presentation layers to worry about how to display the content not on how to transform the markup embedded within it.”

He continues…

"True CMS’s are really just content capturing tools that are completely agnostic as to how or where the content will be viewed, whether it is a web page, mobile app, TV or radio display, etc. "

And here’s the thing. To create responsive design experiences, we need to use content management systems – as defined by Jacobson – not web publishing tools. Why? Because web publishing tools publish web pages, not chunks of content with great meta data that are agnostic to how they’re displayed.

And think about it, what are you using in your organisation? Or for clients? A CMS or a WPT?

As Karen says in her presentation:

“what we have today are publishing tools, we have content management systems that force us to think about content management + authoring and content publishing + display as the same thing.”

And this is a problem for producing content, especially the type of content we need for designing responsive web sites.

A form is a form is a form

Since 2004, and working on the content management system at the BBC, I’ve been involved in a number of content system designs: from a peer publishing tool for Biomed Central – a system designed for facilitating and publishing peer reviewed scientific papers, to the most recent version of Drupal: Drupal 7. Without exception, all of these systems share the same DNA: They’re complex forms, big data tables and buttons. Maybe the odd list. But that’s about it.

Now let’s think about the process of publishing content a minute.

A writer may use IA Writer, Notepad or Apple Pages. But most likely, they’ll be using Microsoft Word. They’ll create the content, edit it, save it, re-edit, print it and scribble all over it, get it reviewed, talk about it, throw it away, re-write it. Once they’ve done all of this, they’ll need to publish it – or maybe they’ll just need to put it in the editorial workflow for review. To do that, they generally copy and paste paragraphs into the CMS. They’ll then need to fill in all of these other required fields: some meta data, pick some categories, a 140 character standfirst, a standfirst for the mobile display, upload some images, but damn, they forgot to crop them.

You get the idea. And so it goes on. Publishing content with a content management system is a royal pain in the arse. Almost without exception.

A page is a page is a page

People think in pages: users, authors, writers. You. Me. My mum. It’s a comfortable metaphor. We have the word ‘scroll’. There are web pages. A location on the web is talked about as having edges, and we all know that’s a problem that’s not getting any better with new devices with new screen resolutions and physical sizes. In swallowing the red pill of responsive design, we also need to feed that pill to our users, readers and producers of our content management systems. We need to start talking about content in terms of bits, not pages. And we need systems that help us think that way.

A better way

As Karen says, a CMS is not an authoring environment, it’s a management environment. Mostly, it’s a painful environment and the headwind from these tools is increasing, especially as we start to think about breaking out content into chunks, not pages. In doing so, our management of that content – meta data, images, display rules – also grows. So what do we do?

In-house development teams developing content management systems need to focus a little more on workflow and a little less on features. Understanding the needs of editorial teams goes a long way. A suggestion might be to start a CMS working group that is comprised of designers, developers, editorial, product and other stakeholders who can guide the system more holistically. Create tools that allow for curation. Content management needs to allow for the ebb and flow of content, not just the creation and publication.

We’ve all started talking about content again. For a long while, our content problems were hard problems and nobody wanted to confront them. But as far back as the monks, good designers have always concerned themselves with content however difficult it was. So let’s not think about our pages of content anymore, let’s think about bits of content. Let’s think about stories as collections of resources, meta data and links that never have a beginning, middle and end. Let’s think of our stories as adaptive. And let’s build systems so we can make them that way.