During the fall term 2019, I’ve been working on the WordPress site and updating the Carleton DHA page.
In the former project, collaborating with professors from the Classics Department, I created CHIANTI site, a WordPress site. To add and organize various contents, I used several plugins: Elementor to organize the content pages, Shortcodes and List category posts to order posts sorted by categories on a page, Document Embedder to convert language learning sources to be downloadable, Smart Slider to use a video carousel on the student portal page, and Pods Admin to create a submission form for faculties.
In the course of arranging and refining the site, I realized some tips which would be helpful when creating websites at another time. I’ll write them down for future use.
Clarify the audience and objects of the website.
When you get stuck, google for the troubleshooting first. There is maybe somebody who is in the same situation and already asked similar questions.
Be careful about the consistency – theme colors, fonts, font sizes……
When you are not sure which plugin to use, see their review, download numbers, the latest update date.
If you create a website and then yield control over it to the third party, make sure to create a concise and easy to follow instructional document. (preferably with some screenshots as needed) This is actually a great way to keep information in one place, such as the theme colors and fonts.
Finally, although there is a lot more to mention, communicating with partners/clients is crucial to improve the website closer to what they expect.
Regarding updating the Carleton DHA page, with permission to access and edit the page, I mainly updated the DH members for this year and the past projects. Updating past projects especially required some important things to keep in mind: 1) Use visually eye-catching screenshots of the project, 2) Check the copyright of the image within the screenshots, 3) Avoid controversial contents/images publishing on the web, 4) Make sure that private information is hidden.
As you’ve seen, I spent most of the time working with WordPress. For the next term, I hope I’ll be working with other types of digital tools.
One of the projects I’ve been working on this year has been a textual analysis of the fifteenth-century London Chronicles for an English professor’s research. The professor hoped to identify and isolate place names in the text (such as London Bridge, Sussex, etc.) and make a map of all the data. This is where the Digital Humanities team came in: what software and digital tools could we use to extract this data and display it in an insight way?
The first tool we examined was Voyant, an online textual analysis tool that creates data visualizations. We uploaded a PDF of the London Chronicles to Voyant and played around with the website to see how it worked and determine whether it was effective.
While Voyant was great for analyzing macro data sets and getting a holistic view of the text, it was rather ineffective for gathering specific iterations of place names and appeared no better than manual close reading for this purpose. One of the other problems we encountered were the variations in medieval spelling; for example, Voyant created a separate category for “London” and “Londan” even if they referred to the same place.
We then turned to a different tool to help map our place names: Edinburgh Geoparser. Geoparser created a wonderful map of the place names. However, it was unable to quantify the number of times a place name appears or arrange the place names in order of frequency. Thus, it was great for visualizing the places but not ideal for textual analysis.
Finally, after testing these different softwares, we stumbled upon a Gazetteer of Early Modern Europe which contained a list of place names, their spelling variants, and their location. We collaborated with a member of the Data Squad, a local Carleton organization dedicated to organizing data, to produce a program that would cross-reference The London Chronicles PDF with an XML of this data. In this manner, we would be able to get a reliable count of place names in the text that included their spelling variants.
This process has taught me that Digital Humanities is a lot of trial and error. In doing this research, I’ve learned there might not be one perfect tool for a project, but combining different resources and collaborating with others allowed me to find an innovative solution. This experimentation and sharing of ideas and research is vital to the work we do as Digital Humanities Associates.
This term, I’m making my first foray into the world of being an in-class Teaching Assistant (TA). In past terms I’ve worked as an out of class TA, holding office hours and offering outside support, but this is my first time actually attending class. This means that there’s some new things for me to figure out, but there’s also some things that I learned from being a TA last term that still apply.
Ana and I were out of class TAs for a Classics course last term and I learned some important things from that experience. One thing I always try to do now when I’m working with a student is check what they do know. Immersed as we are in the world of metadata, I didn’t think to explain what metadata itself was. But pretty early on we got that question – what exactly is metadata? And once we got that question, it made sense. Metadata was not something they were studying in class, so there was no expectation that they would know what it was. After that, I made sure to check with students what they knew about Omeka and metadata first, so I would know where to start that would be most helpful. Because of course there is also the flip side to this problem – if a student is familiar and comfortable with metadata, there’s no need to explain it. So I always found it most helpful to check first before beginning any explanations, so I could meet the student where they were.
An aspect of being a TA that is absolutely new to me is being in class with the students. On Wednesday there was time in class for students to work on an assignment in pairs. I was a bit shy about going up the students when they were working, and at first just wandered and waited for someone to ask a question. I realized after a little while that actually approaching the students was more helpful. While when I wandered past the students wouldn’t ask any questions, if I prompted them with a simple, “how’s it going for you?” they frequently would ask me a question. So although I was shy about doing asking them directly, it was more productive for both of us if I did. I’m still trying to get more comfortable in my new role, but I’m learning some good approaches along the way in order to provide assistance for both the professors and students in the most helpful way.
See some of the work the class has been doing on the blog!
I have spent a large portion of my worktime this term looking at mapping tools and ways of visually representing different kinds of geographic data. We used ArcGIS for creating a map of Bede’s England (you can read more about it here) and that worked really well for the purposes of the project: it allowed to denote different types of objects (e.g., a town, a monastery, etc.) with different symbols and link pages that alluded to those places and gave a clear visual representation of the objects. However, as much as I love ArcGIS (I think it’s really cool!), one can imagine wanting to do certain things with maps that it’s not perfect for.
This term I started working on the Carleton Guide to Medieval Rome to which students who go on the Carleton Rome OCS program contribute pictures and stories about different monuments and places in the Medieval city. The goal is for site visitors to be able to go on a particular “walk” and, while on that walk, learn about the pieces of the Medieval Rome they encounter along the way. So I have started looking for a platform that might be better suited for this goal than ArcGIS and found a really nifty one – Neatline, an exhibit builder that uses Omeka items to create interactive stories including timelines, pictures and georeferenced historical maps (I’ll explain what that means below). I have only started playing around with it but have already discovered a wide array of really great tools.
First, you can use actual historical maps (scanned images of old maps, that is) to overlay the basemap. That is a fantastic visual way of integrating the ancient or Medieval city into a modern one – and bring a historic map back to life! I used an 1830 map of Rome from David Rumsey map collection above (“1830 is not Medieval!” you might astutely observe. You are totally right – I picked this one as an example mostly because I liked how it looked). To do that, I had to georeference the map – a fancy term for identifying several common points on both maps – using a very straightforward online tool called MapWarper and then exported it to Neatline.
Then I added a couple of objects onto the map – in the screenshot above you can see the Temple of Hadrian, or Hadrianeum. I first created a new item in Omeka and then imported it into the Neatline exhibit – you can import all items with a certain tag which will be handy if a lot of images need to be added. Neatline places the point on the map for you if you include the coordinates in the metadata – that part turned out much more confusing than it sounds, however. It turns out that the coordinates need to be in a very specific format, WKT (or well-known text). Wikipedia told me that the format for a point is POINT(# #). Unexpectedly, when I entered the lat and long numbers, Neatline placed the temple of Hadrian…in the ocean off the west coast of Africa. After some frustratingly futile googling, I found out that the coordinate WKT uses coordinates in a coordinate system called Pseudo-Mercator, and the lat and long values need to be flipped (I’m still puzzled by all of that).
In addition to adding points on the map, you can also add lines and geometric shapes. Lines of different colors and points could be used to represent different walks across the Medieval city of Rome – I’m excited to try that and see how it turns out!
While my colleagues have been migrating content from our old website to our new not-yet-live one, I’ve been working on learning my way around the Unity game engine, a major part of Project Workhouse. I started from scratch with only a vague knowledge of C#, the language that customized scripts are written in for Unity. In the past week I’ve worked through the “Roll a Ball” tutorial and gotten started on importing assets like textures and materials and using them to good effect in a 3D game environment. – Bard
Here are some snapshots from my version of the “Roll a Ball” tutorial: