13 September 2026
For this week’s blog post I elected to review Lauren G. Kilroy-Ewbank’s article, “Doing Digital Art History in a Pre-Columbian Art Survey Class: Creating an Omeka Exhibition Around the Mixtec Codex Zouche-Nuttall” (2018)1. I was unfamiliar with Omeka as a digital collections platform prior to reading this article, so I found that Kilroy-Ewbank did an excellent job explaining the tool through her collegiate user-case scenario. (For more on Omeka, see here–>).
As of the publication of this article, Lauren G. Kilroy-Ewbank was a professor of art history at Pepperdine University. She specialized in the visual culture of Latin America from 1400-1800, the decolonization of art history, and digital art history (DAH) pedagogy. Kilroy-Ewbank left academia in 2020 and currently serves as one of the co-founders of ARTSQ, an online platform dedicated to making art and history more accessible to K-12 students.
The Omeka project detailed throughout this article focuses on reading the visual language of the Codex Zouche-Nutall (CZN). Students in Kilroy-Ewbank’s art history course were tasked with building Omeka sites to serve as a visual argument for their analysis of the CZN imagery, taking the place of a traditional formal research paper. Students developed their arguments from materials learned in class before turning to Omeka, using the digital collection platform as a way of communicating their research to a non-academic audience.
Metadata: Data About Data
Kilroy-Ewbank stressed the importance of proper metadata throughout her article, emphasizing that it was the backbone her students’ success with Omeka. This can be difficult to convey to art history students who may be unfamiliar working with data and metadata (data about data), as Omeka uses user-assigned metadata and tags to build the digital collection. Without thorough metadata, Omeka can’t build a system.
Omeka runs on DublinCore, so users are required to have some familiarity with the cataloging system before diving into the platform. Luckily, DublinCore is fairly straightforward compared to other systems like MARC21, and is very adaptable to visual images. Kilroy-Ewbank devoted an entire class period to walking her students through Omeka and DublinCore, providing them a foundation to build upon rather than simply throwing her students into the deep end. While I have never used Omeka myself, it seems that their online documentation is fairly robust, furthering supporting the students.
Concerns Regarding DAH Tools
One concern that has arisen from Kilroy-Ewbank’s article is the long-term stability and accessibility of the CZN Omeka projects after the course ends. Unlike traditional publications, digital tools are not static and they are at risk of decaying over time if they are not properly maintained. Software updates push older versions of platforms out-of-date, rendering them practically unusable over time. Some digital platforms are tied to student university accounts, which many students lose access to after graduation. In the event that projects in the aforementioned situation require updates, there is no way for a user to provide them.
I am unsure of the exact backend process that goes into creating an Omeka project, but I assume it is heavily reliant on developer programming to run. DAH tools like Omeka often provide the programming needed to start an online platform so users do not have to generate it themselves. While this lowers the barrier of entry for many users who otherwise are not familiar with programming, it creates a reliance on faceless creators to keep the tools operating. If the developer decides to kill the program or stop providing updates, the projects associate with it will cease to exist.
Conclusions
What struck me the most in this article was Kilroy-Ewbank’s emphasis on DAH projects not being perfect, as I have worked in DAH in the past and always been concerned about issues with my projects. DAH tools are new and still developing technologically, so they are prone to errors and bugs. Moreover, I find that may digital tools have confusing documentation (if any at all), making it more difficult to solve issues as they arise. For example, ESRI—the parent company of ArcGIS Pro and ArcGIS Online—has relatively poor documentation in my opinion. Their page is difficult to search and links are buried in individual webpages, making it incredibly frustrating to comb through.
Kilroy-Ewbank acknowledges in her article that her students will likely struggle with Omeka, and seems completely okay with that struggle. What seems to matter most to Kilroy-Ewbank is that the students attempt the platform and try to think about supporting an argument visually, rather than through a research paper. For professors like Kilroy-Ewbank, tools like Omeka are meant to act as an alternative to the traditional research paper. DAH tools are oftentimes more accessible to non-academics, as they aren’t hidden behind journal paywalls and use more accessible language.
Even if the Omeka projects are unsuccessful, Kilroy-Ewbank seems prepared to congratulate her students on a job well done. Sometimes it is the process of learning that is more important than the final product.
Turning away from Omeka, our class had the opportunity to interact with another online digital collections platform this week: CollectionBuilder. Similar to Omeka, CollectionBuilder is an online tool that allows users to curate their own collection of visual and auditory media (images, videos, .mp3 files, etc.). It was designed specifically for digital humanities projects by a team at the University of Idaho.
CollectionBuilder’s barrier to entry is fairly low for users unfamiliar with programming. Sites are maintained through a Github repository, which users copy directly from CollectionBuilder itself. The developers provide users with pre-populated Google Sheets to fill with their data, highlighting necessary fields (i.e. ‘Title’, ‘Object_ID’). The cataloging system is based on DublinCore, with a few modifications. Users have the option to populate the pre-formatted Google Sheet and create a basic webpage, or dig into the code in the Github repository for further modifications and customization.
I was actually very familiar with CollectionBuilder coming into this week’s classes, as I used it in a final project in another class this past spring. Since I have experience with programming languages, I elected to modify the code and templates provided by CollectionBuilder to better suit the needs of my project. I am by no means a software engineer or a computer scientist, but even I found that CollectionBuilder’s documentation was fantastic for walking users through modifications and adjustments to their sites. The documentation is also very good for simply setting up a basic site—no modifications needed.
(The project I used CollectionBuilder for was the Roman Wall Painting Index (RWPI), an online database of Roman wall paintings organized by subject and theme. Traditionally, Roman wall painting has been organized by geographic find spot, making it difficult to compare paintings across different locations. The RWPI was designed to provide a visual alternative to traditional means of organization for researchers. It is still being updated as of writing and currently represents a small number of total wall painting. You can access the site here–> or under the Research & Projects tab.)
- Lauren G. Kilroy-Ewbank, “Doing Digital Art History in a Pre-Columbian Art Survey Class: Creating an Omeka Exhibition Around the Mixtec Codex Zouche-Nuttall,” Journal of Interactive Technology and Pedagogy, no. 12 (February 2018) ↩︎
Leave a Reply