A Drupal Story, Part 1


A little over a year ago, a new web site was launched for Alton College. The site had been a year in the making – platform, design and content was all identified as being part of a large redevelopment project.

This is the first of a series of posts documenting our site development journey. In this part: our choice of platform.

If you haven’t already done so, it’s worth reviewing your own website via the Way Back Machine (otherwise known as the Internet Archive). Go back as far as you can – right back to the start of the records. In the case of the Alton College web site, this is February 29 2000. Not a good look, but perhaps about par for the times, certainly among educational organisations who had yet to appreciate the value of a quality website (but then nor had many businesses). You will probably notice a few characteristics that give away the production method – it’s FrontPage, and those buttons are pretty standard and often used features of the application at the time. You can’t really distinguish this business site from those of individual or community sites of the same period, or a few years later.

Fast forward to just three years ago, and we had a great site that was developed and maintained by a very talented developer. But herein lay a problem -we were reliant upon our developer for so many aspects of content production. It wasn’t just the page layout and style that needed a developer hand to make changes, but also to edit the content. In the twilight of the site, a simplified content management system was added, allowing for some text to be edited, however this didn’t enable us to keep as fresh and exciting a site as we would have liked. Time for a radical change.

Between 2000 and 2009 we had learned much; how to (and how not to) go about managing site development, which site features and functions are important to us, and what workflows the site infrastructure must support. A process of evaluation began, and we looked at a number of different products, all of them open source; Mambo, Joomla and Drupal.

Why open source? We already had experience in contributing to the Moodle community, the aforementioned developer had collaboratively contributed to the Chamelion theme and a number of different Moodle features. Open source was also being used to deliver our Individual Learning Plan. You have to invest in open source; it doesn’t come ‘free’, and you should certainly consider contributing something back to the community – whether that be directly in support of the product you happen to be using, or in sharing effective practices with others.

Honestly, there wasn’t much to call between Mambo, Joomla and Drupal; each has their own particular outstanding features. If we had particular needs from certain feature sets, one might have stood out above another, but since our needs were fairly generic, the differences were inconsequential. With this in mind we leaned toward Drupal, having some experience of the platform among our team, and knowing that features like the Content Construction Kit would go a long way to extending site functionality.

In my next post I’ll talk about how we analyzed and re-mapped our outgoing website, and the strategy we began to apply to our content.

3 Responses

Leave a Reply

Your email address will not be published. Required fields are marked *

Let\'s make sure you are human * Time limit is exhausted. Please reload CAPTCHA.