Don’t mistake your CMS for a development platform

The Washington Post was an early pioneer in building interactive journalism applications, hiring luminaries no less bright than Adrian Holovaty and Derek Willis, among others. But they admit they’ve fallen behind in recent years.

Post managing editor Raju Narisetti recently sounded an all-too-common refrain to explain the paper’s slump, blaming their antiquated content management system. It “can’t really handle a lot of the databases and open-access information,” he said in a piece by Post ombudsman Andrew Alexander.

While the Post is far from the only news organization decrying an old, inflexible content management system, CMSes shouldn’t be an obstacle to building news applications. Even the best CMS was designed to do a different job and — good or bad — shouldn’t be mistaken for an expressive, open development platform.

CMSes are good at mapping complex editorial processes onto a repeatable digital workflow. They store and retrieve complex data, for the most part very reliably. They trade flexibility for ease-of-use. Creating new stories or photos is usually simple, thanks ironically to the system’s rigidity. Learn how to add a byline once and you should be able to do it anywhere.

This tradeoff is common to many systems: the more flexible, the harder it is to use, and vice-versa. Compare a professional SLR camera with a point-and-shoot, or a manual transmission car and an automatic. Customizability comes at the cost of ease-of-use.

My advice to news organizations trying to build applications: You’ll be quicker and have happier programmers if you leave the CMS to what it’s really good at, and let newsroom developers use what makes things easy for them.

So you don’t have to tell your CMS what a headline is in order to write one, and chances are excellent that the vagaries of your editorial process are pretty well handled by your CMS, even if it doesn’t always seem that way.

Interactive news applications, on the other hand, require maximum flexibility. Developers building news applications need a true tabula rasa, and the tools they use shouldn’t come with assumptions about the final result. They may create a Flash application mapping Olympic medals or a huge database of stimulus contracts. They may end up not building a Web page at all, but an API consumed only by other computer programs.

In fact, while there have long been interesting interactive applications on news websites, the heyday of complex journalism done using software — which I suspect we’re in now — couldn’t have started before the advent of the free, open-source rapid software development frameworks Django and Ruby on Rails.

Django (2005), Ruby on Rails (2004) and MVC frameworks like them enabled a whole new kind of development: what I call “deadline software.” Putting 100,000 records from a Freedom of Information Act request online and making them searchable no longer took a team of developers weeks, but could be done by one or two developers in days or even hours. News organizations could take a perishable, competitive set of data, and get something sophisticated online quickly enough to match — and beat — the story a traditional reporter could write.

These frameworks were born to serve the needs of a fast-turnaround news cycle. Django was developed by Adrian Holovaty and others at a newspaper — the Lawrence (Kansas) Journal-World.

Developing outside your CMS doesn’t mean news applications won’t match the rest of your site. At ProPublica, our news applications — which run under subdomains like “projects.propublica.org” — fetch core files from our main website using plain http requests to keep headers, footers and other styles consistent.

The Chicago Tribune’s news apps team also takes this approach. “Almost all of our applications look like they live inside the mother website,” says Brian Boyer, Tribune’s editor of news applications. “But we either cheap out and just reproduce the header and footer or get tricky and pull the header and footer as fragments from the CMS — the latter technique lets us keep navigation, etc., current.”

News applications can pull stories using RSS or APIs, and readers can navigate between content and news application pages totally unaware that they’re traversing systems, platforms, and even geographic server locations. Your site search engine and ad servers should also happily support this.

Developing outside your CMS also doesn’t mean your IT department has to purchase and support new servers. Another technology enabling deadline software is reliable cloud infrastructure products like Amazon’s Elastic Computing Cloud (EC2), which is enormously scalable and, inexpensive relative to dedicated hosting. Most news applications managers I’ve spoken with use services like EC2 to deploy applications quickly with a minimum of long-term commitment.

So my advice to news organizations trying to build applications: You’ll be quicker and have happier programmers if you leave the CMS to what it’s really good at, and let newsroom developers use what makes things easy for them.

Incidentally, the Post is hard at work upgrading their technology and already thinking along these lines. Their chief digital officer, Vijay Ravindran, told me “just as plain HTML has gone the way of the dinosaur, so has using the CMS to do everything.”

Are you creating news applications in your newsroom? Please share your setups and stories in the comments.

Scott Klein is the Editor of News Applications at ProPublica, directing news application development and production. He also moonlights as co-founder of DocumentCloud, an independent non-profit organization that helps newsrooms organize and publish their source documents online.

Tags: , ,
  • http://stdout.be/en/ Stijn Debrouwere

    Some good points here, but they're based on the assumption that all the innovation should be channeled towards creating special one-off applications and whiz-bang interactive stuff.

    I think there's a lot to be said for innovating how we present and publish day-to-day news as well. Most CMS'es still don't allow you to enter news in a well-formatted and structured way (see http://www.holovaty.com/writing/fundamental-change/) that would make it repurposable, nor do they allow you to get serious about contextualizing the news (see http://stdout.be/2010/tags-dont-cut-it/). E.g. the Texas Tribune chose Django as the base on which to build their CMS, because they wanted the flexibility to be able to experiment with their day-to-day publishing, and that requires more than just a playground for special occasions.

    You're right though, you need the resources to pull off something like that (and the courage to say legacy software goodbye), because when using a MVC framework for everyday content management you do lose some things that a good CMS gives you for free. But it can pay off nicely if it's part of a larger strategy.

  • kleinmatic

    Stijn,

    You and I agree that CMSes could use some innovation. I didn't say that all CMS development energy should be channeled elsewhere. I'm simply saying that newsrooms should use the right development tool for the thing they're making, and not get sidetracked by the capabilities of their CMS.

    Thanks for commenting!

  • http://www.danielbachhuber.com/ Daniel Bachhuber

    Good points, Stijn. In my opinion, you shouldn't let a janky CMS get in the way of building innovative news applications but you also shouldn't be complacent with a janky CMS. I think the ideal scenario is one where you have an open source content management system that is well-tuned for the day to day editorial process and is also extensible, you can easily pull data out of it/push data into it, etc.

  • Pingback: We’re in the information business

  • Pingback: IA for news websites: a link dump

  • Pingback: Hoe ik het nieuws graag zou lezen

  • Pingback: How cloud computing and open source helped news organisations cut costs | Online News Design

  • Pingback: Sprinkles on top — live from the DDJ