Design and development of a content management system (CMS) for Yell Adworks’ corporate Intranet.
In the begining
When I first joined Yell Adworks it was primarily as an Intranet developer. A pretty specific role, but with a wealth of opportunity. The existing Intranet platform was creaking at the joints due to a rapidly expanding workforce and a mountain of content. It was basically unmanageable, and they needed a team to hammer it into shape.
Our first task, as a team of 3 developers, was to review the existing codebase and patch up the worst of the holes. This “version 2″ of the Intranet introduced very little new functionality, but it vastly improved the performance and went some way to fixing the unnavigable menu structures. At the time, we had a few fairly major technical issues: Firstly, 90% of the business was still using Netscape 4.x, which meant we were trapped in HTML table hell (CSS was just a dream) and awful browser-specific scripts. None of which was the fault of the original developers, I hasten to add, it was just the nature of a product that grew organically and rapidly to fulfil immediate requirements.
Thankfully, this little nightmare out of the way did a couple of things: Firstly, in made it clear that our exiting platform had to be replaced. It simply couldn’t cope with the increasing user load, and technically it was becoming extremely difficult to support (and somewhat delicate)…
Users matter
A group was formed, Intranet User Group, representing various areas of the business. Trips were organised to various physical locations (only in the UK sadly, I never got to visit the US or India!) to meet with users, and over time a large requirements list was put together. By engaging the users early and often, we hoped to make the Intranet far more for ‘them’, driven by their needs, rather than something pushed onto them by management. I loved the process to be honest – nice to get away from the computer and actually see the folks that the software really has an impact on.
Version 3
After a series of proposals that I co-authored with the Intranet team, the business agreed that we could look at a brand new platform that would be better suited to our business needs:
- Document storage, multimedia
- Support existing systems
- Simple navigation, Customisation
- Work across multiple physical locations, scalable, stable
- Social media
Version 3 of the Intranet needed to do many things that were not possible in earlier version. Most importantly, it needed to be scalable. We had, by this point, many times the number of employees than the originally envisioned and the business was continuing to expand. The Intranet needed to deliver multimedia, and needed to be easily managed by non-specialist users. Several existing smaller systems that relied on the current version of the Intranet needed to continue to integrate without having to also be rewritten.
Open source?
There was a big argument at the time over whether it was the time to go down the open source route or ‘stick with what we know’. From an arcitecural point of view, it made sense to base any new Intranet developments around an open source platform. Long term, easier to support and in theory easier to plug-in new functionality. However a number of factors also weighed against this: We had several ’large’ offspring applications that were heavily reliant on the existing Intranet. These couldn’t be abandoned easily, and writing new bridges between this systems would be particularly fraught given the range of skills we had on the team. Also, bear in mind this was a little while ago, and most of the open source platforms we take for granted these days (WordPress, Drupal and siblings) were far from mature enough for large corporate environments. The alternative to both of these was off-the-shelf software, but this seemed an expensive undertaking.
The decision was made that we would develop the core-product from the ground up, starting with a fully-fledge CMS, document repository and then a customisable user interface. Social media aspects of the Intranet would be provided via WordPress and PHPBB.
The platform
I was asked to design a platform that would fulfil the technical and user requirements, and along with the team we proposed a new Windows-based platform.
Each physical site would have a dedicated server, each server would have a database and file store that would ’round robin’ replicate using rsync and mysql synchronisation. By sticking to Windows servers, we would be able to maintain the existing ASP based application as well as introduce open source php to provide the social aspects of the new Intranet.
The business agreed to proceed with the project, and I was put in the role of Technical Project Lead, reporting a project manager and working closely with two other developers.
The design
From the start we knew we would be introducing new technologies to enable rapid development of the user interface. From both a general user and administration point of view it was critically important that we made the entire system as easy as possible to use – primarily because we wanted to open up content creation to a much wider range of business users.
jQuery and jQuery UI offered exactly what we wanted. While somewhat untested at this point, I trialled UI elements and developed a suit of scripts that would allow us to achieve the kind of ‘feel’ we wanted for the design without having to develop a framework from scratch.
Working with the team, we came up with a number of early design concepts that seemed to work really well.
The business decided that it preferred a more heavily ‘corporate’ branded design. I still think we missed a trick by not going with the more ‘web 2.0′ earlier designs.
The build
An initial 90 day project was put together, and construction began. During this process, the business was changing rapidly (first a company rebrand, then some large change in requirements). Following a loose agile process, regular communication with project sponsors and users enabled the product to be tweaked as we built. Weekly reporting to the project team, and in the latter stages of the project bi-weekly releases ensured that issues were caught quickly and small functional changes could be accurately estimated for delivery.
Code:
ASP Classic, jQuery, mySQL, PHP, JavaScript, CSS, XHTML, XML
Design:
PhotoShop, Illustrator, Flash