Where Should Your CMS Go Next?
How to adapt in a changing environment.
Content management is often a balance between systemization and customization. As digital lines blur—between products, platforms and the constantly evolving versions of each—there’s pressure to standardize content so it can live on longer and in more places. But there’s also a desire to provide richer, bespoke user experiences that might not translate across a single site, much less across an entire portfolio of them.
It’s hard to make your content management system (CMS) do both.
CENTRALIZING AND SHARING
Right now, National Geographic publishes a collection of a nearly 20 sites, run by four different CMSs. Each site has its own audience and own emphasis on content types, but synergies exist that the group, as a whole, hasn’t taken advantage of because of the fragmentation.
Headed by Jonathan Young, the company’s CTO, NatGeo is now in the midst of a migration to a commercial platform that will centralize workflows and management of content across most of its sites. Once it’s complete, it’ll open up avenues for collaboration and resource sharing that didn’t exist before.
"My goal is that the platform would allow any property to share content with any other property," Young says. "In many cases, the tools that we have today on different platforms and different sites has made that difficult. We don’t have a specific percentage we’re trying to hit, but we see the same future as everyone else where there isn’t the same barrier between brands."
Building back-ends for that many sites is obviously a complicated process, but starting from a central code base has been (or will be) the key. At NatGeo and elsewhere, Young has taken on similar launches site-by-site, but he’s opting for an ensemble approach here.
"In the past, we’d have the team work on one site and then move on to another site," he says. "As you’d expect, we learned things during implementation, and would apply those learnings to the next implementation to make it better. That meant that as you moved from one implementation to the next, we’d essentially deploy Version 1.0 to the first customer, Version 1.1 to the second, Version 1.2 to the third, and so on. When the dust settled, we had four or five code bases, not one code base being used for four or five different things."
Instead, a hub-and-spoke model, as Young calls it, gives the group a central reference point to build out from. Individual sites can modify on top of that, but there’s an underlying universality that facilitates sharing. Even those modifications will be made with the central code base in mind, instead of a specific brand.
Reader’s Digest pursued a similar goal as it relaunched its flagship site early this year, according to Diane Dragan, executive director or digital content and strategy for RD.
"One of the things we’re looking to do with Reader’s Digest internally, and also across other products like our sister publications and our books, is to have a more efficient content process whether the articles are starting in print or online and moving elsewhere," she says. "Really, what we were looking to do with this CMS upgrade was to facilitate sharing content among the different products."
Like NatGeo, RD did some spring cleaning of its code base and is making sure future modifications go on top of that backbone. A lot of those build-outs were focused on providing customized functionality for story templates and automated back-end solutions that take a lot of the SEO work out of editors’ hands. It’s paid off—Dragan says search traffic is up 130 percent year-over-year.
CUSTOMIZING CONTENT PRODUCTION
Standardization and automation like National Geographic and Reader’s Digest are implementing are clear methods toward an improved and modernized content production process, but MIT Technology Review is going in the opposite direction.
In fact, the brand’s chief digital officer, Erik Pelletier, thinks formalized production processes might become a thing of the past—in some cases, at least.
"Today, a lot of organizations really scale their operations into what capabilities their CMS is able to provide," he says. "But there’s a strong desire to impact the environment that we’re using to manage content. There’s a need to tell richer, deeper stories that stretch the limitations of an environment where you’re managing the content in a predictable and repeatable type of way. In those features where we’re investing a lot of time and resources, that have tremendous value beyond any particular time period, we want to build them in a way where they’re not so templatized."
That’s not to say templates aren’t useful—Pelletier notes that they work just fine for 75 to 85 percent of MIT Technology Review’s content—but he just wants other options for high-value content. With the help of a design team, those options are actually available now, but they’re inefficient and time consuming to produce. It’s a "quality-at-scale" problem.
Ironically, Pelletier’s fix for this very technical problem is not technical at all: it’s a workflow issue. His development team sits in on editorial meetings looking for opportunities to identify points where they can collaborate.
"Content producers aren’t just writing in Word docs anymore," he says. "They have their own tools, they’re applying markup, they may even be prototyping and pushing forward into some of these deeper, richer realms on their own. The question is how to accommodate some of that to make the actual production faster and more efficient. What we’re really looking to do is make that customization easier."