What To Look For In A CMS?

One of the discussions with my friends hovered around what to look for in a CMS. With so many available choice surely becomes difficult. Also the fact that many RAD frameworks for Web like Ruby on Rails, Django, Symfony and many more are in the choice-land has only made the selection more difficult.

I preferably avoid the feature-based selection. I think a requirements-based one is more suitable from a longterm perspective. A feature-driven selection is very tempting, but it starts hurting the moment you start customizing it for your purpose. The problem with this approach is that features are only names with short descriptions, whereas your requirements might have more to do with the behavior. The feature tells you neither about the content structure, nor about its adaptability.

This post is more about the other aspects of a CMS, that can help in selection. I am going to use the definition I had attempted a while back.

A Content Management System (CMS) is a system which manages entire lifecycle of the content – from its creation to archival/destruction without breaking the integrity and meaning of the content.

Span the content life cycle

This is what comes out of the phrase content management. The system should let us create, manage and archive or destroy a piece of content, without breaking it. The challenge here is that each of the actions that we mentioned here might differ by the content type. For example, creating and storing an article and an image can be completely different. Similarly managing them can involve completely different workflows and conditions.

A CMS should have the ability to span the entire life cycle all content. All this without affecting its meaning and integrity.

Handling multiple content types

This can be subjective. However, I believe that for a CMS to be applicable in multiple scenarios, it has to be able to handle multiple content types. In fact, not only handle, but it should even facilitate creation of various content types.

A lot of times the content types and data types are mixed. Content types usually represents the real world content, while the data type represents the formats that the computer handles. Typically a content type is composed of various data types, like text, images, or time.

Another aspect is to apply certain global operations to all content. For example, search is something that can apply to all content. I would also extend this to say that a content management developer should have control specify what should be searchable and what not. Another such example is classification.

Content goes through many hands in its life cycle

A CMS, like any piece of software, integrates somewhere with the real world. And real world is full of collaboration and team work. If a CMS has to solve problems in such scenarios it has to inherently acknowledge the fact that different people at different times can handle content. The challenge is that this is not free-form, along with allowing multiple people to interact with the content, it has to restrict some others. And it has to restrict the people to do only certain things with the content.

Traditionally, the users have always been thought of as the ones who consume content. A CMS explicitly acknowledges that the users also include people involved in the entire content life cycle.

If a CMS does not support a good roles and permissions system it can be very difficult to achieve this. Most of the failures or dissatisfaction out of using CMSs, that I have seen, have born out of the fact that the CMS has not been able to support the business processes. A strong roles and permissions systems is one of the factors of automating business processes.

Separation of Concerns, with Flexibility

The other factor is the flexibility with which you can work with content, whether it is retrieval, processing or rendering. Separation of Concerns is found in almost all the CMSs nowadays, however they also carry its side-effect – inflexibility. An implementation of separation of concerns involves internal APIs, using which the various concerns interact with each other. If not designed well, these APIs can impose restrictions.

The APIs should also allow us to work with the content at an atomic level. This does not mean that it should not carry any abstractions, however, it should not prevent the developer from working with content at its atomic level. I have faced more than just a couple of scenarios where something could not be displayed just because it was not accessible.

This has been a bit abstract, but I have not been able to come up with something more concrete for something as abstract as a CMS. Also, there can be many more such points if you consider the other variations like the Enterprise CMS, like integration. Also, a very important aspect of CMS is to allow metadata, which is used to provide context for a content.

As usual, I will encourage you to disagree, debate or throw stones if you feel that something is amiss. This is limited to my experience, which is miniscule compared to the knowledge out there. I will more than glad if I can learn more out of this.