Building a Website for Medieval Artefacts — What did I Learn?

This year we decided as a class to undergo the exciting task of putting on our very own manuscript exhibition in the display cases of the History Department. During out discussions, I was struck by the fact that our hard work would only be on display for a short time. If we could make this exhibition permanent, we could show off our work for years to come. But the university space is limited and could not accommodate such an exhibition. However, building a website to house this exhibition promised longevity. Therefore, myself and the other members of the website team came together and began work on Medieval Ottawa, a companion to the exhibition.

Our first task was to chose a platform. After experimenting with Omeka, WordPress, and Wix.com we decided that WordPress, with the various plugins it offers through our student hosting package, would give us the desired layout and usability. Our main concern was whether the platform we chose could host the high quality images necessary for our audience, who would need to see the fine details of the objects.  Omeka had this ability, but ultimately lacked the functionality we wanted for future students and researchers. Wix.com lacked open-source options, and was therefore less student-friendly. WordPress was the Goldilocks of the bunch, perfect for students with its open-source usability and it is capable of hosting high resolution images.

Once this was decided our team member Callum began researching how to incorporate IIIF framework or Mirador viewer into WordPress. As we have written in a previous blog post, this proved difficult to accomplish without direct access to the university’s server and this task was ultimately abandoned. Nevertheless we were still able to host our high resolution images and implement a zoom function despite the drawback.

Matt was tasked with filming interviews for the website and these were uploaded to the Medieval Book Youtube account to be embedded into the WordPress website. You can watch the videos here. We also made use of the University’s Media Commons recording rooms to record Shamus McCoy reading the Latin transcriptions of the objects in our exhibition. We felt this would be beneficial for the seeing impaired and would offer an auditory way to engage with these medieval works, which we so often understand as solely visual objects. You can hear these recording under the “transcription” tab for nearly all of the folia in our exhibition.

We wanted to ensure that the research on our manuscripts were preserved long after the exhibition was taken down, so we set up a Metadata tab on each of the folia pages on the website. This is an organised collection of the information each student in the course gathered for their respective folia in the Fall term. This process was the longest: the information was first gathered, reviewed, reviewed again, organised, standardised, and finally reviewed again before it was imputed into the website. This was to ensure that researchers and students could easily access the data for these objects. Having correct (to the best of our knowledge) information on display was extremely important to our team, and we encourage researchers to comment and correct the data if possible.

The time and effort that went into creating this website was immense. The website team at times found ourselves working for 8+ hours in the History Department’s Digital Humanities room. I cannot thank my team enough for their hard work and patience in seeing our vision to the end. Throughout this process I learned many valuable lessons, I will name a few here. I learned how to lead a team by setting attainable tasks, providing assistance and encouragement, and ultimately doing whatever I could to ensure we all reached our end goal. I also learned the art of delegation. So often in my undergrad I found myself carrying the load of a group project because I was afraid to let go of tasks I deemed to important to not handle myself. This year I learnt to trust in the strengths of my teammates by allowing them to take on the tasks that I would normally attempt to do myself. This was an invaluable lesson that I will surely carry with me. When we set out to build a website, I did not realised that on top of gaining experience in website building and digital humanities I would also learn some of the most important skills for a student to take away from university: how to not only work but thrive within a team.

 

Manuscripts on Display: Student Engagement with the Physical Book

When our class discussed creating an exhibition for Carleton’s “lost” manuscript fragments, we were confronted by the question of audience. Who would be interested in visiting our display? What knowledge do they bring with them and what knowledge do we want them to take away?
As university students who are enthusiastic about the medieval past, our aim was to delight but we hoped to entice visitors to learn more. Thus, the exhibition team set about choosing the most beautifully decorated, shimmering and detailed fragments, those with illuminations that would excite— from exceptionally brilliant flora and fauna to the most haunting portraits of executions and angels.

Early in this process, I had the opportunity to put our fragments and manuscript books on display for the students of a second year course on Medieval Europe. This was to be a one-time exhibit and students were tasked with providing post-workshop feedback. This was a unique opportunity to understand what students take away from engaging with physical codices and fragments.

Of course, as the coordinator I had preconceptions about student’s expectations and knowledge of the Middle Ages. In fact, we had spent multiple sessions together discussing medievalisms: popular beliefs about the middle ages, with the likes of Robin Hood, King Arthur, and the notorious Black Death appearing as distinctive features of the period. Moreover, most of the student’s assignments required the examination and analysis of source documents. These were often transcriptions and translations (often translations of translations) into modern English. With many steps removing the student from the physical document, it is beneficial for them to engage with these documents as physical items— What better way to understand the physicality of these documents then through not only seeing them through glass but engaging with them!

In consultation with Marc Saurette (Department of History; Medieval and Early Modern Studies) and Llyod Keane (Archives and Rare Book Coordinator) I began pulling sources from the shelves, keeping in mind to demonstrate both the beauty and the dynamic culture of the medieval past. Beginning with medievalisms, we pulled from the shelves of Carleton’s Archives and Research Collections (ARC) an early modern version of Caxton’s edition of Mallory’s Le Morte d’Arthur which features the original Middle English spelling. I included Gerard’s Herball (a herbology handbook originally published 1597) so that students could amuse themselves reading this vernacular text. This was a particular hit among the class, not only because they could read and sound out the early English, but because this allowed them to find both extinct and fantastical plants. One astute student mentioned they were intrigued to find post-columbian exchange items (such as potatoes) in the book.

Throughout the course we discussed the rise of notaries and universities during the Middle Ages. To provide a sense of what these documents may have looked like, I included both charters held in ARC (letters on the topic of the King’s rents) and a student copy of the Commentary on Pope Gregory IX’s Decretals. One charter is a chirograph, a document written in duplicate on a single parchment with the words “chirographum” in the center and then cut through to later establish the authenticity, the other a common deed accompanied by a broken red wax seal. A student who plans to study law spent a good portion of time with the chirograph; another student found the notes on Decretals compellingly relatable to our modern methods of learning through notetaking.

However, it seemed the majority of students were less concerned with the content of the documents themselves and far more interested by their physical aspects. The amount of time and labour taken to create a manuscript book, the use of animal skins for parchment, and even the process by which monks would learn to become scribes fascinated them above all. To be able to touch the rough and wrinkled vellum, see the gold leaf illuminations in person, and to smell the scent of an old tome whirling up as you turn the massive pages were recurring mentions among the student’s responses. They connected these physical objects to the historical work they had been doing throughout the year, writing that this experience was invaluable to them for the opportunity to have a glimpse into the past. For some, it provided an understanding of the immense reverence that medieval people could give to manuscripts books.

I would say that from what I found, students were indeed drawn to medievalisms but were very interested in the physicality of the medieval book. Not only were they drawn to the beautifully illuminated works, they found charm in the rough and crinkly parchment of these well-worn codices. I hope this brief exhibition as well as the exhibition in Carleton’s History Department, Carleton’s Lost Manuscripts, inspires future codicological pursuits!


Thanks for reading!
Kate

The Design Brief: Medieval to Digital

As our project continued to grow, it seemed like new ideas were becoming actionable plans every day. This was undoubtedly exciting, but we quickly realised that because we operate largely in our specialised groups (Exhibition, Media, and Website teams) we faced the problem of stylistic cohesion between the teams. We needed a creative design brief, a concise document that outlined the styles, colours, materials, and requirements that would be universal in our project. A simple but vital example was matching fonts and colour scheme throughout our social media posts, exhibition, and website.

In a previous in-class brainstorming session we developed profiles and objectives for the project. We answered key design questions including:

-Who is our audience? Who are our contributors?
-What are our main objectives?
-What is our budget?
-What is mandatory for our project? What is supplemental?

Once we established the answers to these questions, we had a clear direction. We were ready to start producing —but first, we needed a cohesive design.
We knew our audience: exhibition guests would be students, faculty, and enthusiasts and what they shared in common would most likely be their residency (live in Ottawa) and their interests (enjoy medieval things, museums). It was important to address these in our design of both the physical exhibition and the website.

Ottawa residents would likely be drawn to the fact that the manuscripts and folia in our collection belong to an Ottawa institution, Carleton University. Therefore, the logo of the institution will feature quite prominently. Exhibitions tend to draw in visitors both young and old, and accessibility concerns were a major factor. We chose neutral dark tones (black, dark grey) and with white to provide the high-contrast needed for colour-blind visitors and those with eye-strain (after all, students and professors spend a lot of time looking at screens!). For our accent colour, we built a colour palette with coolors.co using a scan of one of the folio to be exhibited. The result was a beautiful variant of blue called lapis lazuli (#26619c) which was serendipitous following this article that came out earlier this year.

There were limitations to what we could accomplish with a wordpress site, but thankfully through reclaim hosting we were able to get access to some premium plugins. After a  crash-course refresher, I was able to manipulate the wordpress CSS (the style sheet used to style an html page) to give us the desired fonts, colours, and frames.

It was also important to have a contingency plan in our design brief in case key elements of the website did not work. For example, if we cannot create an instantiation of a Mirador viewer on our site, it was important that we have a backup plan for how to display our scans and their respective metadata.

Although we cannot anticipate all the roadblocks we face in designing both an exhibition and a website, a design brief is a great place to start. Not having the budget for a user-experience test, we stuck with tried-and-true styles and fonts in order to have as little error as possible. That being said, it won’t be perfect and feedback is always welcome.

—Kate Brasseur, Website Team Leader


Interested in watching the website go from bare-bones to exhibition companion? Follow our progress here!

IIIF Toolkit: Trials and Tribulations

We’ve returned home to Ottawa and we’re ready to start uploading our IIIF content to our Omeka site. Nothing works, everything seems broken. With moral low, we began to frantically google our problems. We were missing one very important part to make the toolkit work:

We needed to install and host a IIIF image server.

We first attempted to host our images on an online server, the Internet Archive. With the API still in alpha and the documentation still in progress, our results we far from perfect. Our images had their default resolutions set to thumbnail size and we could not manage to create proper manifests through archivelab.org. Perhaps we need our own Image Server that we can point to our Omeka install?

The next IIIF image server I attempted to install was Loris. But without dedicated server space, the server would be run locally (and therefore not always accessible). This wasn’t a viable solution for our project. We needed server space.

After discussing it with others in the department, we realized that we should get server space through our institution and allow an experienced computer scientists from the university install our IIIF Image server for us. This means a lot less challenges in the Terminal for me, and less of a chance that the image server will cause us issues (due to my modest installation attempt) in the future.

Working with Omeka(.org) and the IIIF Toolkit Plugin

After dabbling with setting up an install of Omeka.org on localhost, we decided that setting it up with a hosting service was a faster and more efficient way to go. We used reclaim hosting, which provides an easy install feature for Omeka Classic already built-in. After a little bit of initial setup we were ready to get started working with Omeka Classic with all the unrestricted functionality.

We knew we needed Plugins to make our Omeka look and behave the way we wanted so we checked out the Omeka documentation for Plugins (https://omeka.org/classic/plugins/) to search for some that might be good. When we had a list of the plugins we wanted and had them downloaded, we had to send them to our file manager on reclaim hosting through our FTP software (I was using FileZilla on Ubuntu, Marc went with Cyberduck for Mac). How to download, install, transfer, and use Plugins is all well documented on the Omeka Classic User Manual and is what we used to get them up and running.

We ran into an issue when attempting to install the IIIF toolkit, one of the tools we were most eager to use. We transferred the plugin over, and when it appeared on the plugin page, clicked “install”. But we received this error message:

Omeka has encountered an error
To learn how to see more detailed information about this error, see the Omeka Codex page on retrieving error messages.

There was a link provided leading us to a page on how to send error messages, but gave no clues as to why the toolkit wasn’t installing properly.

So the first thing to do was find out what there error was, but Omeka disables error reports automatically. To enable error reports, I had to find the .htaccess file in the root directory of our Omeka install and edit the line:

#SetEnv APPLICATION_ENV development

By changing it from a comment (by removing the #) to a line.

I attempted the IIIF toolkit install again and received this error message:

RuntimeException

The configured PHP path (/bin/php) does not point to a PHP-CLI binary.

Now it was just a matter of fixing the problem, which is that our plugin needs to execute code using the command-line version of PHP. I followed the instructions on this forum to fix this problem.