Your Online Presence > Strategy & Development, Managing Content

Commissioning an open source content management system

By Steve Cowie

The article hopes to assist non-technical decision makers in voluntary organisations who may be considering adopting an Open Source web-based content management system, by pointing out some key factors that can be used to compare different systems. In addition, it provides an overview of some of the most popular systems, to identify ways in which these differ and may be suited for different communication tasks. Particular products that are discussed are Drupal, Joomla, Modx, and Plone.

Introduction

Using the web to conduct business has become standard practice for many voluntary organisations. Many may consider shifting from the traditional model of a website consisting of static pages towards a content management system (CMS). Typically these will consist of display pages which are viewed by site visitors, and administration pages that are used by site editors to organise content and users. Content will be added and edited using web-based forms, and the theory is that content and layout are separated so that non-technical people can run their own site without having to get technical support.

There are lots of free and open source CMS available and voluntary organisations may be attracted to these, in the hope of saving money, and possibly also because they like the idea of open source. With so many CMS available, it is quite a challenge for a small organisation in particular to decide which product is most suitable.  This article aims to help with that by providing some questions that an organisation on the threshold of adopting a CMS can ask itself and put to developers who may be providing a CMS.

The questions are generic and could apply to any CMS that controls web-based content, but the views expressed in the article are based on analysis of four CMS applications: Joomla, Drupal, Plone, and Modx.

All four are Open source applications where every aspect of website content is managed using a web-based administration and editing system. They were selected because they are already widely used and also demonstrate contrasting approaches with Joomla and Modx slightly more focused on ease of use and usability while Drupal and Plone focused on technical frameworks that make it possible to add almost any type of content.

What do we want to do?

Whenever I ask this question of clients, the reply is likely to come back, ‘what can I do?’ However, the more you can keep your thinking about your communication needs separate from your evaluation of CMS systems, the better.

Just because a CMS system makes it possible to do things, doesn’t make them relevant to you. How many community websites have you visited where there are bulletin boards like an electronic Marie Celeste – floating along with nobody aboard? Check that the CMS system allows for easy addition of functionality later, but ensure that it does only what you need now. A lot of CMS systems seem to be based on the assumption that all anyone wants to do is spend their life blogging.

In reality, most smaller organisations probably just want to make routine updates to their website without having to call on a techie every time. If that’s what you need, go for something light like Modx rather than a tool like Drupal or Plone. 

Although advocating a cautious approach, you also need to think about what you may be doing in the future, to ensure that you aren’t stuck with a system that can’t expand to cope with more functions, and traffic. 

One example of this would be e-commerce, which is a field a lot of smaller voluntary organisations wouldn’t have considered three years ago, but would be quite likely to start using in the next three – does your CMS support it? (all four CMS discussed here support some form of e-commerce, although you have to double-check that the system is compatible with the type of secure payment transaction system you plan to use).

Who are we?

There is a world of difference between Oxfam and a local youth group run by volunteers. One is likely to have a team of in-house technical experts, and communicates with thousands of people, while the other doesn’t. This matters for CMS systems in a couple of ways; complexity and functionality.

Plone, for example, is a development framework that supports virtually any organisational activity you can imagine, but consequently, it is complicated and difficult to learn, probably a bit like flying a jumbo jet compared to a glider. Similarly, Drupal has the attractive feature of one core installation being able to support multiple different sites, which is fantastic for maintaining a multi-site, dispersed organisation.

On the other hand, if you are in the small group type, and don’t have access to technical expertise, be very careful about diving into fully-featured CMS systems; maybe all you really need is a simple blogging system like Google’s ‘Blogger’.

What’s the learning curve?

There are two aspects to the learning curve in using a CMS: initial set-up and ongoing administration.  You need to be at the least an IT enthusiast to set up most CMS as you need to be familiar with creating databases and configuring software.

Once installed, the CMS also has to be configured to organise content, users, and workflow as required. The complexity of these processes is related to the range of functionality provided by individual CMS systems. Joomla and Modx are considerably easier to set up initially than Drupal and Plone but it still takes quite a bit of developer knowledge to really get to the bottom of any of these products so that you can do things like customise them to meet the individual requirements of an organisation.

More importantly, you need to think about how the system will be administered once installed. Will content be maintained occasionally by one or two people who have lots of other things to do and aren’t interested in IT anyway? If the answer is yes, go on to check how easy it is to actually do routine tasks such as finding and updating text and images. 

For example, Drupal uses a sophisticated concept of everything being a node which can be categorised using limitlessly extensible taxonomies of keywords, but Joomla just allows organising by section and content.  However, which approach makes sense to the typical end user? If your basic requirement is to convert  your existing static website to an easily updated one, and you don’t have IT experts on hand, both Joomla and Modx will do that and are easy to grasp. 

On the other hand, if you are a larger, multi-faceted organisation that does have ICT support and plans to make the web a central part of it’s activity, then Drupal and Plone provide extensive functionality. However, you will definitely need access to coding expertise if you want to do things like customise functions to your precise specification. 

What’s the workflow model?

Almost any CMS will have a workflow model that organises the process of moving content from initial input through to publication. In some situations, an organisation may want staged publication, moving items from contributor to editor, to senior editor, to live.  It may also be desirable to have several editors in charge of different areas of a site.

You should work out how you want this to work so that you can evaluate whether a particular CMS does what you want. For example, ModX, has a relatively basic workflow management environment, whereas Drupal has a sophisticated range of possibilities (provided you activate and configure extra modules).

What’s the information model?

The information model describes how content is organised to make it possible to navigate and find it. The Drupal model is to tag items using a hierarchical taxonomy of terms, thereby allowing for an infinitely expandable model. While this is a very powerful model for large amounts of content, it may be a bit overwhelming for non-specialist users.

The much simpler model of sections and categories used by Joomla will certainly initially feel easier to grasp. Modx and Drupal both make no distinction between folders and articles, with both being seen as content items.  Again, while this makes plenty of sense to programmers, it may be tricky for non-technical users to get to grips with.

What are the user assumptions?

There is a suspicion that a lot of open source CMS are built by geeks for geeks, and it certainly seems true that systems seem to make assumptions about who is likely to use them. All of them seem a bit guilty of utilising jargon such as ‘nodes’ of content’, ‘snippets’ of code. 

Many of them seem oriented to being portals for communities of IT enthusiasts, so there are three columns of content, with an overload of links giving a busy, busy sense. Items have loads of comments below them, and a running counter of many thousand times they have been read this month. 

We once spent a lot of time deconstructing the Post Nuke CMS to make it applicable to a geographical community in the North of England, as opposed to an online geek convention in the USA. You need to ensure that a CMS can be easily customised to reflect who you are and what you want to do.

What does it look like?

Already touched on above, under user assumptions, the look and feel of a CMS tends to reflect assumptions about who is going to use it. The default appearance of Drupal certainly suggests it was built by coders rather than designers, although it is relatively easy to customise.

Plone has a reputation of being relatively difficult to customise, and certainly, you will not be able to pass it across to your favourite graphic designer and ask them to apply your normal look and feel by the end of next week. 

Similarly, with Joomla or Modx, you can certainly customise the display as seen by visitors, but customising the administration view is more complex.  However, many people may feel that the slightly standardised look of many CMS is a price worth paying for so much ‘out of the box’ functionality.

Is it accessible?

Accessibility measures the extent to which a CMS abides by World Wide Web Consortium standards for access, particularly for visitors with impaired sight. The core principle is that all site content should ‘degrade gracefully to text’ so that it can be read by a speech reader or text-only browser.

CMS vary wildly on this area with some (Joomla) being not too bad on the display-side, which is what site visitors see when they arrive at the site, but completely inaccessible on the administration-side, which is where the site is controlled by contributors, editors, and administrators.

Both Plone and Drupal seem much better on this but in Drupal’s case in particular, this is achieved by providing a much less visually attractive interface than Joomla. Joomla comes across very much like a desktop application by its use of icons, context menus, and popup hints, much of which is powered by JavaScript.

Some other CMS systems achieve similar desktop application results by using layout tools like frames and tables that are discouraged by W3C accessibility standards. However, a recent usability analysis of Drupal (PDF file) suggested adding more JavaScript to improve usability and user-experience.

This therefore presents a dilemma whereby precisely those features that make the application pleasant to use, also make it inaccessible. There may be situations where a small organisation can argue that non-sighted users will never be required to carry out site administration so discrimination is not an issue, but this is a major consideration for an organisation employing several people.

What about operating systems and platforms?

The majority of open source CMS seem to use MySQL as the database, with code in PHP, and run on Linux servers using Apache web server. This certainly applies to Drupal, Joomla and Modx.

Plone uses Python as the scripting language, which is sometimes seen as a problem because there are a lot more PHP coders out there than there are Python coders.  Also, the hosting options for Plone are more limited because it doesn’t run on the standard configuration described above, and will not perform well on the low-cost shared space web servers that small organisations may be limited to. However, the potentially higher cost of a Python programmer and hosting may seem justified, if you require a framework that supports a large number of different functions, sophisticated content categorisation, and advanced workflow management.

In addition to considering the requirements for running the CMS, you should also check about options for interacting with it.  Does the system operate equally well with all browsers and platforms, or do you have to use Microsoft Internet Explorer on a PC.

This may be less of a problem if your system is designed for a closed community like an Intranet, but can be very irritating for the general public. Admittedly, this is perhaps less of an issue for open source software, compared to commercial CMS, but it still applies and should be checked.

Check whether both the display as seen by site visitors and the administration system are cross-browser and cross-platform compatible. You may decide you can live with limited compatibility on the administration side, provided the display side is compatible, but bear in mind that web applications that abide by World Wide Web Consortium recommendations for standards compliance, also tend to score well on accessibility.

What’s the support?

All of the CMS discussed here have websites with documentation, support forums, and several also have books about them.  In addition to checking what’s currently available for an open source project, it’s usually worth doing some reading and checking that a given project still has mileage. 

For example, the Joomla CMS has emerged as a branch from an earlier system – Mambo, so you have to ask whether you are confident this will continue to develop, and if not, whether you are happy with it as it is for the foreseeable future. You can also join the online forums that are run by all these systems to get a sense of how active and approachable the system community is.

What’s the actual TCO?

TCO is short for Total Cost of Ownership and is typically used to measure all the costs associated with a piece of hardware, like a personal computer. It isn’t just a matter of buying it; there’s electricity, maintenance, repairs, and disposal to consider. 

In the case of an open source CMS you may have no initial cost but you have to consider the costs involved in initial installation and configuration.  A CMS like Joomla can be installed by anyone with a bit of knowledge and confidence around software, but even there it will still take quite a bit of time to get it just right.  Some further expertise will be required to customise the look and feel without damaging the underlying code, which may be why so many sites built using Plone look ‘Ploney’.

More expertise will also be required if customised functionality is required.  Consequently, you have to accept that for all but the simplest CMS operations there are development costs involved.  Admittedly, you are maximising the amount available for customisation rather than having to buy a product and then pay more to customise it, but  it won’t be free.

Useful links

General article on issues to consider before adopting a CMS

Feature on how to evaluate a CMS – written in 2002 but still relevant

General consideration of open source CMS applications

Comparison between Joomla, Drupal, and Plone 

User experience of setting up a site in Plone

Comparisons between Joomla and Drupal

Features comparison sites

CMS Matrix

Open Source CMS