How We’re Thinking About Content Management for City Government

Hi! I’m Jake. I’m a writer, software engineer, and — as of a month ago — a Design, Technology, and Innovation Fellow for the City of Austin. My first few weeks were all about learning, from participating in design interviews to researching what kind of Content Management System our team might want to use for our first project, a new website for the Austin Convention Center. This post is about my thoughts so far on how our team should approach selecting a CMS, and I owe most of the ideas it contains to excellent posts I’ve read from 18F, Development Seed, and Contentful.

This is just the beginning of what our team aims to share with the world about what we learn as Innovation Fellows. We hope you’ll learn along with us, so be sure to hit Follow if you’d like to keep up.

If you’re part of a project that involves building (or rebuilding) a website, chances are that you might hear someone talk about “which CMS we should use.” Often, that question might be presented as a decision between a few popular platforms, like WordPress, Drupal, or Joomla, which can make it seem like you’re deciding on a single component. The truth, though, is that when you pick one of those CMSs, you’re making a decision about a whole bundle of components—usually, at least four distinct products:

1. An editor to input and edit content
2. A backend database where the content is stored
3. Templates to define the site’s layout and display the content
4. The web pages that are finally delivered to visitors of our site

The one-size-fits-all approach of WordPress and its comptetitors has some merits, including ease of setup (someone simply installing a WP theme doesn’t need to think about templates as being separate from the admin), and for WordPress’s primary use cases of blogging and publishing, it’s often a practical choice.

But thinking about these parts of a CMS separately lets us see how combining them in a product like WordPress leads to coupling between them, like how the admin and templates both rely on the same scripting language (PHP), or how the database content is stored in a WordPress-specific structure that the other parts of the system need to understand.

On larger sites, the coupling between parts eventually defines the limits of what’s possible. For example:

• Instead of evaluating community support and developer expertise, we’d have to base future development decisions first on framework and language compatibility.
• The kinds of content and data we could publish — and where it comes from — would be constrained (and require tailoring to) to WordPress’s built-in rendering process and admin interface.
• We might have more trouble meeting uptime requirements and addressing load issues, because the parts of the system would more likely than not be on a single server or network.
• We’d potentially increase our risk of exposure to security exploits by enabling the use of inadequately-vetted third-party plugins, which can also complicate upgrades.

I like to frame these concerns as reflective of the differing needs among members of a team. It’s developers who care most about the front-end tools available to do their work, while it’s content editors and other users within an organization who need flexible ways to input and publish content, and IT or ops specialists who take on the challenges of scaling. But a platform like WordPress universally constrains everyone’s decisions, and makes it much more difficult to adequately optimize any part of the system.

The larger and more complex the organization, the more defined these different constituencies tend to be, and the more it makes sense to consider their needs separately. This is the driving motivation behind what’s sometimes called a “decoupled” or “headless” CMS, which is designed to support the separation of editing, content, presentation (i.e. templates), and deployment layers.

Benefits of a Decoupled CMS

The ability to address diverse needs more effectively would be a significant advantage on its own, but a decoupled CMS also comes with a handful of key technical advantages:

• You get redundancy and scaling practically for free, because you can deploy the website — just HTML, CSS, and JavaScript — to almost any web server or Content Delivery Network.
• You separate your content from your website, which makes it easy to reuse in totally different contexts, like native mobile apps.
• You can combine content and data from sources besides the main editor, including APIs and automated feeds. That makes it easy to build micro-services, which in turn lend themselves to a micro-purchasing approach to maintenance and improvement.

It may seem like it would be more complicated to set up each of these components separately, but it shouldn’t be: a decoupled CMS should rely on widely-supported tools, solutions, and standards. Done right, it even should save time, by allowing developers to build domain-specific features without needing additional time to test product-specific compatibility.

Building an Open-by-Default CMS

There’s another way in which a decoupled CMS is uniquely suited to government organizations: the separation of content from editing and presentation naturally lends itself to thinking about content as open data. We can even choose to approach selecting a CMS as a data-first problem, which might look like this:

1. Look for a content editor that’s able to output data in an open, human-readable format like YAML.
2. Find a way to push or save that data to a public platform like GitHub.
3. Select a templating layer that works with the data format we’ve chosen.
4. Document the availability of our content data for anyone to use.

That’s all there is to it: those are the four parts of a CMS in terms of their relation to open data. But this line of reasoning represents an important shift, too: from talking about a CMS as a website system to talking about it as — surprise! — a content system.

At its simplest, this is possible today with nothing more than GitHub Pages. (Check out Prose if you’re not familiar with it.) But you might still enjoy that kind of plug-and-play setup even if you have more complex needs — you can do a lot, for example, by pairing Contentful and Jekyll with CI processes that sync your content to GitHub and deploy your website to S3.

We can also apply the same open, data-first approach to what we do beyond the core of the decoupled CMS. Perhaps we need to publish data from an internal database to the website: instead of pulling data directly into the presentation layer, we could start by exposing it as a micro-service public API, make sure that’s documented, and then go about integrating our new API with the website. Reusable, documented, and distributed: everybody wins.

Our team plans to use a decoupled CMS on our first project — building a new website for the Austin Convention Center — and we’re really excited about the opportunities this approach will enable. We’re aiming to write regularly about what we’re learning throughout the project, so be sure to follow us here if you’d like to get updates.