Taking stock

Ok, so we “did it”. Or at least, we did some of it…

Here’s what we did do in our allotted 12 hours (roughly in order…):

• bought a domain
• set up a google docs object spreadsheet
• designed a logo
• downloaded and installed WordPress MU, Drupal, Omeka
• drafted an Information Architecture
• installed WP plugins
• made a decision about platform(s)
• created blank pages based on the IA
• imported object data from Google Docs to Omeka
• wireframed and designed key templates
• built css and then WP templates
• wrote content
• wrote a simple WP/Omeka plugin
• designed a dummy floorplan
• tweaked (a lot..)
• went live with http://dev.thefuturemuseum.com/ after almost exactly 12 hours…

Technically (just to give you a reminder) we used a combination of WordPress MU for the bulk of the site and the really rather nice Omeka to hold the object data. Dan built a WordPress plugin which pulled the object data from Omeka’s alternative response formats and inserted it into our WP pages.

Prior to making the decision about which platform to use, we held our object data on Google Docs and used a simple web form to add stuff. Once we decided to use Omeka we used the CSV import plugin to get our data out of Google Docs.

Initially we were thinking we’d use Omeka on the front end too, and just re-skin it to look like the rest of our site (ie users would “silently jump” over to Omeka to look at collection items and then back again for “other” museum information. We realised pretty soon though that it’d be much better to not have essentially two sites to maintain and design so instead went for the WP front-end / embedded Omeka objects approach.

So what did we learn, and why…?

We set out with two main aims. Firstly, we wanted to show that it is possible to build (museum) websites quickly, using cheap or freely available tools and techniques. On the whole, we both feel we achieved this, managing to produce a site from scratch and get it live. This is not to say we’re 100% happy with the site we produced: both Dan and I wanted at least another couple of hours to tweak and fiddle; had we been building a museum website in a week, this would still have been the case (there is NEVER enough time, right?!) but still, 12 hours was a very, very tight timescale to set ourselves.

Clearly, many of issues raised via Twitter or on this blog remain for most “real” museums and we had a huge luxury in not having to deal with painfully slow signoff, huge stakeholder meetings, conflicting pressures and political tensions.

I guess the point we’d make in response to this is one that we have both made many times in the past: although no museum is every likely to (want to!) build a website in a day, there is a tendency for the timescales created by the political nature of museum decision-making to actively damage projects. The raw enthusiasm and energy that is created by doing things rapidly, cheaply and – frankly – without the polish of perfection – is hugely important to any project. A year-plus long timeline (some museum online projects I’ve worked on have been 3+ years in length!) will by default kill any passion and enthusiasm, and probably most of the members of the project team, too. Finding a middle ground where decisions can be made quickly and technologies like WordPress or Omeka are installed and configured easily; finding a framework where museums can play and experiment – this is clearly where success lies.

A couple of other people mentioned that the costs (currently, erm, £6.39!) are unrealistic and should include our time as well. This is probably right, depending on how you cut it, but (sadly – wish my day-rate was higher…!) this would still amount to not much more than – say – £1000 for total build.

The second thing we wanted to do was to provide some kind of genuine clarity into the process that we followed in the hope that it might help others. We hope we’ve done that to date, and intend to continue to do this into the future with various presentations, starting with a workshop at DISH 2009.

On a more practical level, we aim to take the plugin that we built, re-write it from the ground up and make it available for others to use in their WordPress installations. The Omeka approach is great – we can’t stress enough how impressed we were with the site, the documentation, the system itself – but we see that for many (perhaps larger?) institutions, a WordPress front-end coupled with an Omeka collections management backend is likely to be more flexible than a “one size fits all” approach of using Omeka to do everything. We both have some ideas which we’ll articulate later about how Omeka might be improved to help this and hope to be in touch with the Omeka team shortly.

Meanwhile, we’re going to snapshot the site we built as a showcase (possibly at a new subdomain – 12hrs.thefutureuseum.com or somesuch) and begin planning how we can take our main thefuturemuseum.com site forwards over the coming year. If you have ideas, please do get in touch!