At web manager job interviews these days, interviewees get asked ‘what CMS packages do you know?’ implying that as a content manager or publisher they are expected to be an expert in how to use a CMS. Surely the point of a CMS is that anyone can publish to a website and the content manager or publisher just has to be shown around a couple of times to understand the features and can then concentrate on the content.
I often get asked to recommend a CMS for a client website, and these days my usual answer is ‘bespoke is best’. By usual I mean if you just want to have a nice looking blog then let’s look at WordPress or similar, it’s a good tool for doing a specific job after all, but not all websites are as simple as that. A lot of websites need user registration, customised data collection, customised article publishing tools, specific catalogue image control, user generated content submission, Google maps integration, personalisation options etc etc etc. So let’s look at the specific site requirements and pull together the various parts into a customised whole that covers just these requirements within a framework that is easy to build on and has an easy to use interface.
This approach might be at odds with some received wisdom in the off-the-shelf vs bespoke CMS debate. Admittedly, there are lots of robust open source packages out there, Joomla, Drupal, Typo3 to name but three that I have used. All these packages have been developed over the years to provide every conceivable solution for every conceivable web developer’s problems and as a result they are bloated, non-specific platforms that require customisation taking considerable development time and resource with an inelegant solution the end result.
Strategically, a bespoke PHP-based CMS has a lot of advantages for organisations who have relatively few legacy systems to integrate with, are committed to growing and developing their web presence and have a multi-talented team who work with it. There are also a lot of advantages for CMS development to continue at the pace determined by the client’s thinking on how they engage digitally and their ability to provide the resources required to support this.
In my ideal world, a truly open source bespoke CMS solution would be based on a common PHP/MySQL framework using an amalgam of custom code and open source snippets. Each release would address specific client requirements and offer an easy to use interface for doing specific tasks. These releases would use minimal code for basic tasks like article editing and creation but also offer a range of enterprise level features like versioning and permissions. Content managers who previously used clunky off-the-shelf systems would not believe how easy it is to use and how simple the user interface is, no longer being clogged up with unnecessary links to developer functions like ‘DB check’, ‘Task center’ or ‘Clear FE cache’ (sorry Typo3!).
I don’t advocate developing absolutely every CMS function from scratch however, if clients have specific needs for such things as ecommerce or email marketing it makes a lot of sense to use third party packages. My view is that by having an agnostic approach to a CMS ‘umbrella’ ensures the package that best addresses the client’s needs is selected rather than the best Joomla ecommerce module.
Another bugbear about CMS packages is the use of the term ‘Open Source’. Sure, the systems mentioned above are based on Open Source code, but the development interfaces are visual and filled with system specific jargon that means a developer has to be familiar with that package. This immediately means that developers have to be specialists, not simply good PHP developers. The OS aspect of a system like Typo3 means that members of the OS community can develop modules that provide more functionality, the end result being a huge range of overlapping or competing modules developed for specific tasks that add even more to the bloat and even more options to an already unfriendly and clunky interface.
So it’s my view that the sensible approach to CMS development is to look at genuine requirements, and how best to address them, not to be beholden to deploying one uberpackage that could be characterised as putting the square peg into a round hole.
Share this
01/08/08
Nanotube
2 comments
n1p2yii88kwn7to0
notable location. So also gaol!