Selecting a Content Management System (CMS) — the importance of the back end

First published on the miggle blog 27/3/17

Choosing the right CMS for your web applications can be a daunting task. Where do you start? Well, given you’re thinking CMS because you want to manage content, then the quality of the tools that enable you to do that will be key. Those tools by which you manage the content you’ll often hear called the back-end, or the back office, or the admin area.

For a while at miggle, between 2011–2018 we were best known for the sites we built in the Drupal CMS. We also built sites in WordPress and MODX as well. For a period we used our own proprietary CMS, miggleCMS. And between 2008–2012 we were managing large amounts of content, via a team of editors, for AOL, Yahoo! and BSkyB. Adam, our Lead Product Manager had worked on integrating technology for national press titles online and in print. Emma, our Head of Ops, was Head of Ad Ops for a large publisher and I spent eight years across two portals. Alongside our team of Acquia Certified Developers we had a huge amount of experience in developing CMS and managing and monetising content especially for travel, media and not-for-profit organisations.

Some logical starting points

There are a couple of questions you can ask yourself at the outset.

Do the people who will manage the content have any experience of using a CMS?

If so, which systems? For work, or personal use? And what were their experiences of that like? What worked well? What were the pain points? How good was the training, the documentation, the contextual or inline help?

According to Builtwith.com, 32% of the top million content managed sites are built with WordPress, so there’s almost a one in two chance that if you ask that question, this is an answer you’ll get. The corresponding figure for Drupal is 3%.

Do whoever we use for development have any experience in working with a particular CMS?

If so, that in itself might be a good starting point. Especially if that team is in-house and are the obvious go-to choice. If their experience matches that of your content team, then this might even strengthen the choice.

So, it’s almost certainly WordPress then?

Well, not necessarily. The most popular choices are not always the best in any walk of life. The best choices are those that most closely match the outcomes you want to achieve. Of course, you may know the outcome, but do you know the means to achieve it?

Right now the best selling car in the UK is the Ford Fiesta. Does that mean it’s the car for you? Not necessarily — it will depend on a whole variety of factors. And this may very well be the same for you and WordPress. It might be, and there might be very strong reasons for why it looks a safe choice. But, it might not be the most suitable choice.

What are the determining factors in choosing a suitable CMS with a great back end?

Any CMS is just a starting point. In the same way your Black and Decker workbench, your tool box and that big pile of wood in your garage doesn’t know you are going to build a wardrobe, neither does your CMS know what site you are going to build.

The right tools for the job

Of course, if you’re going to build a wardrobe you need the right tools in that box, to best work with the (ideally optimum) wood you’ve chosen. You’ll want your CMS to have a lot of the right tools as well.

The good news is that most modern CMSs nowadays have the tools you’d expect. Some of those tools are more extensive and varied than others, with different CMSs having strengths and weaknesses, or differences in approaches. I won’t digress on that too much in this post, because I want to focus on how the content is managed more than on the variety of tools that allow sites to incorporate functionality, like an image gallery of city landmarks for example, or login via Facebook. I’ll also save for another post [LINK] the means by which we determine whether a project is best for WordPress or Drupal (or something else entirely).

Getting the toolset in order

Basically, what you want your development team to do is get that toolset in order so you can do what you need to with managing your site. Part of that is making sure that the right tools end up in the hands of the right person. For example, you may want certain people to have the ability to categorise content using a set taxonomy (like a list of countries your users can travel to), but not have the ability to add countries to that taxonomy.

The time it takes to hone the tools will depend on how exacting the requirements are. The more restrictions, validations, contextual help, workflows and types of user we have to take into account, the longer it will take, so having a clear idea of what content managers look like is important.

The key questions we always ask are as follows:

1. What skills do the content editors have? e.g. can they pre-optimise images for web use, or do they need the CMS to help them with this?
2. How many are there and are all editors equal? e.g. senior editor, junior editor, with permissions to create, edit, publish or delete content set accordingly. Do approval workflows or moderation tools need to be in place?
3. How much time do they have? Is editing the site their main focus, or do they have other fish to fry? Do they have time to manually build hub pages, or do they want automated tools to curate, bubble-up or cross promote content, or a mixture of these?
4. Do different departments have different content management needs? e.g. does the marketing department need different access or tools than the finance department?

Once we have the answers to these we need to determine what training, documentation and and support looks like as well:

1. Is documentation written separately, in-line or provided as videos?
2. Does it cover how to create images for example, or editorial style, or SEO guidance?
3. Are we training the trainer, or training everyone?
4. Are there tasks which are too complicated and time consuming for content managers to do for which we can offer support?
5. Are there certain tasks which need to happen so infrequently (e.g. changing a menu option) that it makes more sense for content managers to raise this as a support ticket than to spend time to try and remember how to do something? This is all about you working out how to be most effective with your time.
6. How do the lines of what is required for training, support and documentation change over time as features iterate, staff change and new skills are required?

Travel Nation

Travel Nation wanted to move from an environment where too few content managers acted as bottlenecks to the various people who needed content to be put on site. This process of democratising content updating to resolve this meant that the tools needed to be as simple as possible. The process focused on inbuilt validation to ensure accurate completion and categorisation of all content before it was published. The same taxonomies which are used to categorise content are also used to manage images, which makes applying effective pictures to content is a quicker task than it was before, with end results being more relevant, and therefore of higher quality.

The Student Room (TSR)

For The Student Room (TSR) it’s not just the content managers that need the ability to edit content. Community members and TSR clients can also create content, with the type of content they can create governed by their permissions (which in the case of TSR clients is determined by how much they pay) This meant three things were key:

1. Content needed to be creatable and editable from the front-end for TSR users and clients.
2. This User generated content (UGC) needed to be moderated by internal content staff before new articles or edited articles could go live. Content managers needed the ability to be able to add comments to reviews, as well as override changes or locks on content if requests were not followed up on.
3. Contextual and inline help, as well as data validation and spam prevention measures had to be built in on the assumption that if it could go wrong, it would go wrong.

NHS Brighton and Hove

Many different types of staff make up a local NHS organisation, so different departments have different levels of content requirements. Secretaries to board members, for example, should be able to edit agendas, meeting dates and upload board papers, but should not be able to create or edit content, or upload documents in the prescribing section of the site for GPs.

Content quality and accuracy is absolutely key for NHS, so all content has a review date set, with authors notified by email in advance of these. The overall site manager can also pull a report of where progress is against review dates, so that they have the data with which they can chase up those who are running behind.

What makes all of this achievable?

The common feature with all the three sites above is that they were built in Drupal. Drupal allows developers such as ourselves to:

1. Create specific content types for each distinct part of content.
2. Create multiple taxonomies to categorise the content and determine who can use, edit or create terms within these.
3. Create multiple roles (e.g. admin, senior editor, junior editor etc.) and decide what permissions to assign to this on a function-by-function and content-by-content type basis. By restricting what users can see (and, as importantly what they can’t) the back end can be made as concise as it needs to be.
4. Create specific templates and themes for the back end and the means within this to display editable content based on various criteria, making it easy for content managers to get a holistic view of content within their remit.

Once live, what might commonly go wrong and how is it mitigated?

These are some common issues we see arising over time.

Organisations and people change

Those users who we trained on day one are different, fewer or greater in number, less or more skilled, have more or less time or have different requirements from those who are there today. Understanding and knowing your client helps with keeping up with this, as does having a support package flexible enough to adapt to change.

Users delete content or people they shouldn’t

With effective control of permissions we can restrict who can delete content — and in fact ensure that, if need be, content gives the impression of being deleted when it is in fact still archived somewhere and accessible by a higher ranked role.

People find workarounds

As humans we’re pretty adept at finding clever workarounds to achieve a use of a system which wasn’t intended. This then might cause issues down the line if an organisation wishes to use that data in a different way. All we can really do in this instance is encourage clients to share these with us, as and when they start using them, so we can either be aware of the situation or determine if we need to create a specific tool to handle it.

Breaking content

Where we give certain roles the ability to add manual links, or change URLs, or delete content there’s always a danger related content can disappear, or unintentionally become unavailable to certain user groups. When this happens it’s often an indication of where permissions may need to be tightened up, or validation or checks improved.

General technology changes

Google search algorithm changes and evolving best practice in terms of managing or optimising content for mobile devices are two examples of where technology might change how certain content is managed. The way in which images are handled is often a good example. Hi-res screens have meant that often we need better quality images to make pages look good on the latest devices, while at the same time recognising that fast internet download speeds are not a given everywhere.

Improvements in feature sets or the CMS tool set

Most of the sites we build change over time. Each time we add new functionality we’re generally augmenting the tools that provide this, but it is not always a given that the way in which training or documentation is updated to cover that will be as uniform as when the solution was first rolled out — especially if support time is at a premium. Sometimes the changes may come about due to small changes in how updates to the CMS impacts how the tools are used. These sorts of changes, and indeed any small iterative changes, can make it harder to keep training and documentation updated.

Conclusion

The more tailored the back end is to your specific team’s requirements and skills and the more flexible it is to meet the changing demands of your business, the better and more future proof it will be. Drupal is unique in all of the CMSs we have used in that we have yet to find an example where the requirements of a business have outstripped how Drupal can manage them in the back end.

Digital decisions are never a walk in the park, so let me help you find the right way through the technical landscape.