For many years I have developed websites the old-fashioned way. I have used the MicroEMACS text editor and Unix/Linux command line tools to create HTML/Javascript and Perl/PHP CGI files entirely from scratch, and installed and configured MySQL databases and Apache webservers the same way.
This is the way software engineers often create websites because it allows them to concentrate on the functionality and logic of the website without any of that wishy-washy graphic design or usability nonsense getting in the way to slow things down.
This is a great way to learn the nuts and bolts of how a website works, but the resulting websites have two significant problems:
- They look very boring and fail just about every usability test you can think of.
- Once they get above a certain size (say about 30 or 40 pages), they become an incredible hassle to keep updated.
To help with problem 1) I would sometimes enlist the help of a graphic designer who would give me a decent-looking HTML template which I would then splice into my web page files and use header and footer files with SSI directives or Perl file commands to help with problem 2).
This only took me so far however, and I realised a couple of years ago that to have a modern and effective website that ticks all the boxes of usability and effectiveness (see my previous blog posting ‘What makes a ‘webmaster’?‘), I needed help from some fancy software. And after reading ‘Information Architecture for the World Wide Web‘ & ‘Don’t Make Me Think!‘ I realised that there was more to websites than just throwing the contents of a database onto the web.
Luckily I managed to persuade my employers to cough up some cash for a copy of the Adobe Creative Suite 3 (CS3) package and this contained applications that helped immensely when it came to maintaining a medium-scale website (see my previous blog posting ‘Spend some money if you want a serious website‘).
However, even with the rich functionality of CS3 I came up against a problem – allowing the website to be edited and updated by a disparate community of users of differing levels of technical ability. This is essential for a medium-scale website – one person alone cannot maintain the content of a website like this.
Even a website support team full of technical people cannot do this properly – a good website is a collaboration between two groups of different kinds of people – the technical web-savvy people (software engineers, database administrators, graphic designers) and what I like to call ‘domain experts’ – the people who know what content should appear on a particular website that represents their interests, when it should appear, and in what format (e.g research academics, business & marketing executives, journalists).
These two groups of people often have skills and experience that does not overlap much. The problem is in finding a method for these two groups to collaborate effectively to develop the website. I was inevitably drawn into the world of Content Management System (CMS) applications to find a solution to this problem about a year ago.
I had used CMS applications before, notably Zope/Plone, but the results had been mixed (see my previous blog posting ‘‘Free’ software, the open-source planet and Plone‘). I investigated the Moodle, Mambo, Joomla and MODx CMS applications (which fit into a similar open-source niche and use LAMP technologies) and finally settled on one application that satisfied the requirements that I needed – Drupal.
Drupal is an open-source PHP/MySQL-based application that has a large and diverse set of developers and users that have contributed a rich set of functionality and support to the application, and it is widely used by academic institutions. It fits very well the requirements of my main professional website, allowing users to log in to the site with their browsers and edit the content of webpages with an intuitive and simple WYSIWYG-style interface that requires no more technical knowledge than creating a Microsoft Word-style document, and its installation and configuration (via ‘modules’ and ‘themes’) is extremely flexible. See a sample screenshot of the Drupal WYSIWYG web page editing interface here.
Counting on non-technical ‘domain experts’ to keep a website maintained in this fashion is only possible if the experience curve to effective editing flattens out rapidly, and the initial entry hurdles are low. Typical ‘domain experts’ do not have a couple of days to go on a training course to learn how to use a new IT system, and if it is not immediately obvious how to use the system they will give up, never to return (sometimes after only a few minutes, in my experience). Wiki-based websites would also simply not function if they did not offer an easy-to-use editing interface.
The Drupal CMS addresses this issue, but many CMS applications do not – large ‘enterprise’-scale commercial CMS applications such as Polopoly sacrifice an intuitive editing interface for a rich feature-set that appears to be trying to be a panacea for every potential situation, but locks out the type of users that I am trying to cater for.
You can see the results of my use of the Drupal CMS application on my main work website, www.erp.ac.uk.
Martin
Nicely put.