Our Content Management Systems are the Mainframes of the Mobile Era

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.

I 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.

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.

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.

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.

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.