I’ve been a big supporter of Omeka.I love the archive and information science oriented hierarchy. I love the considerations taken for small archival institutions. Really, I mean all of this sincerely. There’s a lot of great hooks for creating your own plugins and extending to your own themes.
But with experience and seasoning comes a certain kind of ability to properly weight the pros and cons of using a certain package.
First a little on my experience with Omeka. One of ASHP’s long standing visions was to create a comprehensive online database of all of the worksheets, teaching activities, and annotated primary document resources that they used in their professional development for American History teachers. The outcome of this work was “HERB: Social History for Every Classroom” which launched in 2011. Herb has been wildly successful, and it is built on the Omeka platform with a front end theme designed from scratch, several customized plugins, and a couple that were built from scratch just for this project (such as one seen here which allows the creation of reusable question sets).
I learned a lot about Omeka in my time (over a year) developing Herb. Though I have a lot of support at ASHP, I’m a one team programming crew. I write the CSS, create the plugins with PHP, administer the server etc. So when I evaluate a package I tend to do so with an eye for maintenance and ease of development.
On the shortcomings I’ve found using Omeka
As this is the most common question I field here in the New Media Lab I thought it would be worthwhile to layout a few of the issues I (and other New Media Lab students) have run into working with Omeka. This is not intended to be overwhelmingly negative, because as I mentioned, there’s a lot of great things about it. Effusive praise is easy to find, but I don’t see a lot of honest assessment of the software. So here is what I think after 2+ years of very intimate and up-close work with this package.
For new developers, Omeka is rather intimidating. The documentation is rather sparse at times (though getting better from where it was 2 years ago) . Though a community exists where questions can be asked and answered, I find it a far cry from the active and engaged community around projects like WordPress. Fair questions from novices often go unanswered. Plugin documentation can be even more difficult to navigate and incorporating them into your site often requires more than a intermediate level of coding knowledge.
The Key Takeaway: Experienced developers and development teams should have no problem working with Omeka. Developers who are not familiar with troubleshooting code on their own may find Omeka challenging to customize.
Omeka has several themes available from their site. Some of these look quite nice, but for groups with a strong visual identity (for whom “looks like a WordPress site,” “looks like a Mediawiki,” or “looks like an Omeka site” are not acceptable theme characteristics) they may find the options somewhat lacking. The “From Scratch” theme is a powerful starting point, but again requires expert knowledge of CSS and at least intermediate understanding of PHP to seriously customize.
As I mentioned a few paragraphs before, I often am doing both backend and frontend development simultaneously. In an effort to streamline my process, I often use an existing theme as a starting point. With WordPress’s themes, I can often find a “75% there*” starting point and focus on creating the plugins that will make the site unique and functional. With Omeka, either you like the default themes appearance or you don’t. As more institutions use Omeka, the need to stand out will become increasingly important and apply pressure to the narrow default theme selection
The Key Takeaway: Out of the Box, Omeka looks like Omeka. Because customizing Omeka’s appearance is done only via the code, experience developing and comfort with code can be obstacles to creating a new look for Omeka
There are lots and lots of fields. I’ve previously said that it was one of Omeka’s strongest assets that it uses a standard such as Dublin Core. But in reality, for students in the lab and non-traditional archives it can pose a bit of an obstacle. For many, just beginning to think as an archivist about their collection is a huge hurdle. But quickly the semantics can become confusing: who is the publisher? should she instead be a contributor? do I put the same content in the rights field? It also seems that the idea between what is a collection (why can an item only belong in one collection) and what should be an exhibit is another logical hurdle that makes Omeka more like a traditional archive, but has come up time and time again as a source of confusion for Omeka users.
The Key Takeaway: if you don’t have at least a passing knowledge of Dublin Core and archival practices, some of Omeka’s powerful archival features may instead be hindrances.
And finally, there’s updating. In most cases, WordPress updates are nothing more than a simple click. Other Content Management Systems vary from “a single click” to “complete manual update.” Omeka is one of those. Though it does not have the exigency of WordPress updates (Omeka is unlikely to be targeted by hackers since it is a niche package) the updates that it does have are rather difficult to install. I’m sure they’re working on one-click updates, but until then it is rather challenging for novices.
The Key Takeaway: Updates can be a fair amount of work to install, but there aren’t any security issues so for the time being updates can be considered optional.
On the Takeaways
For all the things that Omeka does well, its important to know where it may be more challenging than the alternatives. I find that development of an Omeka site takes probably 30-50% longer** than the equivalent site would take on WordPress. I have also found that for novices or people new to programming, altering Omeka’s functionality or layout is several times more difficult than making those same changes on WordPress.
So is WordPress the answer to all of life’s problems? Hardly. But one a current project with a rapid deadline that I had originally slated for Omeka, I’ve changed platform early in the process to WordPress in order to expedite development.
I definitely think Omeka warrants a close look. With each new version, the product improves; therefore, I think Omeka should continue to remain on our collective radar. But as it is still early in its product lifecycle, we should temper our expectations and approach Omeka with an open-mind but realistic expectations.
TL;DR: Omeka is a great product for people interested in curating digital collections, but customization requires at least an intermediate knowledge of PHP, CSS and HTML, as well as a comfort for forging ahead boldly where no one has gone before.
And of course, If you’re interested in talking in person about Omeka development, please feel free to reach out to me or come to an upcoming New Media Lab meeting. Several students are working with Omeka and as always, we’re excited to share our experiences.
*75% there – The idea behind this philosophy is that in developing a custom theme for a client, if you can find a theme that incorporates most of what they’re looking for, you can spend 100% of your time concentrating on the 25% of the functionality that will set their site apart.
**30-50% This is just based on my experience, your mileage may vary. I don’t have any hard statistics to back this up. Just my development cycles over the last 5+ WordPress projects and 4 Omeka projects.
*** Happy New Year to all!