When the CIPR asked us to redevelop their website, we jumped at the chance to bring open source technology and web standards to an organisation that represents and promotes the marketing communications industry.  With 9,500 members – all professional communicators – it was a daunting task to produce something that the membership would approve of.

We chose to use Drupal – having successfully built Drupal sites for the likes of News International, we knew we could hit the ground running and end up with something that would be able to serve the CIPR for several years.

The challenges

The existing site had 30,000 static HTML files, with widely varying markup and no style consistency.  Because the site was really difficult to edit, many of the most active areas had been spun out into microsites with an asp.net based proprietary content management system.  These microsites were editable by their respective content owners, but with no oversight, and with complete content control available to the editors, so styles began to diverge even more.

A number of third party services and applications needed to be integrated into the new site. Eventbrite for event ticketing, ezProxy for access to academic journal services, and the CIPR’s own Ladder CPD system (another Assanka project).  For Ladder and ezProxy, we needed to be able to authenticate CIPR members outside of Drupal, so we would need to have some kind of single sign on system centered on the Drupal site.

Details about the members themselves are held in the CIPR’s membership system, a client-server application with a Windows front end and a Microsoft SQL Server database.  On the old site, synchronising this with the database the website was using for authentication required a long manual process and, for some reason, a number of Microsoft Word mail merges. The membership system is here to stay, so our solution would need to vastly improve on this process to get member profile updates into the website far faster than was possible before.

Finally, it’s worth mentioning the workflow challenges. Under the old site, the institute’s staff had to email their requested changes to the web team using a Microsoft Word based form. The web team would implement them “within 5 working days”, by editing static HTML files manually, and could not provide any content oversight, only the technical support to put the content online. For a new site to be successful, the management and oversight of the institute’s web output would need to change completely.

Build process

Our build process followed a fairly typical sequence:

1. Site map workshops: We gathered together and worked with the main content creators and heads of department. Over a number of sessions, and using a lot of Post-it notes and a very large wall, we produced a site map.  The site map was transferred to Mindmeister, where it continued to be collaboratively edited and refined.
2. Wireframing: We produced wireframes of a new home page and typical article pages, to explore the organisation and prioritisation of content.  We needed a number of different, flexible content positions to accommodate a variety of content and media.
3. Creative concepts: The wireframes were used as a basis for producing creative concepts to establish a new stylish look and feel for the site.  Three concepts were presented, from which the CIPR chose one.
4. Standardisation: From the concept mock-ups, we derived a set of design standards. This is where we sought out any inconsistencies in the design and attacked them to produce a documented design standard that would be used as a rule book for developing the remaining layouts. The standards cover column layouts, margins, font and colour palettes, image aspect ratios and sizes, paragraph formats, heading levels, link and button styles and all interaction styling.  It’s easy to forget interaction styles – for every button, for example, you need a standard, hovered, pressed and disabled style.
5. Layout development: Using the design standards, the concepts were expanded into the dozen or so different layouts that would be used in the final site.
6. Rendering: With all layouts complete, HTML templates and an optimised stylesheet could be produced to serve all the layouts.
7. Drupal build: Skinning Drupal with the new templates, installing and configuring all the content types and modules we would need, and writing our own bespoke modules for our special requirements.
8. UI behaviours and trackers: JavaScript libraries and loaders for all the interface behaviours, with graceful degradation for users with JavaScript disabled.

Special features

Much of the functionality of the new site came out of the box with Drupal, but we added some of our own modules to enable some particular functionality:

Node image

Our design called for image based teasers for content pages.  You can see examples of these on the homepage of the site, under ‘Features’.  The image used for the feature teaser cannot be required to be part of the content of the page itself, so it has to be separately mapped to the node.  Additionally, our design standards mandated a specific aspect ratio for all images on the site, and four specific valid sizes, so all images, whether used for feature teasers or within the content of the node, must be made to fit these design rules.

To achieve this, we wrote a new module, which we call Node Image, and a TinyMCE plugin called Node Image Chooser, to replace the standard TinyMCE Image insert/edit dialog.  The Node Image module also alters the node edit form to add the ability to attach images outside the content body (to serve as feature teasers).

The form for uploading and editing node image nodes provides a cropper tool to allow the user to preview the original uploaded image (often a digicam photo at a far higher resolution than desired), and crop the four valid image sizes out of it, using a draggable frame with a constrained aspect ratio.  This allows editors to quickly create the four variants of each image, so for any image we can always offer the choice of all four possible sizes, without requiring editors to be trained in image manipulation software.

Restricted content

We needed to be able to protect some pages so that they were only accessible by CIPR members or even a smaller subset of the membership who were perhaps members of a particular regional or sectoral group.  However, access to this information is one of the most important and valuable benefits of membership, so we wanted to ensure that non-members could see that this content existed, even if they couldn’t access it themselves.

Many newspaper sites handle this situation with a concept called a content barrier.  The user is shown a teaser of the page content, and a message indicating that in order to read the remainder of the content, they must pay a fee or register.  We started with the existing Restricted Content module, but completely rewrote it to support tokens and offer completely different views to anonymous users versus those who were logged in but simply did not have the required role.  We’ve released these changes back to the community – our modified version is available on the Drupal project page.

We married this module with a bespoke (and very simple) robots login module, which identifies legitimate search engine crawlers from Google, Yahoo and Microsoft, and allow them to view all protected content as if they were members, but with a NOARCHIVE restriction.  This further contributes towards our goal of making this member only content visible to non-members by allowing them to find it via a general web search, though they still need to join in order to view the full page.

Single sign on

We didn’t just need to authenticate users for the benefit of Drupal.  We also need them to be logged in for other sites as well, notably Ladder, the CIPR’s Continuing Professional Development system.  We wanted to ensure that users did not have to log in several times to access these services.  So we turned Drupal into a single sign on hub.

Our solution starts with the Login Cookie module, modified to support tokens and shared secret based signing.  When users log in, we use this module to set a cookie containing various particulars about their user account, and a signature that can be verified by co-operating apps on the same root domain.

The second part of the solution is the need to redirect users to a querystring-specified destination on login and logout.  This is to enable users initiating login directly from an external app to be seamlessly redirected back to it after their login has been processed.  We started with the Login Destination module, but found this to be over-engineered for our needs in many ways, while it also missed a key requirement – redirect on logOUT.  So we ended up writing a bespoke module for this.

Finally, the services module gave external apps that read the SSO cookie the ability to query the user’s full Drupal user account to get the details that we did not include in the cookie.

Social sharing

Our requirements included the usual need to allow social sharing of content via Digg, Facebook, Twitter and so on, as well as the ability to send pages by email to friends, and bookmark pages in the browser.  All these were easily solved with AddThis which also adds analytics into the bargain.

Inline audio and video

The CIPR needs to be able to include videos from Youtube and Vimeo, and publishes its own video content via Vzaar, all of which have straightforward embed codes, but there’s no simple way to insert these into TinyMCE in a way that allows the designer (not editorial users) to control their dimensions and style.

We wrote a new TinyMCE plug-in to replace the media plug-in, which allows CIPR editors to find an online video and just paste the URL into the plug-in dialog.  The plug-in recognises the URL format, queries the API of the appropriate video service provider, and displays the video title to the user to confirm they have the right one.  The user can then simply choose which of our standard image sizes they wish to use for the video player – ensuring that video players are shown at exactly the same size as embedded images.

This continues a theme of replacing complex functionality with alternatives that separate content decisions from style at the admin level.  So if an editor wants to insert a video, they should not have the choice of what width and height to assign to the player.  That is a decision made by the designer, not user.  So our plug-ins don’t offer the choice.  As a result all the CIPR’s videos are presented in the same way.

Audio files are embedded using the same plug-in, recognising the file as an audio format, and embedding the excellent Google Reader inline mp3 player.

Forms

The CIPR needs loads of forms.  Membership applications, renewals, applications to join groups, entries for awards competitions, and so on.  Drupal’s capabilities to create arbitrary user defined forms and aggregate the results did not really do the job, so we turned to the service provided by Formassembly.  This third party service allows a non-specialist end user to create a wide variety of forms, and process results in many different ways, as well as providing useful connectors such as Salesforce integration and one-off Paypal payments.

We created a TinyMCE plug-in to insert verified Formassembly form IDs into a specially designed machine tag in the content of any page.  We paired this with an output filter that converted the machine tag into the full HTML of the form, making a few changes to it on the way through – tweaking Formassembly’s HTML mark-up slightly allowed it to be styled by our CSS without having to include a second set of form styles.

Search

Drupal does offer user facing search via various means, but we felt that we needed something really awesome to make up for the years of having no search on the CIPR site at all.  We wanted something that offered a great relevance engine to surface the best matching content.  In short, we wanted something like Google on a small scale.

Fortunately, for a fee, that’s exactly what we got.  The search engine on the CIPR’s new site is powered by Google Site Search, a paid-for API-driven service that builds and uses a dedicated index on Google’s servers, but is delivered and branded entirely within your own site.

Course finder and member directory: searchable views

The old site already had a directory of members, and we wanted to maintain that, and add directories of PR suppliers and courses as well.  The Better Exposed Filters module came in handy here, providing an excellent checkbox list interface to options such as level, cost and type of course.

Events calendar and Eventbrite integration

With the CIPR’s events all managed on Eventbrite, we needed some close integration between the Eventbrite accounts and the CIPR site.  Using Eventbrite’s XML feeds, we perform a regularly scheduled import of event data and use it to populate Event nodes within Drupal.  Eventbrite already provides a lot of meta data – and we add a machine tag in the Eventbrite body text to link the events into courses within the CIPR course finder.

This also enables features such as listing all available dates for a course on the course page, and allowing users to navigate to alternative dates from an event page.

Meta data

The existence of content types like courses and events made us think that it would be really useful to have the ability to assign arbitrary key-value data to any node, and display it in a table alongside the content, in a similar way to Wikipedia’s boxes.  We used CCK fields to collect the meta data and a custom block to display it.

Content types

Our full set of Drupal content types are:

• Standard page: A flexible content page
• Blog post: Automatically bylined and aggregated under an author or topic.
• Course: Anything that can loosely be described as a training course is created using the Course node type, which has additional CCK fields for properties such as length, level, type, cost and accreditation.  This then powers the course finder.
• Course provider: Used to record details of an institution that provides training courses.  A course is linked relationally to a course provider which allows course provider pages to display a list of their available courses.
• Event: A single event, normally an instance of a training course, imported from Eventbrite, linked to a course
• Forum topic: Using the forums module, forums provide discussion areas for groups
• Node Image: Our bespoke node type for constrained-size images

Optimisation

Finally, we thought we would share a few tips on optimising delivery and measurement.

• Third party JavaScript loading: We use JavaScript from a number of third parties, such as AddThis and Google.  We developed a simple scheduled task to download these libraries and cache them on our servers so that we could deliver all the JavaScript to power the site’s UI behaviours in as few downloads as possible.
• JavaScript grouping: We group all our JavaScript files into two downloads – one in the <head>, and one just before </body>.  A script in our theme concatenates the script files, and also returns 304 Not Modified responses whenever it can.
• Tracking 404s: It’s really easy when using Drupal to make the mistake of including your tracking JavaScript on your 404 error page.  Not only does this incorrectly inflate your traffic figures, but it’s a lost opportunity to create a useful broken links report.  We use Google’s recommended method for tracking 404s, and then we filter them out of the website profile we use for reporting traffic numbers.
• Caching of twitter / facebook feeds: Updates posted to the CIPR’s twitter and Facebook accounts are downloaded on a schedule and cached on our servers as fully rendered HTML to allow them to be included in our pages at the final stage of assembly.
• Feedburner: Using a simple user-agent and request-uri based redirect in an Apache rewrite rule, all end user requests for RSS feeds are diverted to Feedburner, which provides excellent analytics to let us know how many readers are consuming each of our RSS feeds, using which devices or clients.  It also reduces the load on our servers to have over 95% of our feed requests answered by Feedburner.