modern cms development

Posted by Peter Curran


How do you go about picking and implementing a new CMS for your website?

What have we learned from the CMS implementations we’ve been involved in lately? How do you go about picking and implementing a new CMS for your website? These are good questions – the CMS market has changed considerably over the 17 years that Cirrus10 resources have been involved in it.

In the late 1990s and early 2000s, it was considered normal to spend seven figures on a CMS project, with services and implementation cost averaging two or three times the cost of the license. “Enterprise” was the buzzword of the day and designing a system that would allow business users to manage the website, let content be used anywhere, and that would meet the needs of the next ten to fifteen years was the goal. So how did that work out?

Well, the ten to fifteen year part seems to have succeeded. Most of the CMS re-implementations and RFPs that we are involved with are for clients that are replacing an old system. Unfortunately, for many companies, the elapsed time seems to be more about lack of budget than satisfaction with the system that was built. Content and site management are still centralized in a small group of people (normally on the IT side), and large parts of the systems developed so long ago are sitting unused. Massive frustration with the usability and flexibility of the CMS is the main reason we are called in to help with a replacement. On the business side, users want to be able to change things easily and quickly, and without calling IT. On the IT side, administrators and developers want to deal with their day jobs and not have to put everything aside to deal with the next urgent content change coming from the business.

There are two main things we have learned which may help solve these issues on your CMS implementation: decide who will actually be managing the content and what they will be managing, and be prepared for the inevitable changes that will come once they are using it.

There are two main things we have learned which may help solve these issues on your CMS implementation: decide who will actually be managing the content and what they will be managing, and be prepared for the inevitable changes that will come once they are using it.

The difference between page management and content management may be the key factor in determining which CMS you should use.

Are you Managing Content, or is Content Managing You? CMS – a Content Management System. Separate the content from its presentation layer and you can use it anywhere for anything. Sounds great, but in practice this is not where websites have gone. Actual reuse of content happens of course, but a large number of our clients don’t think in these terms – at least on the business side. You need to consider what you are actually trying to do. Are you really going to reuse that content in other places, or is it just a page on a website?

The difference between page management and content management may be the key factor in determining which CMS you should use. In our discovery sessions and workshops a clear distinction emerges: technical stakeholders talk about “content”, “reuse” and “separation” while the business users talk about “pages”.

CMSs which work based on a structured view of content (a series of fields, logically separated) are great if you will really use the content in multiple places with multiple formats. Unfortunately, this approach to content management always sacrifices usability for the people who have to enter and maintain the information. If you need this approach you should assume that content management tasks will be centralized in a core team who really understand the nuances of your system. CMSs which take a page-based approach are easier for non-technical, or less well-trained users to navigate, but sacrifice the ability to easily reuse content in other places.

The good news is that most good CMSs now allow both approaches. You can manage structured content and page content, with usability on both sides. Responsively designed layouts are also a boon in this area – if your CMS allows you to impose CSS-based formatting on your content at the creation/editing stage you can have real flexibility for reuse.

The days of defining an exhaustive content model as part of an initial implementation are gone (at least, with most CMSs). In the past, it was necessary to think way ahead when you were defining your content. CMSs lacked the flexibility to change the structure of content on the fly and required significant technical involvement every time you wanted to add a new field or a new use for your content. This is no longer the case. A good CMS allows you to make these kind of changes using a simple interface, and propagate the changes without too much effort. This means you can really be agile with a CMS and consider implementation phases in terms of a “minimally viable product” instead of trying to figure out where you will be one, two, or ten years from now.

We strongly believe that the best way to successfully implement a CMS is to get it installed, get it live and have the business users actively managing their website content in as short a time as possible. It’s not unusual to find that requirements defined prior to the initial implementation are not as relevant once users actually get their hands on a system and see what it can do. In the interest of keeping it simple, what are some of things that you have to keep in, and what can you leave out?

Make it responsiveMake sure your CMS has some basic out-of-the-box responsive layout capability. It is common (and understandable) to be focused on getting the site up as soon as possible and to worry about other formats and devices later. As soon as you launch, someone important is going to look at the site on their phone, and if it is illegible, misformatted or just a bit messed up you’re going to have to fix it. If the site content responds correctly from the start, if the navigation works, pages load and text can be read, you will have a great launch day instead of a sleepless launch night.

Don’t Compromise on SEO – One place NOT to compromise is SEO. Most CMSs come with SEO features out of the box. At a minimum you should mandate the following five options:

  1. Static, user-definable URLs giving you the ability to point to a page in a business and search-engine friendly way. You need to be able to avoid complex IDs and query-strings where it makes sense.
  2. Ability to redirect a page to anywhere. If you don’t do this, anytime a URL is updated on your site inbound links can break (commonly called a 301 redirect).
  3. Editable title and meta-tags, especially for snippets of copy that accompany Facebook, Twitter and Linked-in shares. You won’t always be able to define what your site looks like when shared but this will help you programmatically cover your bases.
  4. Automatic Link Management for when you just have to change that URL – make sure all the links in your navigation still go to the right page.
  5. A Sitemap.xml that is automatically generated and updated. Think of this as a way to make sure search engines know what you have available.

Plan for crisis – A CMS that requires a staging/approval step before go-live is great for review when you have the luxury of time, but the day will come when a VIP calls you and demands to know why a piece of content isn’t live on the site RIGHT NOW! You can take care of this issue by having a CMS that will publish (and unpublish) on demand. Use the roles and permission features of your CMS to make sure the right people have the ability to do this (and avoid “the intern published it” moments). The ability to publish on demand out-weighs the risk of publishing the wrong thing.

Wait for Workflow – There was once a school of thought that it’s important to track every step in the publishing process, no matter how minor. Every step would be built into the programmatic workflow in the CMS. As a result, the last decade of CMS implementations have left the corporate world with millions of dollars of complex unused workflow systems. Successive steps in a workflow are assigned to the same person (normally the “CMS expert” at the company), who spends valuable time approving and re-approving the same content they initially created, just to get it published.

Launch with a minimum of approval workflows. It’s easy to add steps to a workflow if you find you need them later, and it’s better to have those steps be exclusive to the edge-cases they are relevant for.

So there you are: the business stakeholder who has been trapped behind unusable systems or senseless IT bureaucracy; the systems administrator who is sick of unclogging publishing queues for someone who ignored the proper procedure (again). You’re fed up and ready to fight to the death for a set of requirements that are going to make everything better in the new system. And here we are: the sympathetic systems integrator ready to cater to your every whim.

Remember, this is how you got into the mess in the first place! Implementing a CMS is exciting and transformative, but be patient. Before you write any requirements, ask your SI how fast they can conceive of getting you live and pay close attention to all of the assumptions they make as part of that estimate. Go with the absolute minimum viable product, get to know your new CMS over a few weeks, and then come back to the table with your requirements.

Need further strategic or technical help?