It’s impossible to say this comprehensively, but most people in publishing hate the CMS, or content management system, they’re forced to use at work. Increasingly, media companies are opting away from open source platforms like Drupal and WordPress and building custom content management systems to power their websites.
Exactly how integral is the content management system to good storytelling on the web? And what’s so hard about building a decent one?
Reuters columnist Felix Salmon predicted that media companies would either thrive or perish on the efficacy of their publishing platforms. Indeed, several companies, from BuzzFeed to Vox Media, publisher of the Verge, have made notable investments in their CMS, even as innovators in the space declare the CMS needs to be “burned to the ground.”
Why so much pressure on the lowly CMS? For one, the complexity of editorial packages continues to increase, thanks in part to the success of projects such as the New York Times‘s “Snow Fall” and the Guardian‘s “NSA Files: Decoded.” These interactive pieces get lots of attention, and publishers are seeking to better exploit the rich storytelling features offered by the web.
But how much does a site’s underlying technology actually influence its day-to-day operations?
Despite the hullabaloo over the clever design of projects such as “Snow Fall,” the CMS arguably has a greater impact on editorial workflow than design. Take FastCompany itself–its CMS was rebuilt after the magazine launched two new sites, Co.Design and Co.Create. Previously, each site had its own CMS, slightly modified from that of the main site. When changes needed to be made across verticals, each site had to be updated separately. After joining FastCompany in 2011, CTO Matt Mankins decided to rebuild the CMS from the ground up on Node.js.
“It was my stance that the only rational way forward was to consolidate the CMSes and create a presentation layer,” he says. In other words: All the different Fast Company client sites or apps would load their content from one common stack.
FastCompany‘s current CMS unites the main site and and its sister sites (including Co.Labs) under one platform, so that universal changes can be made at once. It also separates content from presentation. Writers and editors submit text, images, and videos for stories through a Drupal layer, a vestige of the old CMS. That content is captured and stored as data on a Solr server with a Redis caching layer, and then styled according to the site’s master design using Node.js. Converting the content to data before adding presentation details ensures that even if FastCompany.com undergoes a redesign, the site will have a consistent look from story to story.
Other sites’ content management systems are similarly structured according to their distinctive editorial functions. Pitchfork, for instance, depends on the timeliness of its reviews, which are largely written by freelancers, not in-house. To expedite the process of assigning and editing reviews, the site’s CMS, which was built using Django, doubles as a schedule manager: It alerts writers when reviews have been assigned or canceled (say, if an album release is delayed) and reminds them of pending deadlines. The site’s CMS also readily adapts web content for Pitchfork’s mobile app, without editors or designers having to make alterations.
In the case of Quartz, the Atlantic’s business-focused site, the CMS, a custom installation of WordPress, is designed to serve the site’s mobile-first functionality. The company developed its publishing tools to equip its reporters and writers to complete most production tasks, such as developing charts and graphs, independently.
Doing so, says senior editor Zach Seward, encourages staffers to develop components of a story–from text to graphics–holistically rather than tacking on additional media after a story has been reported and written. “We’ve found that it helps people write more natively for the web,” he says.
Although well-designed content management systems can greatly expedite an online newsroom’s day-to-day workflow, it also imposes limits upon a site’s structure. After all, a CMS is a system meant to stamp out mass-produced online articles–not bespoke projects.
After the success of “Snow Fall,” Andrew Kueneman, the New York Times‘ deputy director of digital design, told the Atlantic Wire, “This story was not produced in our normal CMS, which is probably pretty obvious… We don’t have the luxury of doing this type of design typically on the web.”
Other sites face similar issues. Pitchfork, for instance, uses a whole separate production process for its cover stories, such as its feature on Daft Punk, which typically include visual effects such as animations. In fact, the workflow for such stories is quite similar to the design process for print.
Once a cover story is written, the site’s creative director develops the concept for the accompanying photography and video; the developers then work to produce those visual effects.
“It’s typically done in a couple of days,” says Matt Dennewitz, Pitchfork’s vice-president of technology. “Some elements require some back-and-forth.”
Adding such bells and whistles to the main CMS can have help editors and technologists build custom editorial packages, but they also let editors do too much. Plug-and-play tools such as ScrollKit can greatly expand the capabilities of smaller sites like PandoDaily; at larger publishers, custom features can help eliminate the silos that usually develop between writers and editors, designers, and technologists, allowing them to collaborate more effectively.
“It’s best when producers, designers, and writers are working in tandem the whole time,” says David Holmes, PandoDaily’s head of social media and experimental journalism.
But making features such as parallax scrolling and 3-D animations central to a site’s publishing platform poses the risk of abuse. Indeed, the most successful multimedia projects, such as the Guardian‘s feature on the NSA, incorporate various types of media in such a way that they are integral to the narrative, not merely supplementary. But doubtless a lot of publications overuse visual effects like parallax scrolling, to the reader’s frustration.
Pitchfork’s development team kept those caveats in mind when it developed a modular visual editor for the site’s less intricately designed features. “It’s good to limit what you do per piece,” Dennewitz says. “That’s a big driver keeping certain features out of the CMS.”
Evidently, a site’s CMS can restrict certain modes of storytelling just as readily as it facilitates others. For media companies eager to propagate their distinctive brand of journalism, developing a robust CMS would seem to be critical to their ability to scale, as Salmon argues. But is developing custom software the best way to accomplish that goal?
On one hand, the size of a site’s editorial operations seems to have little bearing on its choice of CMS, as illustrated by the number of large sites, from CNN to the Economist, that use customized versions of readily available systems such as WordPress and Drupal. “We’ve been joking for years that we should just run [FastCompany] on Tumblr,” Mankins says.
Instead, the decision is often more dependent on the outlet’s core editorial philosophy. Salmon, for instance, cites the distinctive, bespoke quality of BuzzFeed and Gawker’s content management systems. In BuzzFeed’s case, the CMS facilitates the rapid sharing of content across social media; in Gawker’s, it enables readers’ posts to be featured as prominently as its paid staffers’ work. (A previous incarnation of FastCompany‘s site also attempted to promote readers’ contributions alongside staff-written articles.)
But few sites have such a singular mission that an off-the-shelf CMS cannot be adapted to their needs. Though Quartz’s mobile-first approach and classification of stories by temporary “obsessions” rather than permanent news categories lend the site a distinctive character, its editors and developers never considered building a custom CMS according to those features, Seward says. “A lot of us worked with terrible CMSes at other organizations,” he says, “but it turns out there are a number of lovely systems out there.”
On the other hand, a site’s philosophy–editorial or business-wise–may change radically enough that its underlying technology also requires a major overhaul. Preparing for that possibility is one reason Mankins opted for a custom CMS for FastCompany‘s site.
“I think you should choose a technology where you have a clear understanding of how to modify it to grow with you,” he says. “If you’re lucky, you’ll keep growing out of your CMS and there will be a new one, custom or otherwise, to take its place.”
Do you work at a publishing company? What’s your CMS situation? Let me know on Twitter.