Postal heritage and Plone, or: how I learned to stop worrying and love Content Management Systems

'Plone' is the name of our Content Management System (CMS). This is the story of how and why we came to use it. We are sharing our experience in the hope that it might contain useful lessons for another organisation in similar circumstances.

Part 1 - The Client's Point of View

Part 2 - The Developer's Point of View

Part 1 - The Client's Point of View

'The Client' is Steve Gardam, Access Manager for the BPMA.

I originally wrote this for the Museums Computer Group newsletter in autumn 2005 to show the lessons learned from the development of a Content Management System (CMS), for the benefit of colleagues across the cultural heritage sector.

The background to the project

In April 2004, an independent ‘Postal Heritage Trust’ was established by Royal Mail Group. This new trust took responsibility for The Royal Mail Archive and the former National Postal Museum collections, taking over from the Royal Mail Group Heritage business unit. As part of the handover, the website www.royalmailgroup.com/heritage was extensively revamped and Postal Heritage Trust branding applied. Royal Mail Group continued to host the site on their server.

The website content was reviewed in June 2004, and we found many small content errors. This became a bigger problem, as it emerged that the previous ‘friendly’ arrangement to update content was no longer possible, as Royal Mail Group had outsourced its ICT. The high cost of editing content meant that the site was to stagnate for several months. Perhaps it was a blessing that we could not obtain website visitor statistics during this time!

New brand, new website

To further complicate matters, the trust was already in the process of developing a new public identity: this was finalised in autumn 2004 as The British Postal Museum & Archive (BPMA). We wanted to operate under this new brand, but our website still referred to the ‘Postal Heritage Trust’, and our URL was www.royalmail.com/heritage - this was confusing enough for the staff, let alone the public.

Whilst the web is important to most museums, for us it is crucial: the BPMA does not currently have a physical museum site for daily visitors. We offer an archive Search Room for research with a small display area, whilst our museum objects are kept in a store building which we can only open to the public a few times a year. Until we have a new site, the BPMA website must provide the public with whatever they need from us. We need our website to be as good as possible to serve and increase our audience, presenting a quality face for our organisation.

By June 2004 some things were clear:

Our site carried a reasonable amount of information, but the branding needed to change, and the content was stagnating.
We needed to get direct control over the website. This meant getting our site out of Royal Mail and onto an external server. We could then get a better URL, and implement the new brand.
We didn’t have any HTML experts on staff, so to keep the site fresh, a Content Management System (CMS) seemed to be the answer…

Addressing these issues would provide us with a logical domain (www.postalheritage.org.uk), providing sensible and current content, wrapped in an up-to-date brand.

What did we do?

We appealed to the Museums Computer Group listserve for recommended web development companies to provide a CMS. We knew we would also need the company to implement our new brand on the site (although this was hampered by not yet having the brand guidelines when we started this process).

We were simply looking to get our hands on the content of our own website, rather than radically overhaul the site architecture at this stage. Being able to update content, move content and keep the site information fresh and relevant to repeat visitors would represent a clear advance. This was about getting the basics right, to provide a foundation for future development.

Working out the details

Our initial appeal to MCG was successful – it provided a decent spread of companies to try, but not too many to be confusing. Before we wrote a detailed invitation to tender (ITT), we emailed companies to ask if they were interested, and narrowed it down to about five who said that they were interested in the work. We emailed them with a few more specific requirements, such as allowing us to present and maintain our collections catalogue online, and an image ‘slideshow’ feature (like the BBC’s news stories in pictures). We then took their initial responses as basis for detailing even more specific requirements in a full ITT.

This approach was not perfect. The ITT filled the role of a project brief, but we should perhaps have spent more time working out what we wanted before contacting any companies. Some of the companies considered that they had put in sufficient work in answering our early queries, and did not provide a fuller answer to the ITT. However, getting information back from the companies before writing the ITT helped us understand more of the options available to us. It also showed the companies’ approach to working with us. We had not done this before, and it was a learning process for BPMA staff.

Who did we choose?

We decided to work with Adaptive Technologies Limited (ATL). We found ATL’s responses to our queries measured and open. We also felt that they had the greatest understanding of the heritage sector, perhaps because they are themselves owned by a charitable trust and are based in a Regency heritage centre, in Brighton.

We liked the fact that ATL’s solution suggested using open-source software (Plone) for the CMS, as we were wary of getting tied in to a company-specific (proprietary) system. There were no real differences in price between the companies, because they all tailored their solutions to the ballpark budget we stated. Our choice was based on the overall approach of each company to working with us, and I’m pleased to say we have made a good decision.

Clarifying what we needed

ATL later told us that whilst our ITT had been okay, its main flaw was to try and anticipate the solutions to the issues we raised. For example, where we asked specifically for some kind of CMS, we could have simply said ‘we want to be able to control the content of our website’, which would have lead to the same conclusion.

This makes sense: let the experts present the best solution to a core aim. However, we were consciously trying to detail as much as we could think of at the outset, in order to not get caught out at a later date by paying extra for something we had assumed would be covered in the initial price. There is a balance to be struck here. You cannot do the developer’s work for them, but you must feel confident you have thought about your project in detail.

Communication between client and developer

Our working relationship with ATL developed over the months of the project, and since its completion. A small but important change was from emails to telephone calls. We preferred emails in the early stages in order to maintain a correspondence record. However, sometimes written communication can be a little restrictive, and now it is much more common to pick up the phone and have a chat, with key decisions still being recorded in a subsequent email. Although this is a personal preference, it also keeps a more ‘human’ element in the working relationship.

Ongoing communication with ATL has been the single most important factor in the success of the project, and has justified our choice to work with them.

How did the project progress?

The contract with ATL was finally agreed in December 2004, some five months after we took the decision to start this project. Why did it take so long, considering that we wanted to get control of our website content as soon as possible? The answer is a common refrain in any account of a web project: it always takes longer than you think! In our case, we needed this much time to work out our initial requirements, contact the various companies, write a detailed invitation to tender, make our choice, and finalise the contract.

Reasons behind the slow start to the project

These things could have been accomplished faster. However, like many heritage ‘web managers’, the website is only one of my responsibilities, so I had to balance this with other work. Likewise, the other people involved in the process (ATL, Royal Mail Group ICT staff, BPMA colleagues) could only devote a portion of their time to preparing the project. The lesson here is that the schedules of participants in your project will not mesh perfectly. This leads to time gaps between periods of activity, and these quickly aggregate from days to weeks to months. This is no-one’s fault, but it is a hard lesson to learn.

With the rosy hue of hindsight, once the contract was signed the actual project was quite straightforward. Following initial meetings and discussions, there were periods where we did very little, allowing ATL to carry on developing the CMS at their own pace. It can be frustrating to not have sufficient technical knowledge to understand what is happening to your own website, but ATL were willing to explain anything whenever asked… the trick was to remember to ask!

Getting what we asked for

Despite thinking that we were clear on the scope of the project, there was an element of ‘expectation creep’, which we had to come to terms with. I think that this was partly a result of the five months it took to get to signing the contract.

ATL had interpreted our requirements very literally: we asked for a CMS and we were getting one. However, during CMS development we were beginning to fully implement our new BPMA brand across the organisation. Although we came to an arrangement with ATL to implement a basic site rebranding, this was secondary – to ATL – to getting the CMS created. However, as this rebranding was a visible sign of change to our website, I think we felt that the changes should look more profound. It took some time to appreciate the difference between what we had asked for and what we thought we would be getting.

Our main aim at the outset was to get a controllable and extensible website, but as the project progressed we more clearly understood we had only just begun our web development. We have continued to work with ATL on the site architecture, the online Shop, improvements to the online catalogue; and will continue to seek ways to give our users the best possible internet experience.

Project timetable

The project timetable ran from December 2004 through to March 2005. This deadline linked into rolling out the new BPMA brand, in time for our first major public event in April 2005. We needed the marketing for our event to refer to an up-to-date website which matched our new identity.

Although the final deadline was March 2005, the project timetable did specify an ‘ideal’ deadline in February – in other words, we built in slippage time, trying to apply the lessons of the five months it took to get to the contract point. As it turned out, we ended up working to the final March deadline anyway, so it was as well that we had allowed for this.

Nevertheless, I think the project could have been finished sooner than March. The site was on a test server from January 2005 and there were several weeks in which I could have practiced with the CMS, and edited content at the same time. However, because I was not directly contributing to the technical work done by ATL, I did not focus on the project day-to-day. I often found that I eventually got round to thinking about the CMS on a Friday, having spent the rest of the week working on other projects… Necessary for my other work, not very constructive for the website.

It is not easy for heritage staff with diverse responsibilities, but I think whenever you feel like ‘the developers are just getting on with it, I don’t need to worry’, that is probably the time to give your web project more attention!

The pleasures of Plone - learning to use the CMS

Learning to use the CMS was initially a very frustrating experience, but no different than learning any new ICT application. For example, when using the WYSIWYG editor, copying in text from Word documents can sometimes lead to muddled formatting, but this is something that is learned, anticipated, and then becomes less of a difficulty. I got a great deal of CMS practice working through the entire site at the time of launch in late March 2005 (having put this off until the final deadline approached).

The system becomes increasingly intuitive with practice, and the user interface is logical, with options to view, edit and publish pages. At our request, ATL built a publishing workflow into the CMS, enabling authors to create content and publishers to review and publish. For most of the first year of having the CMS, I was really the only member of staff using it - doing news stories, creating exhibitions from curatorial research, updating visitor information.

Since February 2006 we have been rolling out training to all staff; starting with a big 'Web Week' and then offering scheduled and ad hoc training. We have recently been using our own internal project management programme to devolve direct responsibility for certain sections of the website to staff teams, although there is ongoing support from me and my team.

Things to be wary of...

The logic of the interface has occasionally proven to be a false friend. For example, the content is arranged in folders containing documents and flies, much like Windows Explorer (WE). However, the behaviour of the CMS folder structure is not a perfect analogy for WE, which I nearly learnt the hard way when I cut out some data and was unable to paste it back – happily ATL was able to rescue the missing content. ATL have promised several improvements to the system, which they have developed working on subsequent projects for other clients, but we will have to choose to have a comprehensive upgrade to gain from all of these.

The CMS ran very slowly to begin with, but ATL acknowledged this and worked on it to improve the speed. Having spoken with colleagues who use different CMSs, our Plone CMS now runs at a rate they would consider typical, if not better.

It can still take longer than you expect to edit or produce content. You need to consider maintaining and checking links, creating folders as well as documents, uploading files, resizing images (using Photoshop) and reviewing the formatting of any content you create. Again, I do not think that this is unusual for a CMS, but it must be borne in mind. Doing good work always takes - and deserves - time.

In conclusion

The purpose of the article has been to give an overview of how the BPMA came to find ourselves using a website CMS. Many of the points I have been making are not new, such as: find a web company with which you feel comfortable working; try and remain clear on the project parameters and be wary of ‘expectation creep’; using a CMS still takes time. However, these are all points worth repeating. It's also worth noting that we didn't use any kind of formal project management methodology for this project, which would have undoubtedly helped with the planning.

Our CMS experience at the BPMA has been a very positive one thus far, and I hope this comes across as encouragement for anyone considering a similar path. Our situation in the BPMA is an obvious parallel for many local authority museums, whose ‘websites’ often sit as part of a larger local authority site, with all the restrictions that can bring.

Thanks to having taken firm control of our online presence, we have improved our web services since March 2005, including working with ATL on our first major digitisation project. Everything that we do online enhances our relevance to Royal Mail Group (our main funder), so from this point of view what we have achieved is not so much independence as devolution, which brings benefits to both sides.

The success of our CMS for the BPMA is simply shown in the statistics: our first full month of statistics from April 2005 saw 2,967 unique visitors; a sad reflection of the stagnation of the site over the preceding year. By the end of 2005 this had more than doubled, and throughout 2006 the average has been around 8,000 people every month; which represents around 95% of the BPMA's total public engagement. In September 2006 it leapt up to 11,707 unique visitors; a fourfold increase inside 18 months. This is a result of work right across the BPMA, but the CMS means we can bring this all together online.

Part 2 - The Developer's Point of View

'The Developer' is Danny Hope, Creative Director for Adaptive Technologies Limited (ATL).

This is an account from the developer's perspective, concentrating on the two areas most important to me:

Plone - making the site editable
Usability - making the site work better

What is Plone?

Plone is a powerful, open source CMS that enables non-technical users to create and edit the content of their websites.

Users simply sign in to the system using a web browser, navigate through their site to the page they want, and modify the content with easy-to-use tools. This might involve editing text, uploading images or adding other types of information such as news items, events, or downloadable files. In the case of a website that has a number of different contributors, Plone's built-in workflow and publishing mechanism enables new content to be checked and authorised before being published to the public site.

Why Use Plone for this Project?

There was a time when open source software was viewed with some suspicion. Nowadays it is widely accepted that, with a worldwide development community behind it, open source software is often better that its proprietary equivalent and it is routinely used by health authorities, government departments and other large organizations.

A major factor in deciding to use Plone for this project is the flexibility it brings - putting a website into Plone renders every page editable, which means that it is free to grow in any direction the client chooses, unconstrained by foresight or technology. In addition, and like all good content management systems, the use of Plone forces a separation between content and style - the content is drawn into the Plone page template and displayed according to its associated style sheets.

This latter point was particularly important because the BPMA was preparing to implement its new public brand while the CMS website was being developed. By using Plone we could get on with building the website and add the new branding later. This avoiding interrupting the site's availability to the public, and at no greater cost than if structure and style had been developed simultaneously.

Another factor in the decision was more personal: for some time I had been researching the requirements for a new CMS that I would design, and that the ATL in-house team would build. My new CMS would be a universally accessible and usable vision of beauty, capable of letting anybody edit any website quickly and easily, it would be perfect… I felt this was within ATL's very strong capabilities, until I discovered Plone. I was so impressed by what Plone could offer that I abandoned the idea of a new CMS, and decided to join the open source movement.

Customizing Plone

Although Plone is a very powerful and up-to-date system, our experience of working with end-users indicated that Plone's 'out-of-the-box' editing interface could be improved, particularly in terms of usability. With this in mind, our development team tested and implemented a number of significant changes. These now provide an easy-to-use CMS for the BPMA and a better version of Plone for us to offer other clients in the future.

As well as these general enhancements, we also wanted to ensure that the CMS was suited to the BPMA's actual working practices (CMSs tend to fail when they force organisations to make unpopular changes to their working practices). To do this we conducted on-site interviews with BPMA staff to gain an understanding of how they would use the system; studying their working practices, understanding their expectations for the CMS, and analysing how its introduction was likely to affect the organisation.

This study led us to remove unnecessary or overly complicated features and add a number of custom tools to the system. We also used our analysis to configure Plone's built-in workflow mechanism to suit the BPMA's working practices, reducing resistance to the introduction of the CMS by making it friendlier to use.

Usability

While the main aim of this project was to provide BPMA staff with a CMS, there was general consensus that, in the meantime, the usability of the site also needed to be improved and that some of the project budget should be directed towards this.

Although extensive usability research was out of the question, it was still possible to improve the website's usability based on experience, knowledge and usability heuristics (recognized rules of thumb). While not perfect, this is can be quite effective and was certainly achievable within the budget.

Page layout and navigation

A basic requirement of web navigation is to show the user where they are, where they have been and where they can go next. In this, the usability of the BPMA 'pre-CMS' website was clearly restricted, since the navigation system provided no feedback as to a visitor's current page location and no indication as to which pages had already been visited.

Many modern websites employ a 'breadcrumb trail' to indicate the path taken to arrive at a particular page and, while we considered such a feature, we opted instead to build this functionality directly into the main menu system and enable the site-wide navigation to keep visitors fully informed.

We also added a site search facility and an improved site map page: both are built-in features of Plone. In the case of the site map, this is created dynamically and automatically updates itself each time new content is added.

Information Architecture

Our analysis of the existing site led us to conclude that visitors would benefit from some simple modifications to the site's information architecture Ð the structure and presentation of the site's content.

We were careful to implement a backwardly-compatible system that would redirect users to an equivalent page if the one they requested had been moved. This is much better than a 'Page Error', which so often happens when websites are restructured.

Although the site's information architecture is now more rational, it can get better yet. The BPMA have an ongoing plan of improvements in this area, and we continue to work with them offering advice and support.

What's next?

We have already worked on three significant projects for the BPMA following the initial CMS project. We have increased the usability of the BPMA online catalogue software (DS CALM), to help it fit with the rest of the Plone website; introduced the Plone Mall online Shop facility linking to WorldPay; and added new Plone functionality with The Penny Black Changed the World project, to make over 2,000 digital images available online.

The next phase of work with the BPMA will see a real focus on accessibility, taking what is already a technically accessible site and making it as good as possible. We believe there is no such thing as a finished website, just 'work in progress'. Using Plone has given the BPMA a good starting point from which to progress.

Sections

Personal tools