What is the perfect CMS?

Wiliam, like most web agencies I expect, use a pre-packaged CMS for many of their sites. We currently use Umbraco but find that during day to day usage we end up fighting various aspects of it. If I had to guess, for each feature that we use and love there was at least two things that we hate and makes us less productive.

So then I started thinking, what is the perfect CMS? I already know that the 'perfect' CMS doesn't exist, it's a mythological concept that everyone chases after, like Unicorns and the pot of gold at the end of the rainbow, however, what would make a perfect CMS for the type of work that we do at Wiliam?

These are listed in no particular order.

 

The structure of the CMS data is flexible

This is fairly important and can have a large impact on the sites that we create day to day. Being able to create types of data (‘Document Types’ in Umbraco) and relate them to each other is very important, but it’s more important to be able to do these things well.

A CMS that allowed the data to be structured more akin to a traditional database would be far more useful when creating sites of varying sizes.

 

The CMS does not interfere with the front-end site in terms of layers of abstracted code to retrieve data, and therefore does not introduce a high base level loss of performance

At Wiliam we are often pushing the limits of Design and User Experience for our clients and it’s important that we have the technology to back that up. For us, that means the front-end code has to be as flexible as possible and not constrained to the concepts of whatever black-box CMS provider we’re using decides a website ‘is’.

 

This typically means using a Microsoft MVC project on the front-end which loads in data from the CMS. This decouples the front-end requirements around performance, usability and flexibility from the CMS and therefore removes many (if not all) of the concepts which would otherwise leave the front-end quite encumbered.

 

The CMS data structure can be synchronised via a database schema compare

Many of Wiliam’s clients are large brands who require ongoing work to their website after the initial development, and the CMS needs to be able to handle that process flawlessly. This means that changes the CMS data, its structure or its core features need to be controlled and synchronised with as little fuss as possible. For me, “as little fuss as possible” means using automated tools to detect and apply changes from one version of the site to another in a way that can be rolled back if problems arise.

This is not possible with a CMS like Umbraco and it results in a massive amount of manual work to keep versions across environments up to date as well as to deploy releases on time and in a reproducible manner. There are tools like Courier, but our experience with it over a number of years has been hit and miss and as far as I know, it’s not able to be bound into an automated release process like the ones we run internally in our Continuous Integration server.

If the structure of the website data is an actual database schema then we can generate change scripts and apply schema changes (forward and back) using automated tools which reduces the human error aspect deployment, which is a win for everyone.

 

The CMS is extensible with custom sections in order to integrate external applications

Occasionally when a CMS just can’t handle a certain scenario (100,000 rows of data in Umbraco which are auto-sorted/searchable/interactive, for example) we need to build custom pages which we integrate into the CMS. Realistically this point is only more important for CMS’s which are so limited that it is often required though, such as Umbraco.

In the case it is needed, a CMS which lets you effortlessly integrate your own pages into its structure with as little effort as possible would be ideal.

 

The CMS contains the expected auditing, workflow, user and publishing features

This point is mostly self-explanatory. Any ‘perfect’ CMS will contain all the auditing, workflow, user role, group permissions, timed publishing and logging that anyone would ever expect to use. Often this point is the most overlooked when a CMS is chosen and it’s only after the site is half built that limitations arise and then clients have to address those limitations with offline processes instead of built-in CMS ones, and that is very unfortunate.