Why your CMS is awful, II: what do to about it

In the previous post in this series, I described the circumstances that make most content management systems for the web unwieldy and unpleasant.

It’s possible — maybe even the common case — to put a lot of work and resources into a CMS project, only to wind up with something so hostile that nobody uses it, or it becomes arcana that’s relegated to technical staff.

So let’s assume you’re starting a project incorporating a web CMS, and that you’ve chosen technology based on the capabilities of the system: it’ll do all of the things you and your constituents want it to do. Awesome! Now we’ll try to make a meaningful experience for the people you dearly hope will get into the CMS and create and share stuff that will affect the world in some way.

It’s a two-step process:

  1. have the right stuff, and
  2. work on the CMS throughout the project.

Having the right stuff

Here’s the checklist I use at Different Chairs. These items almost always come up during requirements analysis, and if they don’t, users will ask for them (typically after the money is spent). Nothing here has to do with the basic capabilities of the CMS. We’re assuming you’ve got something capable — and want to improve the odds that anyone will actually bother with it. I’ve also given implementation notes for the Django CMS, since that’s what I work with most often.

Requirement Why it matters Django CMS notes
Support for phones and tablets.

Working in a CMS seems like a “desktop task”, since the administrative user experiences are complicated and sprawling. But people will use the tools in front of them, and that’s increasingly not a laptop or computer screen. Therefore, consider a responsive design for the CMS’s admin experience. Start with making the experience possible, since it almost certainly won’t be with the default admin presentation.

No magic bullet here. Until recently, django-admin-bootstrapped supported the Django CMS and provided a decent responsive design for the admin (it doesn’t support Django 1.5 or Django CMS 2.4). A better solution is to use django-bootstrapped, which takes a similar approach but yields better markup and responsive layouts that scale more appropriately to small screens. You’ll have to override some of the CMS’s templates to get this to work, but it’s well worth the effort.

Easy ways to work on and share draft content.

Any capable CMS will have ways to view, compare, and revert to versioned content, as well as deliver an editorial workflow that satisfies bureaucracy. It’s fine for this to remain a fail-safe that not everybody cares about. But there should be a simple means for someone to create a new draft, look at it, and share it internally. It’s important to be able to work in private, at one’s own speed, and be confident in how the end product will appear and function.

  1. Create a top-level page for draft content, configured such that it’s never published.
  2. Add an item to the CMS toolbar allowing someone to create a new, draft page that’s a child of the page from the first step.
  3. Show this to everyone who will use the CMS.
Live editing.

How easy is it to fix a typo? If you have to go into the CMS, drill down to the content you were just looking at, and enter some editor, you’ve lost. Ensure that logged-in CMS contributors can make quick edits in place and you’ll be surprised by how often they do.

The CMS toolbar is a nearly perfect solution. Set up actions that satisfy common needs, even if they’re just deep links into the CMS admin. Test dynamic or interactive templates, making sure that all states are available to the CMS toolbar.

Structured content everywhere…

For lots of things (lists, addresses, event information), it’s easier to work with a well-designed, considerate form than a text area. Add as many kinds of structured data to the CMS as you can. Their data models and forms-based presentation need good validation and descriptive help and error messages.

Find or create many plugins. In addition to useful third-party plugins like djangocms-table, keep an ear out during development for opportunities to create CMS plugins to capture little bits of data, or to make it easier to syndicate or republish things from other applications.

…but always in the right context.

What kind of page are you creating or changing? What part of the page? The answers to these questions should control what kinds of content are available to work with. Make this easy to change, but come up with sensible defaults that simplify the author’s work. Available options may differ based on where someone is and what they’re doing — but they’ll always make sense.

You wouldn’t believe how often I see Django CMS projects in deployment without a CMS_PLACEHOLDER_CONF setting, which maps available plugins to placeholders and therefore to templates. Producing templates with these relationships in mind is a powerful way to help people feel comfortable and confident when using the CMS.

An appropriate rich text editor.

Two concerns: (a) Nobody likes these stupid things. (b) The most common content management tasks involve fiddling with some copy in a rich text editor. Therefore, configure the rich text editor to generate markup that you won’t regret down the road, and use one that helps authors create and style copy that integrates into the rest of your site’s presentation. A good starting point would be WYMeditor.

Use the CMS’s default of WYMEditor and configure the daylights out of it so that the available classes and elements match the site’s layout, both in the editor and in the content previews it generates. Make the exact same editor configuration available to other web applications used by the same people.

Opt-in notifications for people who want them.

People want to know what’s happening to content they’re responsible for, sometimes without inserting themselves into an editorial workflow. Provide ways to generate feed, get automated e-mails, or other notifications for changes to sections of a site they’re interested in. If it’s a migration to new CMS from some other system, wire page-not-found errors and other errors to the same notifications.

One simple approach is to write some Django signal receivers to listen in on page changes and dispatch e-mails or user-level notifications. You might also choose to create create reporting views in the CMS admin — or just show people how to satisfy their curiosity by looking at the reversion “recent changes” listings.

Don’t let tools wait until the end

When designing a content-driven site, keep the CMS in mind from the beginning of the project. As you do:

  • Research will drive basic decisions about access to, workflow for, and the purpose of content. (The people that will use the CMS are users too — so don’t forget to do user research with them.)
  • Content strategy can inform the structured content you set up in the CMS.
  • Information architecture will hint at the hierarchy and inheritance of templates.
  • During development, the people who will ultimately use the system might like the chance to see and experiment with it.
  • Analytics and instrumentation can be hooked into the CMS, so when you encounter errors you can easily move from a problem to its resolution.

If you work on the management tools while working through the purpose, intent, and content of the product itself, you’ll get more useful, coherent tools.

When you’re asking people across your team or organization to write, communicate, and inspire, you’re asking them to do something that’s never easy. Don’t let the content management system keep these folks from doing that hard work, and doing it well.

“Why your CMS is awful, II: what do to about it” was originally published in the Different Chairs journal.