Knowing That I Don’t Know: Asking Questions

As I near the end of my second term as a DHA, it is a good time to reflect on what I’ve learned from this experience so far. Since starting in September, I have learned, been exposed to, and experimented with a number of digital tools. Although the major tool I have been using in my work is ArcGIS, being part of the DHA team and Team Workhouse means that I learn more every week from the work other team members have been doing. However, perhaps more importantly than learning digital tools, I have learned the importance of communication and asking questions.

For teams like the DHAs and Team Workhouse, communication is crucial. Just like the game objects in Bard’s Unity project that needed to share information in order to function, people on teams also need to share information in order to function smoothly. Uncertainty about who is doing what is not efficient or productive for teams. A particularly important part of communication is asking questions. While I have learned a lot about digital tools these last two terms, I know that there is a lot that I still don’t know. While sometimes it can be productive to struggle through uncertainty to figure something out, other times the process can be greatly improved by a quick meeting or email exchange.

One example of this was when I was helping to migrate our website to a new page (you can see our current website here!). In particular, I was struggling with moving media (especially videos) over to the new site. I spent time looking through Reason’s documentation and trying to figure it out myself, but made very little progress on my problem. Finally, I talked to Doug Bratland, Web Content Specialist, part of Carleton’s Web Services Group. He was incredibly helpful and in just a half hour was able to fix the problems I had been working on. Not only did he solve the problems I was having, but he also took time to explain why I had been running into problems and make sure that I understood what he did to solve them. I came away from that meeting with not just solutions to the website issues, but also a deeper understanding of how Reason CMS works. If I had not asked for help and questions about the problems I had with the website, not only would it have taken much longer to fix, but I wouldn’t have learned as much about how it works. Although just one example from my two terms as a DHA, it nevertheless illustrates the importance of asking questions about things I don’t know. And although I have learned a lot about digital tools in the past two terms, there is still a lot I don’t know. So, I will need to keep asking questions.

How To Do Your Job When You Don’t Know How To Do Your Job

The cool thing about this job is that I get to constantly be doing new things and jumping into new projects. The flip side to this, however, is that each project is unique and requires very different skills – skills that I (very often? most of the time?) don’t yet have. So this term, I’ve been getting used to the fact that not having a skill to do a certain job doesn’t mean I don’t do the job, it means I get to learn how to do it. The question then often becomes, “Where do I even start to learn how to do X?” The following are some tips and tactics I’ve been working on using when I’m faced with a daunting task that I’ve never done before:

  • Just ask. This seems obvious, but it’s often much easier said than done. People don’t want to risk sounding dumb by asking questions, but 1) people probably won’t actually think you’re dumb, and 2) isn’t it better to ask and learn how to do something correctly than spend all your time doing it wrong?
  • Google it, but be smart about it. Again, this seems obvious, but Google is a gift and a curse. Be wary of bad advice (you wouldn’t cite a Buzzfeed article for an academic paper, so why should you take serious advice from it?), and think hard about the search terms you use (be precise, try a variety of related terms, etc…).
  • Pretend that you know what you’re doing. I love this tactic. Sometimes I know that I don’t know what I’m doing, but I don’t know what I don’t know, so I just start working until I get stuck in order to figure out where the problem is. It’s a really great way to pinpoint exactly what you don’t know.
  • Use sites that were created for these situations, like Lynda.com. If you’re a Carleton student, you already have a subscription! Even if you can’t find a video to explain exactly what you’re supposed to be doing, it can help you to get a hang of the general terminology relating to the task at hand or the basic functionality of a tool you’re learning to use.
  • Look for existing examples. Chances are you’re not the first person to do anything, so it’s a great idea to find examples of best practices and conventions. This is true for pretty much anything, but particularly when you’re doing something totally new.

Of course, the best part about not knowing how to do something is that you get to learn how to do it and then a week later when one of your colleagues doesn’t know how to do the same thing you get to pretend that you’ve known it all along and teach them how to do it! Such is the cycle of life. Remember, everyone’s just trying to fake it ‘til they make it.

All things Bede

As of this moment, I’ve been a member of the Digital Humanities team for seven sometimes challenging, frequently exhilarating and always rewarding weeks. I’ve learned a whole lot – from how to write good documentation to using tools like Omeka and ArcGIS to valuable cultural lessons such as being introduced to the 60’s Batman show.

I spent a good portion of my time this term focusing on the Bede Project which aims at creating an online commentary to the Ecclesiastical History of the English People by Venerable Bede. Three Carleton professors – Rob Hardy, Austin Mason, and Bill North – are collaborating on this project. Once finished, it is going to be part of Dickinson College Commentaries. I started working on this project over a year ago and since then have grown fond of Bede and his clear if occasionally funky Medieval Latin.

This term I’ve been focusing on two aspects of the project – vocabulary lemmatization and mapping. Lemmatization is a fancy word for mapping every inflected word form to its dictionary form, or lemma. Most of it was done automatically using a lemmatizer script, so what was left for Bard and me to do was to fill in the words for which the lemma for some reason wasn’t found. That would happen either when the inflected form was ambiguous, in which case I went back to Bede’s text to figure out which of the umpteen possible things it meant, or because the word wasn’t found in the word list the lemmatizer pulled data from (that would be true for Medieval Latin vocabulary, names, or words that had an alternative spelling). While slightly monotonous, this is a great refresher for my rusty Latin, and there’s a fun problem-solving aspect to figuring out which of the many possible meanings a word has in any given context.

The other part of the project I was focusing on is collecting all the data necessary for creating an interactive map of Bede’s England. I created a spreadsheet with a list of all the places mentioned in Bede using Plumber’s index of place names and found coordinates of the corresponding modern places. This process had its own challenges: sometimes it would not be clear where a place mentioned by Bede was located. When that was the case, I engaged in extensive googling and searching through various commentaries to Bede’s text hoping to find a note on the corresponding modern location (sometimes the name mentioned in Bede and the modern English name of the place don’t sound at all alike – for instance, Verulamium is now called St. Alban’s). After that I verified the coordinates of each of the places and added links to Pleiades and/or PastScape for the locations that have an excavated medieval site. The spreadsheet was then uploaded to ArcGIS, resulting in the following map (pretty cool, right?):

The next step I will be focusing on is adding a layer with all the rivers.

Organization: Yes, it really works.

Seventh week is beginning (did anyone else just go into fight or flight mode after reading those words?), which means that I’ve now had well over a month to settle in to my first term as a DHA. Initially, I was going to write that I had spent the first several weeks of this job learning the ropes and getting the hang of how it goes (because I have indeed learned a great many things about a great deal of stuff), but then I realized that that’s not really true. More accurately, I’d say that I’ve jumped in headfirst, taking a “sink or swim” approach to this new job, so now seems like a great time to come up for air and do a bit of reflecting.

In short, I think I can confidently say that I have not utterly failed (I joke, I’ve actually done quite well). I owe this success in large part to the people I work with, who are intelligent and always helpful. But there’s another tool that has been key in learning quickly how to tackle a new project: the documentation.

The nature of student jobs and participation in organizations is that the turnover is fast – jobs and organizations are looking for new employees and members every year, so making training efficient can be essential. I’ve participated I some student organizations where it seems like every week we’re saying, “I’m pretty sure so-and-so did a project like this a couple years ago, but then they graduated…do you have idea how we could get their contact information to see if they’ve still got that information? Or maybe I still have an email about it from freshman year…” Yes, sifting through emails from 2014 is one of the warning signs that something went wrong…

Student turnover can be a logistical nightmare, but this job has been proof that it doesn’t need to be. It’s been so easy for me to access project history, familiarize myself with all the relevant tools and information, and then quickly jump into new projects. Not all of it is perfect, but the effort was made and I am reaping the benefits. If better (or any) documentation is something you think your job or organization could benefit from, here are some tips I’ve gleaned from my experience:

  1. Be specific and consistent when naming documents. “Meeting 3/5/15” is not helpful. “Initial Meeting with Web Developer” is helpful.
  2. Note specifically who has done what. If you need to contact someone about work they’ve done, you don’t want to be guessing between 10 different people.
  3. Take the time to organize. The point of documentation is that it makes everyone’s lives easier down the road. Make everything easy to find using section headers and bulleted lists.
  4. Note things that did and didn’t work. For example, if you’re reflecting on how an annual event went, a note that says “Next year get catering order in 1 week before event” can save planning time and prevent disasters in the future.
  5. Keep everything in one place. This seems obvious, but it can be very easy to for things to go missing, especially if there are a lot of people working on one project. For example, having one big Google Drive folder ensures that everyone knows where and how to access everything.

Now go forth and document!

Something to Think about When You Work on DH Remotely

The past winter break I was in China where some websites and web services are not available. My days were a little bleak without Youtube and Facebook. The worst part was that I had no access to my Carleton Gmail account or Google drive. This made my task of uploading articles to Journal of Historians of Netherlandish Art (JHNA) particularly challenging – it was hard to contact my supervisor and the authors, and it was impossible to view the JHNA articles, figures and upload guide since they are all stored on Google drive. I was glad that I realized this problem before I left campus. I tried to resolve this issue by giving my supervisor an alternative email address and installing Carleton GlobalProtect VPN. However, the VPN didn’t work for the first few weeks of my break. Here’s a rundown of the problems I faced, and how I solved them:

 

(the ones marked with [FAILED] have failed and thus not recommended):

First 2 days of my break

  1. [FAILED] Sat and cried

Week 2

Using my personal email account, 

  1. contacted my supervisor, explained the situation
  2. [FAILED] filed an ITS report, which was automatically rejected because it was not sent from a carleton account
  3. given that (2) had failed, reached out to all my friends who work for ITS for help

Week 3 – 4

  1. VPN troubleshooting with tremendous help from ITS
  2. [FAILED] Experimented some random free VPNs found using Baidu (a Chinese search engine), which brought my laptop some virus problems
  3. Switched to Yahoo (relatively more reliable than Baidu) and found a few highly ranked VPNs in IOS app store
  4. Tried one of the VPNs, “Betternet VPN”. It’s free, and though slow, it works! *Note: This app can only be found in the American app store. An American Apple ID is required.
  5. ITS made some backend updates and GlobalProtect started to work for me!

 

To summarize, if you are traveling outside of the United States and are likely to have similar problems, consider doing these in advance:

  1. Install Carleton GlobalProtect VPN (or other trusted VPN software)
  2. Friend and bribe ITS workers
  3. Give people you need to contact an alternative email address that you have access to in any network environment
  4. Save as many things you might need from Google drive to….your hard drive?…as possible
  5. Download other reliable VPNs to your tablets just in case GlobalProtect fails you

And lastly when you are on your trip and find out that none of above helps, please be patient and stay positive – there’s always going to be a way out; otherwise, enjoy your days free of digital distractions!

 

Unity Updates: It’s all about communication

In between working on other projects, like typesetting articles for Carleton’s Undergraduate Journal of Humanistic Studies and slowly filling a spreadsheet with lemma and definitions of Latin vocabulary, I’ve continued my Unity training. In this tutorial, I learned more about lighting, assets, and scripting. I also built my first game controller to manage score-keeping and UI (user interface) and added my first sound effects.

Adding the game controller created some logistical problems which, though I’m new to them in Unity, are very familiar to me as a programmer. Essentially the problem is that when different objects are separated out, their information and variables are private. Sometimes, for instance, the game controller doesn’t have a way of observing something that happened to the player object, but it needs to be able to act on that information. Setting up the objects so that they can communicate about events is essential, but it’s not always obvious in the beginning that they need to share information. Figuring out that aspect of scripting will be very important in scaling development from demo-sized games to the large Unity project for which I am training.

Use arrow keys/WASD and mouse to play my game.

Updates from the Workhouse: Mapmaking

A significant part of my work continues to be for Team Workhouse, including the work I did over winter break for Professor Susannah Ottaway ‘89. My earlier post detailed my process for determining the locations of parishes in England in order to better understand the use of workhouses for poor relief in the late 18th and early 19th century. I continued to find locations over break, and then double checked those locations I had found to make sure I hadn’t missed any parishes and so I was confident in the new locations. Finally, though, I finished that and reached a point where I could leave the spreadsheet behind and begin mapping! Of course, I quickly learned that you can never really leave the spreadsheet behind.

A map showing all parishes with access to a workhouse in England and Wales.

I quickly ran into a problem: I was working from home, so I only had access to ArcGIS online, which, while a great tool, is not as powerful as the desktop version. The online version will only take up to 1000 entries in a CSV upload at a time, and the database has a little over 3300 entries! I was able to get around this by splitting the spreadsheet into four separate uploads, broken up along county lines to make my life a bit easier. I finally got all four CSVs into ArcGIS online, double checking that all locations were in fact in the map document.

Once I had all the locations in, I was finally able to step back and look at the data as a whole (insert my rough map of all the workhouses colored by county). I soon noticed what looked to be another problem. Since the parishes were colored by county, there were some obvious outliers. In addition, I had imported a layer that showed the 1851 county boundaries, and many of these outliers did not match the county boundaries of that layer. I went through the counties again, looking at parishes that were at least three miles outside of the county boundaries, recording those that fell outside those boundaries to later check to see if the location was correct, and potentially correct it.

An example of the 1831 English counties and exclaves.

While I did find some incorrect coordinates, many of them were actually correct. As I dug into the parishes I thought were incorrect, I learned that many county borders had changed, and many had even had parts of their counties that were not continuous with the rest! Fortunately, I was able to find a layer file of the English and Welsh counties in 1831 courtesy of the Cambridge Group for the History of Population and Social Structure , when many of these exclaves still existed. Using this layer, it was much easier to visually check that parishes seemingly outside their counties were in fact within their boundaries. Once again, the county layer made my life much easier – instead of going back through my spreadsheet, quicker visual checks were now possible for what I thought were incorrect – and many did turn out to be correct.

A map showing the number of parishes with access to a workhouse by county.

Now that I’m confident in the parish locations, my next steps are to really dive into the maps and cartography. The data for the maps is all there, but the task now is to create polished maps for both print and online publication. Despite some of my struggles with both the technology and the content (I had no idea that counties could have exclaves!), the use of GIS was a valuable tool, not just for the cartography, but also for the vital step of confirming that parishes were actually where they were supposed to be.

Martha Says Hello

img_5824Hi! My name is Martha Durrett, and I’m a junior Computer Science and English major at Carleton College. Computer science and English! What? “Well those don’t overlap at all,” you might say. In some way you’re right…I certainly won’t be counting any of my CS classes for English credits. But in many ways that’s wrong – for example, digital humanities! Could I have found a more fun and engaging way to integrate my two majors?

As I learn more about digital humanities, I’m hoping to continue to break down that distinction between “English major” and “computer science major.” I want to discover fun and engaging new ways to integrate not just English and computer science, but any subject that piques my interest. Who says subjects need to be separate? (Finland doesn’t – check this out if you haven’t heard about Finland’s radical educational reform.)  Throughout the rest of the year, I’ll be thinking about how the digital world is changing expectations about how we’re supposed to learn about and interact with the humanities. If you ask me, the humanities (whatever that hefty term entails) have spent far too long hiding inside of textbooks, and it’s about time we did something new with them!

Workhouse Update – Elizabeth’s Ongoing Work

Gressenhall Workhouse in Norfolk, England
Gressenhall Workhouse, Norfolk, England

Most my work this term has been part of Team Workhouse, which is a research project that aims to create a digital reconstruction of the Gressenhall Workhouse in Norfolk, England during the 18th century in order to better understand the lived experience of workhouse inmates (my research this summer and presentation at the Midwest Conference on British Studies is also part of the Team Workhouse). This term, I’ve been working mainly on locating British parishes in the early 19th century. Our goal is to create maps and explore spatial relations of workhouses in England, based on an 1803 Parliamentary report. Professor Susannah Ottaway ’89 and others have already done significant work on finding the locations of the parishes and other places mentioned in the report. There are still many that don’t have locations, however, and that is what I’ve been working on. Although we ultimately want to know where the workhouses were, that information is not accessible to us at this time. We can find the location the churches, and often workhouses were very close to churches. In addition, the maps will be show larger areas, so individual parishes will be relatively small. As such, we have decided to use church buildings as approximations for the parishes and their poor relief.

My typical process looks like this: I would have a parish name (for example, Dowley, Magna, Wellington Division, Bradford Hundred in Shropshire), and would begin on a genealogy website to find out some preliminary information about the parish. I can typically get a church name (for example, Holy Trinity), and I then look to the Historic England pages for more information on the church building. This is the Historic England page for Holy Trinity, Great Dowley, from which I know that the current building is from 1845, although the site is older. I find the church on Google Maps (with the map on Historic England to help me), and use the coordinates for the parish.

A document of notes on parish locations for the Workhouse Project
A document of notes on parish locations for the Workhouse Project

Some places pose more challenges and require more investigation. In London, many of the parish churches of parishes listed in the 1803 report were destroyed in the Great Fire of London in 1666 and never rebuilt. For those parishes, I used this map, which shows London before the Fire. Even so, the streets have changed since then, so I had to estimate where the churches would have been. Another very common issue I have run into is name changes. “Warnslow” becomes “Warslow,” “Laytham” becomes “Layham,” and “Monythustoine” becomes “Mynyddyslwyn” (or “Mynyddislwyn” or “Mynydd Islwyn”). Some name changes are close enough that I am confident they are the same place, especially given the extra information, such as church name or county. Others, I find sources about the different names (especially that last one) to confirm that they are indeed the same place. For the most difficult parishes, I often had to resort to Google searches, old maps (there are many here!), and any other resources I could find on small parishes. I increasingly appreciate parish websites that have histories of their own parishes, which have been very valuable to me during this processes. It has taken many hours, but I have almost finished finding the unknown parishes, so before long we can move on to mapping the parishes and exploring the spatial patterns of 18th century poor relief.

A Stylin’ Term: an update on what Lydia did this fall

Hello! The end of fall term is near and the time seems ripe for another blog post. For the past few weeks, most of my digital humanities time has been devoted to developing and revising CSS quote styles for Global Religions in Minnesota, a locally hosted Omeka project that documents the lived experiences of members of various religious communities in Minnesota.

Because the research and content creation is primarily done by students enrolled in a Carleton religion class, it’s important that we make the backend user interface as intuitive as possible so that they can focus on research and writing. Eventually, the quote styles I created will be integrated into the WYSIWYG (what-you-see-is-what-you-get) interface in Omeka so that applying the CSS only takes one click. So far, I’ve made some styles for varying lengths of block quotes, which are portions of texts quoted from other sources and contrast visually with the main text. Below are screenshots of sample styles I made for short, medium-length, and long block quotes. I tried to apply the most visually striking styles for the shorter quotes and used smaller font and minimal graphics for longer ones.

A short block quote:

screen-shot-2016-11-05-at-5-03-16-pm

A medium-length block quote:

screen-shot-2016-11-05-at-5-03-27-pm

A long block quote:

screen-shot-2016-11-05-at-5-13-52-pm

To get feedback on these styles, I used CodePen, which is a neat website that allows users to edit source HTML/CSS/Javascript code and see changes in real-time. Pens are shareable with other team members and with the general public, which makes collaborative web design and idea sharing really convenient. Even if you’re not currently working on a web development project, there is a lot of interesting animation and styling work to look at for design inspiration!