How to decide which content management system is best

Danny Baggs

When trying to decide which content management system is best, developers often think about how easy the content management system is to integrate before ever considering how easy it is to use. This needs to change.

So many Open Source Content Management Systems in use today don’t put enough focus on serving the end (content author) user and have built strong reputations and recognised brands by empowering site builders and developers. Whilst this is no bad thing, the web is now mature enough for us to realise that we could and should start to give those content authors a little more TLC to make their jobs easier.

Alongside the ‘choice paralysis’ challenge through the sheer number of Open Source CMSs available, there also appears to be a lethargy towards any true form of assessment of candidate systems. This results in ‘follow the crowd’ decisions by which something like WordPress or Drupal is utilised because of the recognised brand or just because the ‘web guy’ thinks bolt-ons can meet a majority of the known requirements. I’m no WordPress or Drupal hater but I am a big believer in picking the right tool for the job, which may take a little more effort to find but will pay back significantly in the longer term.

A few years back, In order to build a website for a friend as a weekend project, I embarked on a little due diligence to assess a number of the popular Open Source Content Management Systems that were out there. I soon realised that my perspective was a little different from others because of working for RedDot, which was an enterprise level CMS vendor acquired by OpenText in 2006, and is now called OpenText Web Site Management. For full disclosure, I still work and enjoy life as part of OpenText today but outside the business unit that was once RedDot.

The Criteria

Although this post is not about enterprise level systems, RedDot pioneered a great editing experience back whilst the CMS market was still emerging, which clearly rubbed off on me and influenced my decision criteria when assessing those Open Source Systems for my weekend project. It lead to me forming the following simple high-level criteria for my assessment:

Always consider the end user

It was important that my friend (the client) was completely empowered to create, edit and manage the content as easily as possible in a way that was most logical to him. After all, it was only a weekend favour and I didn’t want this to disrupt my full time job or turn into another friend and family IT help desk from hell (Dad, no disrespect intended if you happen to read this!).

The system should be extensible

As an experienced developer on a varied array of projects, I know that change happens. Therefore, it was important that the system pro-actively allow for and facilitate this. Not only from a plug-in/extension perspective but also one where core features could be sensibly overridden to not hinder system updates and upgrades further down the line.


It was important that my friend didn’t have all his eggs in one basket – in other words, he shouldn’t have a strong dependence on me. This would be too much of a business risk for him and despite our friendship, I was keen to provide him an option where someone more talented than me could take on whatever I started and improve it.

From my developer perspective, it is obviously also important to have a strong development community around you to support the inevitable tweaks and changes that you’ll need to apply.

I would encourage anyone looking for a CMS to consider the simple high-level criteria above and surround themselves with people that can help with the assessment. I personally used the above to assess a number of systems including CushyCMS, Typo Light, Typo3, Drupal, Joomla, TextPattern, ExpressionEngine to name but a few.

The Due Diligence

For my assessment, I started by evaluating how quickly I could implement a pre-prepared fully coded HTML and CSS page. Some of the candidates were great in this respect but fell short in the user experience where I was stubbornly keen to get a true ‘what you see is what you get’ (WYSIWYG) experience – meaning the actual web page, with the ability to edit.

Many of the candidates seemed to implement specific code patterns (e.g. Navigation) without a clear way to override, forcing changes to that initial HTML and CSS that I had as my starting point. When it felt like I had to bend and adapt the original unconstrained HTML markup or CSS classes too much, I simply gave up and moved on to the next system.

Surprisingly, there were only a few candidates that had a reasonable community around them. Of those, some had a certain ‘blind following’ feel to them where critique around core system features didn’t seem that welcome. I don’t want to bad mouth any specific vendor here as my point is around doing a diligent assessment for yourself to make sure you expose the information that matters to you.

So, What Did I End Up Choosing?

Although I’m hesitant to point out anything negative about specific vendors, I’m more than happy to share the conclusion of my search and the vendor that came up with the goods on all aspects of my criteria. Despite the fact that I still live by the ‘right tool for the right job’ philosophy, the tool I chose has been adaptable enough to be used in a number of projects since.

Previous to my assessment, I had not heard of Concrete5 but it became very clear very early that these guys met all my criteria. I literally had my test page up with content editable areas defined and configured within an hour. The community around the product helped with meeting this goal through useful ‘how to’ guides and this community has only seemed to go from strength to strength in the last few years.

For the Developer

Concrete5 is built in a very logical way also using a ‘common sense’ vocabulary of terms. ‘Page types’ can be defined and individual ‘blocks’ build up the elements and modules that make up a page.

The whole product is built from the ground up using the well established Model View Controller (MVC) pattern, which appealed to my enterprise developer background. For those who don’t know what MVC is and want to know why they should care, it is a software pattern used time and time again to structure code so that responsibilities are de-coupled and separated to facilitate maintenance (this means a lower cost of ownership for you as changes can be applied quicker and easier).

Example: If you wanted a booking form on a given page to look different, the developer only need to change the HTML structure or perhaps even just add a CSS class to the existing HTML (the view) and not be distracted or confused by the business (controller) logic of what is done with the data collected on that form.

In more complex systems, you may even want certain people to only have access to specific areas depending on their role – front end developer (views), back end developer (controllers and models).

Either way, the solid MVC approach was refreshing and I have utilised this well with various customisations over the last couple of years.

For the Content Editor

Finally, to get back to the point around giving those content authors a little more TLC, the editing experience of Concrete5 was unrivalled by any of the other Open Source candidates. In fact, I even thought that the editing experience alone rivalled some of the enterprise level systems that I had been exposed to.

Why do I think it was so good? The following screenshots show that the editor is presented a page in edit mode where only the ‘blocks’ that they’re allowed to edit can be edited.

An example page as seen by a visitor
An example page as seen by a visitor
The example page as seen by Author/Editor when logged into Concrete5
The example page as seen by Author/Editor when logged into Concrete5
The example page opened in edit mode within Concrete5
The example page opened in edit mode within Concrete5
The editor for a “content” block within Concrete5
The editor for a “content” block within Concrete5
The editor for an image block within Concrete5
The editor for an image block within Concrete5


Although I admit I have become a big Concrete5 fan and I send a hat tip to those guys in the way of giving them a mention here, this post is more about getting you to consider what is important for your implementation and to encourage a similar assessment to what I did. You’ll be surprised what you may uncover.

Since undertaking this assessment of various vendor’s offerings a couple of years back, there may be advances through great uses of the HTML5 contenteditable attribute within CMS implementations. If so, this would provide an even more ‘WYSIWYGer’ (I know its not a word) editing experience to end users. I would welcome comments from those of you with something to add on this point as well as correcting me on anything in order to help guide others.

As the Open Source CMS marketplace keeps pace with the web and moves very quickly, I would welcome your experiences in what you choose/chose, the reasons why, and how successful your implementation has been.