The subject of centrally managing visitor comments from museum interactives and online spaces keeps coming up on various discussion lists, so I thought I'd start a post about some work I've done on this that I can refer people to. It's very draft-ish at this stage, in part because I haven't had time to go back to the original requirements and architecture documents and verify my vague memories. I have no idea if posts like this would be useful for other people or what I could include to make it more useful – I'd love to know what you think.
Background
When I started at the Science Museum, I discovered there were lots of different systems running the various in-gallery interactives, which meant lots of different usernames and passwords, server addresses and interfaces to master to do things like approve new visitor comments or update content. The redevelopment of the Wellcome Wing galleries (Antenna and Who Am I?, and the new gallery Atmosphere) was an opportunity to create a centralised backend system that would make it easier to add new content and manage the sometimes huge levels of user-generated content that comes from the galleries.
Sample requirements: Antenna
The updated 'Antenna' contemporary science news gallery also had a vision of integrating the in-gallery and online experiences, not only with content flowing seamlessly into different interfaces, but also by bringing responses from visitors in the galleries and online into shared spaces. The system had to be able to manage polls, quizzes, 'likes', etc as well as helping manage and publish visitor comments. The galleries are visited by thousands of school children a day, and they can generate an immense number of comments, many of which are unsuitable for publication (i.e. kids will be kids, and they will think it's funny to swear or be rude about a classmate, and of course there's a lot of repetition along the lines of 'I like exhibit x').
Selecting a platform
After some thought, I settled on WordPress as the backend platform to publish our content and store user-generated content and related activity. It's based on PHP so it's extensible and it's not too difficult to find developers; it's widely used so there are lots of decent plugins and themes*; it's capable of supporting high traffic sites; and it has an API, which meant it would also work with the gallery's Flash interactives, web and mobile interfaces – anything that can use a web service to push and pull content. The user experience for the content developers and visitor comment moderators was also important to me, and WordPress was pretty good on that front.
As I posted to the Museums Computer Group list once, 'As the gallery is about the latest in science news, it had to be easily updateable, and using a customised WordPress system means the same museum content and visitor comments can be shared on the Antenna website and in the gallery. The system manages content and interaction for the daily (ish) science news stories, the short-term displays, and the in-depth 'Feature' exhibitions. I'm happy to answer questions on the technical architecture and development process (or direct you to the Science Museum/NMSI web team), but questions about the in-gallery kiosk hardware etc are best directed to the New Media team.
Some of the 'have your say' applications in the Atmosphere and Who Am I? galleries also run on the same system, which means visitor comments can be moderated via the same central WordPress installation. I don't know how often the questions or polls change, but it should help the galleries keep their interpretation up-to-date over the life of the installations.'
* the art of selecting a plugin is a whole different post, and generally I'd say it's useful to use them for rapid prototyping and early user testing but unless you're really happy with the way a plugin is written you might want to write any bespoke plugins yourself – this doesn't have to be difficult process.
Lessons learnt?
One important lesson I learnt rolling out and maintaining this project (before I left to start my PhD) was that a project like this often entails navigating between two views of the museum technology world.
A system like WordPress works in a very webby world, where large and small updates to the underlying codebase are released throughout the year. Plugins are updated, the underlying code libraries and operating systems might also release updates and fixes – all of which requires systems for testing the impact of these changes on your code and pushing out updates to live servers as necessary.
Exhibition and in-gallery interactives often follow a more traditional publishing model – once it's live, you might spend a week on bug fixing but then you're off onto the next thing. Software code isn't written or documented for the same levels of maintainability, and maintenance time isn't built into resourcing budgets.
A project that builds in links between webby and publishing-style projects needs a clear plan for either entirely freezing code (and managing any subsequent security issues accordingly) or introducing regression testing and roll-outs for all code production.
