Postal heritage and Plone, or: how I learned to stop worrying and love Content Management Systems - by Steve Gardam
Article for Museums Computer Group
Author: Steve Gardam, Learning & Outreach Officer, The British Postal Museum & Archive
The lessons learned from the development of a Content Management System (CMS) for The British Postal Museum & Archive website.
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 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 were we also unable to obtain website visitor statistics during this time!
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, and will not have one for at least three years. Until then, the BPMA website must provide the public with whatever they need from us; whilst we need it to develop a relationship with our audience and build a lasting reputation for our fledgling organisation.
By June 2004 some things were clear:
- Our site carried a reasonable amount of information, but the branding would need to change, and the content was stagnating. Change was needed!
- We needed to get control over the content. 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, providing sensible 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 at the start of the 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.
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 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.
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.
Our working relationship with ATL has developed over the months of the project, and a small but important change has been 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 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.
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 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!
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 now plan to work with ATL on the site architecture, and the look and feel of the website design, based on user testing.
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 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. We have built a publishing workflow into the CMS, enabling authors to create content and publishers to review and publish. Thus far, we have not rolled out the CMS to a wide number of staff, but our site, like our organisation is relatively small.
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 that we hope to include in an upgrade later in 2005.
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.
In conclusion
The purpose of the article has been to give an overview of how we 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.
Our CMS experience at The British Postal Museum & Archive 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 control of our online presence from Royal Mail, we are now in a position to improve our online services, which means we can improve our relevance to Royal Mail Group, and develop and maintain strong links with their websites. In other words, what we have achieved is not so much independence as devolution, which brings benefits to both sides.