4 ways content management systems are evolving & why it matters to journalists

One byproduct of the digital media revolution is that most journalists today are techies, to a point. It’s increasingly rare to encounter reporters who don’t covet the latest hyper-powered smartphone.

I’ve met with longtime journalists who, having never written a lick of HTML code, are nonetheless eager to skip the Web altogether and start figuring out storytelling for tablet devices. If I was writing about how location-based networking was evolving, chances are I’d hook lots of curious journos who have no intention of ever adding geo-data to their stories. But it’s hard to get people interested in the one technology that they have to use every day, the thing that either inhibits or enables the space-age storytelling they want to do — their content management system.

If your job in any way involves producing media for public or semi-public consumption, chances are you’re a heavy user of a content management system (CMS). And chances are also pretty high that your organization is looking to replace or improve its CMS. It’s worth knowing a few key lessons we’ve learned on how content management is developing, so you know what to look for.

Having worked for and with a host of news organizations, I’ve had a sense for a while that we’re starting to approach content management differently than we did in the early days of the Web. Our sense of what a CMS should do is maturing. To find out more, I talked with three people who’ve all had integral roles in CMS development at multiple news organizations, two of whom I’ve worked with as editorial product manager for Project Argo:

  • Andrew Fitzgerald, who recently moved from Current TV to become senior producer of the online presence for Al Jazeera’s “The Stream.”
  • Patrick Cooper, formerly a daily news blogger for USA Today, now product owner of NPR.org and the CMS that powers NPR’s digital platforms (“Seamus”).
  • Marc Lavallee, my teammate, who sojourned at organizations such as The Boston Globe, The Washington Post and National Journal before coming to NPR to construct the platform that powers Project Argo (“Navis”).

All three of these systems are very different, yet they share some key commonalities that I think present a useful pointer toward how CMSes are developing.

Journalism is moving from “content management systems” to “content management ecosystems”

Digital news operations used to think of their CMS as their one-stop shop: a tool that would do everything one might want to do with one’s content. It would be the place where editors could assign stories, reporters could draft stories, multimedia mavens could store their videos, online producers could program section fronts, community managers could manage comments and more. News organizations would judge potential CMSes by how many different features the software had, rather than by how well the software accomplished any particular function.

We’ve finally begun to accept that no single CMS can handle all of a digital news organization’s content functions. A good content management system today is designed to interact with lots of other software. There’s now a genuine expectation that a CMS will play nicely with videos stored on YouTube, or comments managed by Disqus, or live chats embedded from CoverItLive. Other environments such as Facebook, Twitter and Tumblr come with their own suites of tools. And increasingly, what we call a “content management system” is actually a combo of multiple tightly-integrated systems.

After we investigated several options for building the platform that would become Project Argo, my team decided to use WordPress as a baseline. But we wanted to accomplish several things that WordPress wouldn’t make easy, so Lavallee blended WordPress with Django. This allowed us to seamlessly link the Argo platform to services such as Delicious and Daylife, with minimal friction for users of the software. Each tool does exactly what it was designed to do, without trying to jimmy ever-more-complex functionality into one system.

Al Jazeera envisioned “The Stream” as a show and online news source built on top of the robust conversation taking place on social media outlets worldwide. So when the site chose the content management system that would handle the program’s online presence, they started with software created to curate that conversation — Storify. The Web app lets mainstream users easily pull together stories from posts on social media sites.

Online producers for “The Stream” build stories in Storify that get pulled into an installation of Drupal, where they’re edited, approved and published to the Web. The Storify-plus-Drupal combo brings “The Stream” team several advantages:

  • Storify gives producers a slick, easy-to-use interface to pull in nuggets from the social media conversation.
  • Drupal handles the task of publishing the site, enabling “The Stream” to keep publishing even if Storify is unavailable.
  • It also adds capabilities that Storify doesn’t yet have, such as handling Google Maps.

NPR.org’s CMS, Seamus, is homegrown, and there’s a full team devoted to the ongoing development and maintenance of the software. But even with those robust resources, Seamus isn’t the only player in the organization’s content management ecosystem. A separate homegrown system (“NewsFlex”) manages audio assets and story budgeting for radio. And email is so deeply integrated into the workflow of NPR’s online editors that one might say another of our CMSes is Outlook.

But Seamus’ biggest partner in managing NPR’s content is something called the NPR API (“Application Programming Interface”). Much has been written about the many ways that the API has allowed NPR to build its digital presence; here’s a terrific article from my Poynter editor Mallary Tenore about the effort to expand this API to all of public media. The API makes it much easier for all of our content management systems to talk to one another. It’s a perfect reflection of how interconnected our content management software has become.

There is a growing understanding that content management systems should be “beautiful”

I have seen some hideous CMSes — contextless clusters of text input boxes littered with mine fields of pop-up windows. Then one day in 2005 or 2006, I feasted my eyes on Wilson Miner’s glorious administration page designs for Django.

After years of CMSes mimicking the harsh utilitarian aesthetic of Windows 3.1, the Django admin was stunning — a winsome color palette; tasteful, purposeful gradients; entrancing icon design. Even the experience of interacting with the thing was a delight. Pressing a button might summon a charming JavaScript effect — nothing needlessly ornamental, everything smooth and satisfying. The world shifted a little bit.

Your average news organization CMS used to require weeks of training to acclimate new users. After all, why would a company spend precious design resources on polishing a “back-end interface” that users of the news site would never see? It shows how far we’ve come when Storify — praised for its wonderfully intuitive user experience design — now serves as a back-end interface for a news organization’s CMS. Beautiful software, even for back-end users, is becoming an expectation.

We’re moving in this direction because we now understand that better content management systems foster better content. “The happier people are, the better their content will be, the more content they’ll produce,” says NPR’s Cooper. Plus, as he points out, digital journalists now do much more creative, original work than they did when news sites were starting out, when most of their content was ported from other media formats. “Digital newsrooms have moved from shoveling to creating,” he said. “Those two tasks require very different environments.”

When we launched the 12 Argo sites last September, my team wasn’t able to do in-person training with any of the bloggers who’d be running the sites. We gave the bloggers links to a starter guide and a few tutorials, and we were available by phone, but otherwise, they had to get up to speed on the platform on their own. Within days, even users who were new to HTML were able to publish robust, attractive sites. This wouldn’t have been possible without the years of testing, use and development that have gone into the WordPress interface, Lavallee points out. “A WordPress developer can get feedback from millions of users directly,” he says, “which is generally not the case in a corporate support forum.”

Which leads me to the next point.

Open-source software has raised the bar for default content management experience

When I worked in the newspaper industry, it struck me as a tremendous waste of resources that we had thousands of individual newspapers with nearly identical needs for content management, but we hadn’t yet settled on any baseline content management standards or platforms. It seemed like every day, a new vendor entered the content management market with a proprietary product, built from scratch.

Meanwhile, early in the 2000s, open-source CMS software wasn’t yet a strong alternative. But the open-source community was beginning to converge on standards, and building on the work others in the space had accomplished. (WordPress, for example, began its life as a descendant of the open-source blogging platform b2.)

By the middle of the decade, projects such as WordPress, Drupal and Django had begun to achieve critical mass. In the past several years, Lavallee says, executives making software decisions at media companies started to see open-source software packages that were slicker-looking than the expensive products being marketed by vendors.

Today, vendors demoing software or news organizations considering a proprietary CMS have a pretty high bar to clear to justify the investment: they have to build something that’s better than WordPress or Drupal — faster, more functional, more stable, more secure or more customized to their needs. As that free software has improved, every CMS has had to improve to keep up.

And if you can’t beat ‘em, build on ‘em. Even the most well-resourced news organizations are using open-source tools such as Django, Ruby on Rails, WordPress and Drupal alongside or inside their homegrown or vendor-built CMSes. Seamus, for example, incorporates open-source products such as jQuery and ImageMagick in its innards. We were able to launch the Argo sites quickly because we could use WordPress as a starting point; all of our development was oriented toward adapting and extending the software for our needs. NPR’s Digital Services department helps member stations develop their Web presences; their newest products are built on the latest version of Drupal.

All this is not to say that open-source software is a panacea. NPR’s Cooper and Al Jazeera’s Fitzgerald both cite tremendous value in larger companies having in-house development expertise on content management. WordPress and Drupal provide terrific defaults and starting points, but the bigger and more complex the needs of the organization, the more it will butt up against the limitations of these products.

Last year, NPR moved its blogs off of WordPress and into Seamus, enabling a more seamless integration between blog content and the rest of the material NPR generates. And as Current’s understanding of itself as a media company evolved, the organization was able to engineer its homegrown content management platforms to adapt as well.

We’ve realized that good content management requires constant development

In all aspects of media, news orgs have had to get used to the fact that constant change is the new normal. Content management is no different. For much of the last decade, every news organization always seemed to be transitioning onto a new system every few years — a hugely significant undertaking. We were searching for the silver bullet — the system that would be flexible and robust enough to solve all our problems and meet all our needs for the next 10 years.

We now know that such a system doesn’t exist. We’re beginning to understand that a CMS — every CMS, open-source, enterprise, or otherwise — requires continual investment and development. No matter how small or large your organization is, your content management system has to develop to accommodate a digital news environment that changes dramatically from year to year.

If you’re part of a large media organization, you need people devoted to maintaining and extending your CMS — whether that means an in-house development team or a tight-knit, ongoing relationship with a vendor. If you’re part of a two-person independent news operation running WordPress, you should be updating the software regularly and adding and removing plugins that meet your needs.

In many ways, this reality underlines the other three observations above. Because we know that our content management environment is going to have to evolve frequently and significantly in the foreseeable future, we have to build systems that are lightweight and flexible enough to inter-operate with others.

Because it makes no sense to spend a month of training on a system that’s going to change in a year, we have to use content management interfaces that are beautiful enough for users to grasp intuitively.

And because we need to develop fast, we have to borrow tools and ideas from the world of open-source software to make our content management ecosystems better.

We have made it easy to comment on posts, however we require civility and encourage full names to that end (first initial, last name is OK). Please read our guidelines here before commenting.

  • http://www.facebook.com/profile.php?id=689107993 Frederik Bjerre Andersen

    Great post and good points. But just a small detail: To me it seems that Storify handles Google Maps quite well, doesn’t it?

  • http://www.facebook.com/profile.php?id=689107993 Frederik Bjerre Andersen

    Great post and good points. But just a small detail: To me it seems that Storify handles Google Maps quite well, doesn’t it?

  • http://getLocalNe.ws Cynthia J.

    A very insightful and informative piece indeed, thanks for posting this. :)

    In my opinion, with the plethora of open source CMS platforms and related tools available out there today, most publishing needs could be readily met with carefully planned selection, integration and implementation processes, leaving little room for heavy software development work.

  • http://www.facebook.com/profile.php?id=793627066 João Pedro Pereira

    Very interesting article.

    We’re now at the process of considering a change on our newspaper CMS and I hope to get exactly this message through. Ease of use is vital if you want journalists to focus on content — especially if they have a tight deadline, which almost always is the case.Just a note: you link to the Django framework, instead of the Django CMS (django-cms.org).

  • Charles Calvert

    FYI, Django is a framework for building web applications, not a CMS.

  • http://www.smallhandsbigideas.com Grace Boyle

    Thanks, Matt. This post just resonated with me for many reasons, you hit the nail on the head amongst an industry that for better or worse, is completely driven by it’s ever evolving technology.

    I thought Kapost might be relevant as was one of those pieces of technology that aids in helping journalists, editors and online publishers. Would love to hear what you think: http://kapost.com/

    Thanks again for writing this :)

  • http://argoproject.org/blog/ Matt Thompson

    Good context, Perry. 

  • http://argoproject.org/blog/ Matt Thompson

    Thanks for that insight, Steve. I haven’t seen ContentWatch.

  • http://argoproject.org/blog/ Matt Thompson

    Take a look at the Journal-Register’s Ben Franklin project, in which 18 newsrooms published their newspapers using only free, open-source tools. They walk through exactly which software components they used. It’s a fantastic example of a content management ecosystem.

  • http://argoproject.org/blog/ Matt Thompson

    Thanks, Grace. I haven’t given Kapost a try, but I’m curious to hear what you think of it.

  • http://argoproject.org/blog/ Matt Thompson

    Yep. Another unstated cause of the improvement in CMSes is probably the fact that websites are starting to get better-looking. When every news site involved a byzantine arrangement of modules stacked fuglily adjacent to one another, the CMS had to be equally complex to manage these layouts. Now that we are learning the value of simplicity, whitespace and hierarchy in our designs, the CMS can be more streamlined as well.

    (I also think the proliferation of decent-quality, free templates for systems like WordPress and Drupal has also raised the bar for information architecture and front-end design more generally.)

  • http://argoproject.org/blog/ Matt Thompson

    Totally agree, Mathew. Being able to use a variety of tools, each built for a specialized set of functions, is increasingly a better solution than the one-size-fits-all. And now, with things like password managers, it’s less of a pain to sign into a variety of applications. (Although don’t let any security fanatics hear me say that.)

  • http://pulse.yahoo.com/_HOFWXLJATWG57C6T5L4SJCPTLE Perry Gaskill

    Nice work, Matt. The current state of CMS platforms is a very difficult thing to write about without veering off into complex technical issues and the dynamics of some of the engineering factions involved. Also some remarkably thoughtful follow up comments.

    For what it’s worth, it might have been useful to add some additional perspective as far as the CMS components involved. For example that both WordPress and Drupal, as well as a lot of web-based applications in general, store stuff in an SQL-compliant database such as MySQL or PostgreSQL. Having data stored in such a form means that it becomes both more portable and can also be repurposed, but it also adds a layer of complexity in the sense that database admin is a somewhat different skill set from that of, say, a designer or web developer.

    I mention this because it seems to me that having such foundational elements in place is important if you want to move news content into things such as topic pages, or contextual journalism, or towards the semantic web.

    It might also be noted that both WordPress and Drupal are based on PHP as a programming language with some Javascript for additional functionality. Django is a framework for the Python language. From a business standpoint, the cost of implementing CMS changes using PHP and Javascript is likely to be lower both because there is more of an existing code base available, and because there are more PHP and Javascript developers around.

    @ Steve Yelvington

    Good point about the difference between inward-facing and outward-facing tools. It’s something rarely mentioned. From the standpoint of the direction of computer science, it seems evident that the broader trends are moving toward both semantics and expert systems. And although robotics and financial markets have been able to skip ahead directly into expert systems, the news business is still bogged down in a semantic transition primarily because of things such as microformat versus RDFa format wars. How do you build the expert system news tools you need if you can’t decide on the raw data you’re going to be working with?

    @ Bernd Burkert

    Good comment, but I’m not sure Microsoft Sharepoint would be my first choice as a groupware solution to integrate with or augment a CMS. If what you have to work with at a basic code level is PHP/Javascript, for example, it would seem to make more sense to have your groupware solution also based on PHP/Javascript. Having that capability not only means that you control of the functionality, but also that you can use common CSS style elements to match the UI of the CMS. Two groupware platforms, among others, which are worth watching are PHProjekt, based in Germany, and SugarCRM from the Silicon Valley.

  • http://www.wordpressknow-how.com john murphy

    Very interesting post that told me a lot about how media companies are looking to use CMS and where some gaps still exist. I like the fact that you have taken time to explain cause and effect and go into detail. Well written.

  • http://www.facebook.com/people/Bernd-Burkert/100001184842632 Bernd Burkert

    Great post!

    What I really like (being product manager of the German onion.net cms myself) is that you stress several aspect which we feel important and underestimated by many “experts”

    change is a constant: There are still any product comparison websites (and consultants) out there, that advise clients to make a list of requirements and check it against features and functions of different cms vendors. My understanding is that in many cases the result will fall short of any sustainable solution. Recently I read a study of a German competitor, finding that on average companies replace there cms solution every 3,5 years. Our answer to constant change is a model driven cms, that allows to change the information model of an individual project on the fly without any downtime.

    integration is a must: We believe that a cms is only one part in a typical enterprice IT ecosystem. Rather than replacing other systems by the “big suite” (with all it’s strenbgths and all it’s weaknesses) or copying data between a variety of data silos, we advocate to aggregate the information from all the different sources. For example we integrate with Microsoft Sharepoint which is a popular platform on the intranet but conidered by many too clumsy on the internet. Now you can easily collaborate in the Sharepoint universe, and have certain items automatically aggregated with other information and published on the internet. Or we integrate with e-commerce software adding the superior frontend capability of the cms to the superior backend capability of the e-commerce software. We believe that the “best of breed vs suite war” has been decided many years ago, when the W3C finalized the XML family of specifications.

    bad usability is a no-go: editors (being journalist or working for a company) should get an easy to use “clean” user interface. The model driven approach enables a generic user interface to be derived from the individual information model (which may change with time). The generic user interface is coherent and always behaves in the same way. As a result we loose training revenues ;-) 4 hours editor training with the initial project is enough for ever, as the wisdom is being passed on within the organisation. A by-product of the model driven appoach is, that any project is “taylor made” and the solution partner can arrange the way users work with the system according to the way they want to work. Well, this goes only to a certain extend of cause but it’s much better than pre-fabricated features and functions which never really fit and have inconsistent UI’s sometimes.

    beautiful is better: our answer here is to enable localisation of the generic editor with nice icons and meaningful phrases, to assist the editors doing there work easier and understand the UI more intuitively. As everything is (XML) schema driven we have information types rather than folders and files. The system discriminates internally between a “news folder” and a “job folder” (btw you cannot put a job into the news folder) and the UI is much enhanced by localisation with meaningful icons. We feel that here is still much place left for further improvements and our development staff is currently working at it for upcoming versions.

    My bottom line: we live in a world that is facing rapid changes. We are tearing down physical borders (l live in Germany and can travel into many European countries without stop or border control now. Just 22 years back we had the Berlin wall). We keep implementing more freedom for many people – look at the Arabian revolution – and yes, products like facebook and twitter added a sharp edge to the old concept of “freedom of information”. It’s an anachronism to decide on vendors/products that attempt to lock in your organisation or its data.

    Thanx again for your great insights – and hope mine are’nt boring.


  • http://twitter.com/yelvington Steve Yelvington

    A point often missed: Internal workflow management of unpublished (and possibly unpublishable) content is not the same problem as management of an Internet user-facing public site. There are very different sets of scale and security issues. While it’s certainly possible for one system to work for both, it may be more useful to implement two.

    Our solution at this point is to use Drupal as the website management system and ContentWatch as the internal newsroom system, with an XML-RPC connection supporting instant publication or updating. This makes revision workflow fairly straightforward, and all of the print-specific issues are effectively outsourced. It also lets us have a common editorial environment that can be shared across multiple geographical sites, while maintaining highly specific, targeted customer-facing Web products.

    We have a tremendous amount of Web functionality that isn’t now and may never be represented in the internal newsroom system, but we have worked with MediaSpectrum to implement the most valuable parts that specifically relate to newsroom responsibilities in ContentWatch. Conversely, the Web system doesn’t have to know anything about integrating with InDesign, PDF generation, print ad scheduling, et cetera.

  • http://twitter.com/jeremyhead jeremyhead

    Great post – particularly like the point: better content management systems foster better content. So very true!

  • Anonymous

    to have a quality CMS system, whether if it’s paid, or free of charge, requires that a company, blogger or online marketer continually add value to it, by way of keeping your content up to date, comical, and informative, as well as inspiring. It’s always good to keep the the interest of others at heart and strive to be the best, in serving the people with great content on your CMS,



  • http://www.facebook.com/sellersearl Laura Sellers

    Maybe I’ve missed it, but our organization is looking for an all-in-one CMS (something I know you say is elusive). But there are some touching the boundaries. The requirements should not be that difficult: a way to post online content and then have it go into the print side for more traditional placement and editing. I know TownNews has an option and Publish2 is working on a web-to-print model. Any others in the open source world?

  • http://www.smallhandsbigideas.com Grace Boyle

    What an incredible post. This medium is truly expanding. One of my beliefs about content management, writing, organizing and multiple contributors is that it’s changing as we speak. It can be overwhelming, especially to the journalists and writers who have been around for decades. As I contribute to posts I’m used to the technology, but it’s because I was born “into” it (so-to speak).

    Another tie-in, could be using Kapost which is an online newsroom dashboard for online publishers to help them manage multiple contributors and the entire production life cycle. I’m a longtime publisher/blogger and also write for varying publications, so although I just started working with Kapost I was drawn to their ability to “fill a need” for editors and the ever growing content model we keep seeing.

    Thanks for this post and insight!

  • http://www.facebook.com/sbolton Stephen Bolton

    I think it is true that people do look for the silver bullet CMS that solves all their problems.  What people do not realize that none of the products can replace experience in good, flexible content design.  It is easy to architect your content for a simple website, but very different to deliver to multiple platforms.  This is compounded when you do not know what platforms or delivery mechanisms you will want in the future.  Some of the systems provide structure and best practices to allow you to start using a CMS quickly, but if you want something more complicated you can end up with more extensions than core code returning you back to a management nightmare.

    A good CMS implementation needs to start from good content architecture and design,  and then find a product that will provide the level of flexibility to be able grow and reuse the content to the many channels that may be required in the future.  Some of this requires a mindset change for content authors who may be used to looking at content purely in the context of a single html page.  Inevitably you will not have thought of all requirements that may come up over the long term, at which point you will need to invest time and money to modify to fit your new needs.  You can then only hope that you chose a product and developed your content that will make these changes relatively easy to make, and if all else fails the content is structured cleanly in a way you can export it and move it to another product.

  • Anonymous

    I would also add that its important to make sure the software documentation for such systems is well written, especially for developing new products.

  • http://mathew.blogactiv.eu mathew

    Some time ago (4-8 yrs ago) I was following the ecosystem approach for part of the European Commission. One advantage I found is that it allows you to “break the problem up” into smaller parts, each of which is easier to do, and faster to implement.

    That allows both developers and users, who may not always know exactly what they want, more frequent opportunities to try, test and course-correct the development. It’s almost impossible, after all, to know years in advance what sort of mega-system you’ll need 5 years later, by the time you’ve finished developing it.

    More recently, open-source CMS like Drupal have become so complete and so modular that the right way forward is generally to adopt a robust CMS like it as your core; add to it; and share it with the army of developers out there.

    They’ll  then take everything you do, improve on it, and give it back to you. Hard to argue with, no?