Two months ago I began a 4-week online course (of the same title as this post) as part of my professional development (PD) plan. One of my main PD goals is to build upon my knowledge of and experience with digital humanities (DH) tools, and I specifically identified Omeka as one DH tool and open-source, archival CMS that I wanted to gain experience working with. I have fairly extensive experience working with WordPress but not much experience with other standalone platforms.

I could have just learned how to use Omeka on my own, but I always prefer to learn new tools by “doing,” and by doing so in a structured environment that has been created with that tool in mind. I had no idea where I’d even want to begin on my own with Omeka, so the online course was a perfect opportunity for me to learn the basics of Omeka while having professional guidance but also the freedom to choose my focus and pace. I’ll begin my review with perceived strengths and weaknesses of Omeka, followed by overall comments and final thoughts.

A few final notes before my thoughts:

  1. I worked in a hosted Omeka Classic installation (version 2.6.1), using the Exhibit Builder plugin.
  2. My exhibit focused on postcard production in the United States from 1920 to 1950. View my exhibit here:
  3. Since the course focused only on creating exhibits in Omeka, that’s where I am coming from with my comments. I still have “blind spots” when it comes to using Omeka as something other than an exhibit-building platform (though I conceptually understand how its other features can work together).


Omeka’s greatest strength, to me, is that it allows items to drive the platform and content. Items are the backbone of Omeka, making it an ideal space for creating object-heavy exhibits while also maintaining and linking to full item records, related resources, and collections. (WordPress, on the other hand, definitely lacks this ability to give detailed media information.) This feature can really help avoid the pitfalls that I regularly see students and faculty encounter as they add media and items to digital history projects in WordPress—oftentimes, there isn’t much meaningful information about the item or image other than its name. No creator, no date, and no citation or credit to the owner or source. This criticism is not of my faculty or students—rather, it’s a criticism of WordPress, which, after all, wasn’t originally meant to be an exhibit-building platform. It was meant for blogging, so it has no out-of-the-box focus on item information and metadata the way that Omeka does.

For small historical societies, museums, and other cultural institutions, Omeka’s information and item architecture is even more beneficial—users viewing an exhibit can look at the record for a particular item, then discover related resources or the larger collection that the item is a part of, and then explore items within those resources. This interconnectedness of item and collection networks in Omeka gives much greater visibility to items and collections that might otherwise remain “hidden” if they weren’t published in Omeka. With greater visibility and accessibility comes a greater potential of garnering interest, researchers, and support, all of which small cultural institutions depend heavily upon for their continued existence.


The greatest weakness of Omeka, to me, is the lack of a good preview, or even a general idea, of how the different content blocks in an exhibit page would look when they were published. The content blocks were individually self-explanatory, but how they actually appeared on the published exhibit page—particualrly how each block fit in with the next—was a frustrating mystery. I’m very particular when it comes to appearance and aesthetics, so I found myself making incessant changes to exhibit pages (upwards of 75 revisions for some pages) to get them to look as I had envisioned. (I even crashed my server one night with all of the changes I made—oops.) While it may seem silly to focus on an aspect of an exhibit as “superficial” as aesthetics, I firmly believe that aesthetics play a large role in determining how well an exhibit (or any other piece of visual information) can communicate its message. Choppy, abrupt, and otherwise unappealing aesthetics can disrupt the flow of information and thus, the flow of an exhibit, so not knowing how published content in Omeka would appear was a big barrier for me.

Another weakness, and one ironically related to Omeka’s greatest strength, is the inability to bring in outside images to supplement an exhibit.1 I worked around this issue by adding the images as “Items” to my installation and clearly communicating that the images/items were not owned by me, and I also included copyright information and limitations. I still felt a bit leery adding images to my site that I didn’t own because Omeka seems to operate under the general assumption that you own whatever items you add to your site. From a collections management perspective, this assumption makes perfect sense. For exhibit-building, a process during which it is very typical to bring in objects from other institutions, it is not ideal.


Overall, I found Omeka to be not quite as intuitive, flexible, or customizable as WordPress. However, it was certainly more intuitive than working with a traditional, closed CMS, and it provided the native publishing option and visibility that traditional CMSes do not. Its dual functionality (CMS and publisher) makes Omeka ideal for small historical societies, museums, archives, etc. looking to make their collections visible without having a huge expense.

For a standalone project relying heavily on items, which is what I’ve used Omeka for, it is still a great option, though I do struggle with my site feeling “empty” because it’s built around a single exhibit rather than a broader collection of items. (The home page of my Omeka installation is the best example of this emptiness: a short introductory paragraph to the site, a few items, and one featured exhibit.) The focus of Omeka being on one exhibit leaves the rest of a site feeling very incomplete, and I would love to see an option in the future to use the core functionalities of Omeka for a singular exhibit without all of the surrounding framework that won’t necessarily be filled out.

I went through all of the frustrations and all of the joys associated with learning a new digital tool: I told my boss that I “officially hated” Omeka as I struggled with the aesthetics of my exhibit, but I loved building my exhibit and seeing how it turned out. As I felt more confident working in Omeka, I added some simple custom CSS to “fix” a few things that I didn’t like. By the end of the process, I felt confident that I understood the strengths and weaknesses of Omeka as a publishing tool and could advise someone else who might be muddling through building an exhibit in Omeka on their own, too.


  1. I should note that I did not have my Omeka installation set to allow <img> tags through HTML filtering, so that is an option I’ll have to experiment with later. However, allowing <img> tags makes the process of bringing in outside images only slightly easier—it would still require (as I understand it) adding the images in through pure HTML.