We’ve worked with Practical Action for many years developing their site and online presence, but back in 2010 they took the bold step to completely overhaul their site. This naturally involved considering both changes to the design and the system on which the site was built. After considering a few different systems the team decided on a bespoke path that led to the creation of a custom Content Management System that really establishes new foundations for the site to develop over the coming years.
Starting with the redesign
The design process was exiting, and working on such a large site was always going to be a challenge. The core challenge as ever is to find a way to effectively deliver all the content through an interface that pleases the visitor, helping them to clearly find and read content.
The designs needed to streamline the flow of content, simplifying the navigation and present a lot of content. Lots of time had to be given to planning content layout and we manage to nestle a lot of featured content into carousels on the home page and on all the category home pages as well as embracing a tab system for breaking up in-page content into usable groups. It helped that Practical Action had commissioned a report on their old site which provided some great recommendations including how menus should be constructed (one tier only for main menus). This helped direct early decisions and after a number of design concepts this final design was born.
CMS Highlights
We can’t go into too much detail about all the tech behind the CMS (that will follow in future posts), but here’s a snapshot of some of the features that have been created as part of this solution:
XML at the core
The key objective was to build a system that was not restricted to the web and build a flexible system for the future. To achieve this we needed to move away from the standard web editors and so devised a way to create content in XML. In essence we’ve developed a publishing system, rather than a web content management system. Editors write content which is stored as XML then our CMS, depending on the choosen the template, will be able to translate the XML into what ever media the end user requests. Currently the site is only delivering the content as web pages (HTML), however given the XML system underneath, this content could just as easily be delivered to mobile browsers, or used to create PDF’s ready for print or screen, or even syndicated to third-party services.
Reusable Content
Content is an asset and shouldn’t be locked to a page and given our ‘publishing’ mindset we needed to disconnect ‘pages’ from ‘content’. So the system allows content creators to work their magic using the editor interface as with any CMS, but to publish this content the users must assign this content to the site map to allow the content to be pulled through to the site. This ‘node’ architecture enables content to be repurposed in different parts of the site, allowing different ‘leafs’ or pages to use the same content. In future this same content could be used by a mobile sitemap, or even by a PDF system – allowing content to be written once and automatically distributed to multiple platforms.
Cross Linking Content
There’s no point having loads of content unless visitors can easily get to it so another key goal of the new system was to provide a flexible way for content creators to build lists of relevant content from their article.
We developed a pretty powerful query builder that allows editors to create a list of content based on all sorts of criteria. They can list content from a particular branch of the sitemap or list content that matches certain keywords.
Practical Action’s content is also tagged with information such as language, content type (case studies, technical briefs, annual reports etc) and audience (Development practitioners, teachers, MEP/MPs etc), all of which are available to the query builder, allowing the editor to build content relevant to the reader.
This feature is also being developed to automatically suggest content based on what the visitor is reading, much like how a shop suggest other products that you might be interested in.
Previewing Media
It was important that the fixed media, i.e. PDF, word documents etc could be previewed from within the site, rather than requiring the visitor to download the file to view.
We found a document viewer and built it into the CMS in a way that automatically converts media files into a format suitable for the viewer and will allow visitors to scroll through the media content from within the website, with the option to download it if its what they are after.
Currently only PDF’s are previewed through the viewer but plans are already underway to extend this to support other media files.
Delivering a scalable solution
The previous site was getting around 80,000 visitors a month, and had thousands of pages so this was a large site to begin. Ou solution needed to account for the growth plans of the client (i.e. delivering a system that could be easily managed and facilitate the new content) whilst also supporting the increased traffic and keeping the site quick to load. To do this we needed to embrace the latest tech and tools available to us to deliver a responsive site that would provide us with the foundations for future development. We knew from the outset that we’d be building the system on CakePHP which is a leading rapid development framework. Well formed code wasn’t enough though, so we embraced the cloud technologies at Amazon to deliver the site on a load balanced hosting platform. A complex caching system was devised to keep request times down and that cache is synchronized across all servers in the cluster. All amazing tech we will write more about but that’s just the start…
Delivering content around the world
The site carries a great deal of media that is accessed by users across the world, so it seemed only sensible to build the CMS on a Content Delivery Network (CDN). When a user publishes media from within the CMS, the system pushes a copy of that file to the CDN. The website when listing media, uses the CDN version of the file, allowing the visitor to download the file from a web server in their region (rather than having to transfer that data all the way from the UK). Essentially the CDN means that there are copies of the media on servers across the world and when a user wants the file, Amazon will allow them to download it from the location closest to them to allow the file to download quickly. We’ve also embraced the CDN’s access control via the CMS to allow certain documents to only be available for download when a visitor is logged in – very slick. Needless to say any images and files used by the sites core code are all delivered via the same CDN to ensure load times are kept snappy.
Creating little workers to bear the load
There’s so much going on behind the scenes of the CMS that we want to create a window into the world of “little helpers” so users can see everything that gets carried out to ensure the site is blazing. The principle behind developing a process queue, was that we did want administrators having to wait while for the CMS to finish doing all it needs to do when a page is published. So from the users perspective they click a button and see a response – job done. But behind the scense the CMS’s little workers busy away to:
- Create the necessary thumbnail images (used on the listings) for the content
- Add the content information to the search index
- Push any associated media to the Content Delivery Network (CDN)
- Convert any associated media to the format required for the sites document viewer
Migrating from old to new
What’s a shinny new site with all these great features if there’s no content? Probably one of the largest and most difficult tasks of the project was to import the existing content from the old site to the new site as well as import all the documents and carry across existing user accounts. To give you some idea of the scale, here are some approximate figures:
- 4,500+ web pages
- 3,500+ documents (PDF’s, word documents etc)
- 64,000+ user accounts
The process wasn’t without it’s glitches, cleaning the old data and preparing it in a format for the new system was quite time consuming. Remember we were moving from a traditional CMS that had allowed users to create content in HTML, to a new system that wanted to remove that dependancy from content and reformat content to XML. We also needed to ensure that old content would be presented in the new layouts, so we devised an import system that allowed the administrators to pick an old page and convert it into a new page. This would involve selecting the one of the new templates available and assigning old content to the various parts of the new page. Let’s not forget the sheer time to process the all the physical documents and ensure they were all uploaded and synchronized with the CDN correctly. We were even able to recreate the user accounts on the new CMS without having to reset any of their credentials, so they were all able to login with their details without any potential blockers to them accepting the new system.
Check out the site for yourself: http://practicalaction.org
