Content Management Systems for Web Applications

I spent the last few days analysing Content Management Systems (CMS) for web applications.

We have a very brilliant open source ‘PHP/mySQL, in-house, 3-years-old, SEO Friendly (Search Engine Optimization Friendly)’ CMS – picture on the right – developed by half a dozen developers over the years. But, as projects are growing the need for more was clear. The search for the ultimate CMS had begun…

My sources were colleagues, general and CMS specific websites (including the 2007 CMS awards), reviews, blogs and the CMS Watch report that compares most well-known CMSs in 600+ pages.

There are hundreds of applications entitled “Content Management” (CM) or “Web Content Management System” (WCM or WCMS), but not all of them are appropriate for our business.

Where to Start

To reduce the number of CMSs, a table of 128 features was built and weights were attributed to each feature according to our business model. 55 CMSs made it to the shortlist and were compared, providing a “top 55” list from the most appropriate to the least appropriate. And what a huge table it is (picture on the left)!

After selecting the top CMSs my analysis took another step: installing demos or previewing CMSs online.

A quick preview of the out of the box CMSs gave the impression I was browsing the web 5 years ago… clunky, buggy and even un-configurable admin areas of all sorts. Some exceptions surprised me, allowing me to intuitively creating an article for the home page with Nixon McInnes specific content.

What to consider

So what is a good CMS for our business model? Well, Nixon McInnes is expanding and our projects just tripled their size! That is really good but if we keep this rhythm a new CMS needs to support our growth.

Also the developer team needs to learn how to work with the new CMS. So the learning curve cannot be steep.

The core code needs to be maintained outside Nixon McInnes, and needs to be as straightforward as possible. Templates and new modular plug-ins need to be abundant. And the admin user interface needs to be clear, intuitive and aesthetically appealing. We like to deliver good creative solutions to our clients, and we make sure that happens!

Community support is also a must-have.

We selected a series of use cases we could apply to our new CMS and we took it from there.

Analysis Results

The goal was to find a CMS that could grow with us and allowed for faster production and publication. It needs to have at least multi-lingual, multi-site and eCommerce modules. We assume it would support content management, user management, workflow, SEO friendly management, additional content types and versioning.

Is that much to ask for these days? Apparently so… we could not find one solution that fits our business model and provides the right tools for our developers.

Why? Most CMSs have almost everything that we need, but always miss something else: they do not have eCommerce modules; multi-lingual support is buggy; the code or database is proprietary; the core has a steep learning curve; no good workflow; or the admin area just does not do it…

That itself is a major discovery: there are no stable and complete solutions out there. All CMSs have weaknesses!

Outcome

On the other hand any mid-tier CMS does everything that our home-grown CMS does, and does it better.

So we sat down around the results and discussed the way forward.

Keep our CMS? Historically, that has proven that it is not enough. Is it to develop a new CMS from scratch? We would end up where we are now, or need someone to be a Product Developer.

We came up with a compromise: choose the CMS in a project by project basis.

And that is exactly what we were doing anyway: Using WordPress for small projects and our CMS for bigger projects.

Each project will fall into a category: small, med-size or upper tier. According to that we can choose a CMS that supports the required project specifications.

Won’t we end up the 10 CMSs to support? Not really, if we do some analysis in the beginning of the project and select the best ones to work with.

Conclusion

I am really happy with the outcome. I love learning new platforms!

As I write, we are diverging into multiple platforms: WordPress, Facebook applications API, Widget distribution platforms API, and others. And that is the model of the future: smaller modules to reuse in many applications and better adapted to the user needs.