Card-sorting activity at the Commodity Histories workshop

The AHRC-funded Commodity Histories project aims to produce a 'website that will function as a collaborative space for scholars engaged in commodities-related research'.  The project organised a workshop, 'Designing a collaborative research web space: aims, plans and challenges of the Commodity Histories project' in London on 6-7 September 2012.

As part of opening session on the 'aims, plans and challenges of the Commodity Histories project and website' I led a card-sorting exercise aimed at finding out how potential scholars in the community of commodity historians would expect to find and interact with content and other scholars in the network.  We prepared print-outs of sample content in advance and asked participants to sort them into groups and then label them.  At the end of the workshop I presented the different headings the groups had come up with and discussed the different ways they'd organised the material.

While some work had been done on the site structure previously, the process was useful for understanding some of the expectations people had about the functionality and sociability of the site as well as checking how they'd expect the site to be organised.  Various other presentations and discussion during the workshop reinforced the idea that the key task of the site is to enable contributors to add content easily and often, and tempered our expectations about how much scholarly networking would be visible as conversations on the site.

has written up some of the workshop at The Boundaries of Commodities.

Residency: a week of rapid prototyping at the Powerhouse Museum

I spent a week as 'geek-in-residence' with the Digital, Social and Emerging Technologies team at the Powerhouse Museum.  I've written up some of it at Geek for a week: residency at the Powerhouse Museum (though there's a lot more to say about the testing and the idea itself).

Two PDF versions of clickable prototypes tested in the museum:

Managing user-generated content in-gallery and online with WordPress

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.


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.

'Cosmic Collections' in the tech press

The 'Cosmic Collections' crowdsourced web mashup competition I ran was picked up by two very cool web developer sites, the Yahoo Developer Network and the Programmable Web.

Yahoo Developer Network: A new API and hack competition – this time not from a tech company but by a museum!

Programmable Web: Science Museum Opens API and Challenges Developers to Mashup the Cosmos

Two favourite quotes: a "crusade to bring museums out into the open as places of innovation rather than preservation" (Yahoo) and, "with the rollout of a new API to provide access to information about some of its exhibits, the museum itself has become an example of technological innovation" (Programmable Web).