Our Content Management Systems are the Mainframes of the Mobile Era

Written by Jason Grigsby on

I’ve recently had the great fortune to preview both Sara Wachter-Boettcher and Karen McGrane’s upcoming books on Content Strategy—Content Everywhere and Content Strategy for Mobile respectively. They’ve reminded me of something that got lost in the shuffle after I wrote my poorly titled article back in 2010.

When I wrote that CSS media queries give developers a false promise of a simple solution for designing for multiple screens, most people thought I was referring to the performance issues.


But what I was referring to was an epiphany that I had had earlier that year. After finally convincing clients that building apps wasn’t sufficient because links don’t open apps, I had run into a bigger obstacle—their content management and ecommerce systems were poorly suited for mobile. I wrote in a comment on that original article.

The big problems aren’t CSS or reformatting for the screen. The big problems for mobile web are:

  • Content management systems designed before mobile that don’t separate out text from images and video which are necessary if you’re going to provide those assets in multiple sizes.
  • WYSIWYG editors for content authors that allow the creation of content that won’t republish anywhere.
  • HTML templates, javascript and css that assume desktop bandwidth, cpu, and caching behavior.

These are BIG problems. My conversations with clients over the last year has made me realize how big these problems are. Our existing web infrastructure is ill-suited for the mobile web.

Content Strategy for Mobile by Karen McGraneI was reminded of this last night when I read the following passage in Karen’s book:

The acrimony and the debates around mobile web vs. native apps, or responsive design vs. separate templates are missing the point. The challenge for most organizations in the long run won’t be figuring out a development approach for cross-platform code—because these techniques will evolve and standardize.
The challenge will be supporting a multi-channel editorial workflow, particularly if they want to prioritize content differently across platforms…
The root of the problem is in our internal processes, workflow and tools. To avoid the problem of content forking we need a new approach to publishing content to multiple devices.

Karen summarized the situation better than I’ve been able to. These legacy systems that are often duct taped together containing years of customizations. Often, the people maintaining the infrastructure weren’t around when the systems were put in place and don’t know why the systems do what they do.

Putting our CMSes in a closet

One approach we’ve implemented for a few clients is something based on what I remember happening in the early days of the web to mainframe and mini computers.

Many businesses has existing systems that contained crucial business process and customer data that would make the company’s website better. Unfortunately, these legacy systems were built before the web so they were poorly suited to run a web server and sit exposed on the Internet.

The company I worked for at the time decided it couldn’t afford to move everything off that legacy system. But what it could do is bring in a NetBSD box and then write proprietary connections on the backend between that NetBSD box and the legacy system.

We’ve used a similar strategy for clients for whom changing their infrastructure to support mobile would be too costly, too risky or too time-consuming.

Diagram showing how we use device detection to route someone away from the legacy system to a clean slate as a temporary workaround.

In the diagram above, the mobile web server is using device detection to select the correct template, but it could just as easily be a responsive web design. The key is that the legacy system is now being separated from the presentation layer.

When Daniel Jacobsen described NPR’s Create Once Publish Everywhere (COPE) system, he talked about how most content management systems conflate the task of content management with web publishing and how these things should be separate.

As an added bonus, we’ve found that organizations that already have plans to build mobile applications realize that they need to build APIs to support those efforts. It is much easier for organizations to devote a few developers to create an API than it is to refactor all of their existing web infrastructure. So often you can piggyback on the API development being done to support the organization’s app efforts.

What’s nice about an approach like the one in the diagram above is that it is on the path towards providing better separation of the content management system from presentation layer. Often organizations use the new mobile site as an opportunity to start fresh. The mobile site not only serves the short term goal of serving mobile users better, but it also becomes the site that will eventually replace the current desktop site.

What we’re doing is no different than what we did with those mainframe computers. We’re putting the CMS in a closet. It can continue to do what it does best until the organization is ready to replace it.

This is just one piece of the content picture

While we could identify the problem and point to some things that we were thinking about, we didn’t have the time to dig deep and figure out what it would take to tackle the CMS and content problem thoroughly.

That’s why I’m so happy to have read both Sara and Karen’s upcoming books—Content Everywhere and Content Strategy for Mobile. They do a much better job of showing you how to change the way you think about content and your content management system.

The books help you understand the high-level objectives and why these changes are important. But they go further into discussing how to implement the change in your organization.

I was also pleasantly surprised to find that the two books are complementary without an excess amount of overlap. I think Karen’s might be the one you would hand to a senior person in your company to convince them that there is an issue and Sara’s is the one you would distribute to team members for implementation. That said, both do a good job of balancing the theory and practical.

I realize it may be a bit of torture for me to talk so extensively and effusively about books that you can’t order yet. What can I say?

I know that there are a lot of organizations that are facing these challenges. These books say what I’ve been trying to say for two years and say it better than I ever could. I can’t wait to be able to reference them and share them with clients.

Bonus: Presentations from Lyza and I on content

While I never managed to blog about this topic until now, I did manage to talk about it at Breaking Development last year. The relevant section starts about 19 minutes into the video.

Breaking Development April 2011: Native is easier. Web is essential. from Breaking Development on Vimeo.

Lyza also gave a mind-blowing presentation at Mobilism this year on the nature of content. The video isn’t available yet, but the slides are below.

Jason Grigsby

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He spends far too much time obsessing over mobile and the web. Follow him at @grigs.


The C in CMS also provides a clue to a dissonance: a mobile user isn't in some mythical (content) consumption, or read-only, mode.

The telephone has always been read-write.

Apps have been successful on mobile devices because they generally provide the ability to be creative, interact, tell stories, etc (I'm not classifying here them by how they are built or distributed). Much of the web and its ecology is still burdened with the assumption that we just want to read documents. Apparently not.

So I agree that the CMS as a concept - as well as its particular implementations - should enjoy a serious reboot at this point. Perhaps we could start by losing the primacy of 'C'.


This is an oversimplification. Yes, mobile devices are about connectivity and read/write experiences. But the recent data show that mobile users are going to their devices to start search/browsing/shopping first (and then continuing their tasks on tablets and laptops). All of this is read-only type of activity. Don't believe the hype. Content still matters...

There's nothing wrong with the idea of content management, because a site will still need to manage creation, maintenance, and curation of what they produce. But so many CMS implementations are designed around the workflow for a single page in one format. Adding in WSYIWYG editors has only hidden the problem.

As developers and designers, we can certainly try to design for mobile first, but so far none of our tools are really there yet to help content flow like water. (To borrow a phrase from the excellent Reset the Web presentation...)

If you're familiar at all with the history of accessible web issues, then this is old, old, old news.

In the days of Netscape Navigator, no one could make money by advocating for better accessibility. But now in the age of the iPhone, everyone can make money by advocating for an abstracted-for-mobile system redesign. So it's happening now instead of back then.

It's like folks have finally discovered that there's this platform-neutral file format called HTML. :-)

Irony: the videos in this post just way out of the container on mobile, mocking [a segment of] the article's topic.

I like fitvids.js for that.

Great article!

*"jut" not "just". So much for mobile content management! #DYAC


Yeah, I saw the video issue when I posted. I contemplated delaying the blog post until I could get Fitvid or something else in place, but decided I didn’t want to delay and wasn’t sure when I would get around to fixing that. So I went ahead and posted it. :-)

How can we designers/developers down in the trenches work towards this future? I've been hunting for a long time for a CMS to replace Wordpress, a CMS that handles COPE-like workflows, custom fields/taxonomies/content and responsive designs without a hassle. Does such a thing exist?

Zachary Kain


Does such a thing exist? In my experience some CMS's are already 'COPE ready', in the sense that they handle content as 'data assets' that can be accessed via an API, and to which extensible metadata schemas can be applied. The devil, as always, is in the implementation...

LOL, that'll teach me...

I suppose my point was that half-decent CMS's aren't, in & of themselves, impediments to 'best practice' content authoring, management, delivery & presentation. The complexity lies in all the stuff you've described on this blog (structuring your content & metadata, understanding how you want to reuse & present that content, etc.) & implementing your CMS to deliver those requirements. If you don't get this right, the Best CMS In The World won't fix your mess.

Having said this, in the past I've worked a lot with Squiz Matrix (http://matrix.squizsuite.net/), which has all the features you'd need to implement this kind of workflow - extensible metadata schemas, fully-featured web service API, etc. Not that I'm advocating for any one CMS - there must be many others with a similar feature-set...

Let’s discuss your project! Email Us