Posted on by michaeljcripps

Omeka or WordPress. Omeka or…

I’m teaching an advanced humanities seminar called “Doing Humanities Digitally” this coming term. New course, new materials, and an open field in which to run. I’ve been working on some connections to pull in some TEI coding, some archival interactions, and even some collaborations with the natural sciences (think HASTAC). I have mostly settled on some work with the Digital Thoreau project, am toying with a foray into the Transcribe Bentham project, critical reviews of extant DH projects, a student-developed remediation of a prior humanities project (course paper), AND a digital exhibit project.

Omeka logo

I’ve been familiar with Omeka (developed by the CHNM at George Mason University) for a couple years now, and I’ve browsed through some of what the tool offers. I have always wondered whether it is really better/more powerful/more suitable/etc. than something like WordPress, a CMS/blog tool I use regularly and that is pretty easy to manipulate for a range of purposes.  This DH course, particularly the idea for a project that brings environmental science research together with some archival work, forced my hand and left me no choice but to get serious about evaluating Omeka for our purposes.

  1. First idea: Grab a free Omeka.net account and try out the tool. This couldn’t work because the free account doesn’t include the Geolocation plugin that enables users to locate items on a Google Map.  (There are some workarounds, I now know, but that’s a different story.)
  2. Second idea: Grab the open source Omeka CMS and install a test version within my domain. Complete control, full front and back end control. Not wanting to spend money on a sandbox arrangement, I went with this second idea.

A Preliminary Review/Evaluation

Installation was not as easy as I had hoped. This isn’t Omeka’s fault, really. It had more to do with some php settings that I didn’t know how to tweak/adjust. But I would estimate it took about 12 hours over several days to actually get the CMS to behave in a way that enabled me to test the tool. WordPress, in contrast, is included in many webhost packages, making it a truly one-click installation.  (The WordPress Network install is another matter.)

FWIW, here are the settings I needed to tweak on a Lunarpages-hosted installation:

  • php.ini – needed to comment out some “disable_functions” code in the file located in my public_html folder to get ImageMagick and Omeka communicating.
  • Path to ImageMagick isn’t so easy to locate on Lunarpages, but it’s here: /usr/local/bin/
  • I’m still sorting through a fileinfo module “warning” that Omeka spits out at the first install screen, but the CMS itself seems to work even with that problem/warning.
The theme options are still pretty limited (Omeka is in 2.0.x right now), but that’s a CSS issue that shouldn’t stop one from using the tool. Any self-respecting library or museum using Omeka for real exhibit purposes would almost certainly get some custom styling on the site.  I haven’t looked at the CSS yet, but I imagine it’s pretty easy to adjust.  It’s probably comparable to WordPress in that regard.
Dublin Core baked into Omeka makes it scream “legit” DH tool. This feature alone puts it ahead of WordPress when considering a course whose goals include some engagement with DH standards for describing archival materials. In fact, the entire process of adding materials to Omeka foregrounds good description practice. It isn’t sexy, but the GUI effectively tells users to get their Dublin Core metadata in first.  This isn’t required, but the order of presentation signals its importance.
I’m still very much toying with Omeka, but I think the ability to present multiple exhibits lends itself to a range of points of emphasis. WordPress could easily accomplish this using subpages in a nav structure, of course.  But the exhibits model in Omeka also offers users ready-made templates for presenting pages within an exhibit.  One could build a photo gallery, a mix of images and text, a text-only page.
Geolocation is available in Omeka. This is less exciting than it seems at first, really, since Omeka doesn’t import the geolocation metadata from images on upload, and it can’t handle KML/KMZ imports of GIS data to display in a map.  But it is still pretty nice. I even managed to embed a custom Google Map into an exhibit page, effectively enabling one to pull GIS data loaded into a Google Map into an Omeka exhibit. Of course, it’s all running on embedded Google Maps, and WordPress handles that just fine.
I’m going to run with Omeka for the project, not because it’s better than WordPress (it isn’t – yet). I’m going to use Omeka so my students have the EXPERIENCE of using a hot new DH tool that is legitimate and still under active growth and development. I’m also going to use it so that I can help my colleagues consider including digital archival and exhibit projects in their own humanities courses. WordPress would be much, much easier for me.  But why do the easy thing?

Acknowledgements

I have to thank my colleague Pam Morgan for a series of conversations that yielded the idea that would draw together some of the data she (along with her colleagues and students) has collected on the Saco River estuary, research on the uses of the Saco River, and historical photographs and documents at the McArthur Library in Biddeford, Maine. I must also thank Renee DesRoberts, the archivist at the library, for her willingness to really open up their collection of glass plate negatives for our project. I’m really looking forward to this project!

I also want to thank the tech support at Lunarpages and patrickmj from the Omeka Dev Team for offering me some help on the features and limits of the Geolocation plugin.