Behind the Powerhouse collection WordPress plugin

Yesterday we went live with the first version of the Powerhouse Museum collection WordPress plugin. Rather than clutter that launch blogpost up with the backstory and some its implications, here’s the why and how, and, what next.

The germination of the WordPress plugin was the aftermath of the Amped Hack Day run by Web Directions at the Powerhouse where we launched the Museum’s collection API.

Whilst the API launch had been a success, Luke (Web Manager/Developer) and Carlos (Developer) and I were a little disappointed that although we’d launched a REST API, we had actually made it more difficult for the ‘average interested person’ to do simple programmatic things with our collection data.

Of course, we’d built primarily the API to make our own lives easier in developing in-museum applications, and the next wave of online and mobile collection projects you will be hearing about over the coming 12 months. But we’d also aimed to have the API broaden the external use of our collection data and solve some of the ‘problems’ with our existing ‘download the database‘ approach.

In fact, ‘download the database’ had worked well for us. Apart from the data being used in several projects – notably Digital NZ and one of the highly commended entries in 2009’s Mashup Australia contest – we’d found that the database as a whole item was being used to teach data visualisation and computer science in various universities both in Australia and overseas. We’d also found that people in the digital humanities were interested in seeing the ‘whole view’ that that data dump provided.

None of these groups were well catered for by the API and one of our team, Ingrid Mason, ended up convincing us to retain the ‘download the database’ option alongside the API, rather than forcing everyone through the API. Her argument revolved around the greater, and hitherto underestimated value of being able to ‘see the whole thing’.

At the same time, WordPress had become a defacto quick and dirty CMS for most of the Museum’s web projects. We’ve run annual festival websites (Sydney Design), whole venue websites (Sydney Observatory), exhibition microsites (The 80s are back), and experimental pilots (Suburb Labs) on WordPress over the past few years building up both internal skills and also external relationships to the point where the graphic designers we work with supply designs conscious of the limitations of WordPress. In each of these sites we’ve had a need to integrate collection objects and this has usually meant ugly PHP code in text widgets.

(Don’t be concerned – for larger and complex projects we have been migrating to Django)

[phm-grid cols=4 rows=1 v_space=1 h_space=1 thumb_width=120 thumb_height=120 random=true parameters=”title:computer”]

So in the weeks after Amped, Carlos spent time developing up a WordPress plugin based entirely on the API. This, it was seen, would serve two purposes – firstly, allow us to embed the collection quickly into our own WordPress websites; and secondly, to give interested non-programmers a simple way to start using our API in their own sites.

Late last year we sent the alpha version out to some museum web people we knew around the world for feedback and the Carlos tweaked the plugin in between working on other projects, before its first public outing in the WordPress plugin repository.

So where now?

The WordPress plugin is definitely a work-in-progress.

We’re keeping a keen eye out for people implementing it on their blogs and WordPress sites. (If you’ve implemented it in something you’ve done then tell us!)

Carlos has several features and fixes already on his radar that have come out of our own uses of the plugin – some of these are tied to limitations in the data currently available through the API.

If you’ve got feature requests then we’d love to hear them – and we’re secretly hoping that those of you who are deeply into Drupal or Expression Engine might port the plugin to those platforms too.

Send your feedback to api [at] phm.gov.au

(Luke is also presenting a paper on the API exprience at Museums and the Web in Philadelphia this year)