Choosing and using OMEKA

The search for tools to create and deliver our web based archive was undertaken by me with little involvement from the four contributors. Looking back over my documentation of this phase of development, I think the contributors were looking at this point for me to take the lead in defining the architecture in which their stories could unfold.  Through discussions with each of them around power and control I knew that for Dolly, Andrew and Stuart, it was important to find a system or way of working which would enable them to control their own narrative.  This meshed with my own desire to enable the contributors to tell their story on their own terms.  I knew we needed a system that could set permissions for different users  to give each contributor the freedom to work directly on creating their story without the need for intervention.  For Peter, we realised fairly early on that he could not invest vast amounts of time in building his narrative, so we knew we were looking at finding a different way of working in which his story would be more co-produced.

We wanted to produce an archive that would have immediate impact.  Therefore, the look and feel of the site - and the presentation of the resources on it was a priority.  The ideal solution would be to use a web publishing tool that also enabled collections management of the digital objects that each of the contributors might want to incorporate into their story.  Omeka lept out as the only tool that fitted these requirements. An interesting discussion on Omeka and its lack of competition can be found here:  Omeka describes itself as enabling its users to "create complex narratives and share rich collections, adhering to Dublin Core standards".  This focus on publishing and presentation of archival material combined with some collections management functionality was what I was looking for.

Having decided on Omeka the next question that emerged was to consider how the development of the site could be supported in practical and technical terms.  Here there was a wider question regarding whether I should look to embed the development of Omeka within UCL's infrastructure; the Wellcome Library's infrastructure; or whether I should see what we were developing as independent from these institutions and go it alone.  The constraints around the third option (keeping it independent) meant I ruled this possibility out - you need resources to be able to use Omeka.  Although Omeka is free and open source you need equipment (servers etc); technical expertise or money to be pay for hosting which we didn't have as an independent endeavour.  If I was looking for institutional support then it made sense to look for it from the Wellcome Library since the site (from my perspective) was being developed in reaction to their existing archives and manuscripts collections - it was already embedded as emerging in relation to the Wellcome Library's collections.  

This led to discussions with the Archives and Manuscripts team and the Wellcome Trust's IT team on potential mechanisms for supporting our use of Omeka to develop the mental health recovery archive.  The response from both teams was positive, enabling and embracing but there were constraints that influenced the way forward.

There are two development options for users interested in building archives using Omeka.  The first is to download and configure Omeka onto an in-house server.  The second option is to pay annual subscriptions to use as a host server.  My initial preference was the first option to download and use Omeka in-house because it enables control of the resources to remain with the creators.  However, this option was too problematic.  Firstly, the Wellcome's existing operating system and internal infrastructure does not match that specified for Omeka to be able to run.  Therefore creating an environment  within the Wellcome that could host Omeka would have significant start up costs.  Secondly, there was an issue of the technical support that would be required to develop the system in-house.  However, the major issue that was the main barrier to running Omeka in-house were issues relating to security.  The Wellcome's security protocols meant that it would not be possible to give the contributors remote access into the system - they would have to be on-site to use Omeka.  As three of the contributors live a considerable distance outside London it was immediately obvious that this would be unworkable.   We then looked at using as a hosting service and decided this was a more workable solution for our needs.  The costs of the annual subscription have been met by the Wellcome.

The advantages of using has been that we have not needed any technical support to get up and running with the development of the site; the infrastructure is taken care of by the host.  All the contributors need to develop their pages remotely is a computer and an internet connection.  So it has been a relatively easy process.  The disadvantages are the same as with any resource that is developed involving third party hosting.  I still feel uneasy about our resources being held remotely (because we do not have any say or influence over back up of the material or maintenance of the hosting platform).

In terms of our use of Omeka; I had initial teething problems with setting the contributors up as users on the system - it was initially confusing - but I am not sure how much of that was down to me and how much is usability issues with Omeka.  The contributors who are all used to using other web publishing systems such as Wordpress/Slideshare etc all feel that Omeka wasn't as instantly intuitive as other tools they are used to using.  This has at times caused frustration.  We use the standard templates within Omeka's exhibition plugin to build our narratives and sometimes we would have liked more choice over page layout.   However, to be able to build a site using archives that are woven into a personal narrative exactly meets the emerging requirements of the mental health recovery archive and it is through Omeka that we have been able to realise this.