selecting a Content Management System (CMS) – the importance of the back end. part 1

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. 

Here at miggle, we’re best known for the sites we build in the Drupal CMS. We also build sites in WordPress, and in the past we’ve built sites in 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 has 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 have a huge amount of experience in developing CMS and managing and monetising content, especially for travel, media and not-for-profit organisations. So, we’re in a good position to offer some advice I think.

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, 45% 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 5% – so one in 20.

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? 

In part two of this post I’ll look at how these questions panned out for three of our clients, as well as look at some of the common things that can go wrong over time once you're live with your new CMS, as well as how these issues can be mitigated.
 

If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.