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