The Perfect CMS (Draft)

As I mentioned in my goals for this year, part of the difficulty in actually creating my ideal CMS - or any non-trivial software - is working out where to begin. So these are my first tentative steps - be gentle!

I’ve read a lot of CMS articles over the years, as well as having been involved in numerous web development and CMS development projects - so like anyone else I have my own opinions. A selection of articles that particularly resonate with me include:

The core principles I want to emphasise:

  • KISS - primarily on the user side - whether that be occasional authors (simplified user interfaces), power authors (simplified task management tools), designers (simplified templating), developers (simplified data modelling) or system administrators (simplified installation). It won’t hurt to respect this principle on the implementation side too - though I may deviate towards “elegant”…
  • WWW - The CMS’ (or perhaps more accurately the WCMS‘) primary purpose is to manage web sites. It should therefore make this easy - not difficult, challenging or frustrating! It should output the source code exactly as you want. It should not hijack or tamper with elements of web development forcing you to work around the CMS. In fact, from a web development point of view, it should feel as if the CMS isn’t even there.
  • Customisation - from a developer point of view, provide a well documented API which the web application interface is built upon - allowing customisation and/or replacement of the entire user interface. From an author point of view, the CMS is just another web site managed by the CMS - allowing customisation of the content of the interface.
  • Fun - track and recognise user achievements within the CMS. Turn learning the system into a game - or at least not a chore!
  • Feedback- provide constant feedback about the state of the system and individual projects. Suggest and schedule tasks and best practices for implementation, follow up and review.

In terms of implementation, the key areas I see needing to be developed are:

  • Versioning - a base versioning system, on top of which all content, metadata, administration settings, groups, templates and ideally even code can be stored, versioned, retrieved, branched, rolled back etc. As part of this I will be taking a closer look at the implementation of other versioning systems including Subversion and GIT.
  • API - separation of the the CMS functionality from the web application interface by a well documented API. The shipped UI will rely solely on this API - and will be able to be modified or completely replaced. Current work in CMISJSR-170 and JSR-283 should help in forming a basis for this.
  • User Interface - How the various user types interact with the system - so this is not limited to only authors.

Other items of importance include:

  • Scalability - built from the ground up to support clustering of multiple servers, including distributed storage of assets. Think along the lines of Hadoop or Google File System. It will simply be too painful to try and retrofit this elegantly later. (The ability to run clustered servers on “The Cloud” would remove infrastructure requirements and increase scalability)
  • Templating - a way (or multiple ways) to map data to output - primarily to (X)HTML, but we should not rule out other formats. Most importantly - if at all possibe we will not be creating yet another templating system.

This is obviously not everything, but it is a start - and the first time I have had them all written down together. And yes - it is very ambitious, not to mention scary. I can see why I haven’t got very far before. I have to be careful to avoid “architecture astronaut” syndrome - but as this is the year for implementing - I should know well enough by the end of the year.

What may not be clear from the above is that the API is the CMS. The user interface is simply a web application that utilises the API (hence why it may be completely replaced). The storage for the CMS - whether it be content, documents, permissions, settings etc - is the versioning system. Therefore, the CMS is dependent on the versioning system, and the UI is dependent on the CMS.

With that in mind, the first step is to start making some progress on the versioning system. Unfortunately, “Create versioning system” is not much of a plan - so the first step will be to outline my plan for the versioning system. I have copius hand written notes on this - so hopefully collating it all will not take much time. Once the versioning system plan is in place, I hope to start actual coding - whilst also completing plans for the API/CMS itself and then the UI. At this point, this will all be “experimental” or “prototyping” in nature - I expect my plans wil be quite fluid with respect to what surfaces during the implementation.

Wish me luck!

Leave a Reply