Avoiding Nightmares in Teaching Digital Methods

„One can’t go wrong with this,“ I thought. Well – now I know better!

In an academic exercise, I presented some digital methods to teacher trainees. I wanted to enable them to use these methods deliberately later in school. The required tools were as simple as possible. It was important that they were quick to apply (as teacher’s time is very limited) and easy to use (so their pupils could work with them as well – without losing attention on the content of the lesson). Hereby, the content, not the technology, must be emphasized.

Therefore, I was sure that the main issue of the course would be the discussion of certain maps, graphs, word clouds, and networks. It was self-evident to me that the trainees must use the tools by themselves in order to recognize the creation of methods more thoroughly. Since in humanity departments most times laptop-rooms do not exist (and this was also the case in Heidelberg’s faculty of Theology, where I taught this course), everybody had to bring along their own notebook.

The first method I wanted to show was based on a simple web application. Everybody had to open a browser, go to the site, and start with the application. That’s it. But the web application needed Java, it had problems with Windows 10, and didn’t work with every browser. Tons of problems arose. At the end, only 3 people were able to use the tool by themselves.

The next tool, they first had to install. One person did not have a Windows computer like the other colleagues, but a MacBook. However, the software didn’t work with Mac. Again, the software needed Java, which caused some trouble within the program. At the end, at least half of the course had results they could use.

Afterwards, I wanted to enable them to lemmatize texts by using the TreeTagger. We installed it with the support of a helpful Youtube tutorial. Half of the people were successful; the others had an ample choice of errors.

Last but not least, I had another web application on the program: newer than the first one and well supported. “At least this would work,” I thought with a little bit of hope. It didn’t. The server was down on that particular day…

At the end of the day, I expressed my feelings via Twitter:

After a few comments (thanks to @Mareike2405 , @esthet1cs , and @kaischi  for very fruitful insights), I realized what could have been done to avoid this nightmare: To prevent situations like described above, we must use digital environments. The teacher can upload the data on a virtual desktop and the students are able, once registered and logged in, to work on them with a preinstalled software. My academic exercise still had a second session left, where I wanted to put it to test. I selected the digital research environment of the Ludwig-Maximilian-University of Munich called  DHVLab (Digital Humanities Virtual Laboratory) headed by the art historian  Prof. Dr. Hubertus Kohle due to the following reasons:

  • comparatively many preinstalled application tools which allow all forms of practicing digital humanities (programing with Python; networks with Gephi; annotating with GIAnT; …)

    Screenshot: DHVLab
  • more programs to support working and teaching (graphic programs; MySQL; RStudio; web browsers;  LibreOffice; …)

    Screenshot: DHVLab
  • if a program is missing, you can easily contact the administration staff to install it
  • commendable friendly support (fast accessibility, helpful video-documentations)
  • it’s easy to transfer local data to the DHVlab and to share it with the participants via cloud
  •  participants do not have to be a member of a certain institution, since the teacher decides if they get access or not (in my case, this was very important, because not everyone in my course was a member of the university)

To use the DHVLab as a teacher, I first needed a “lab.” In order to get one, I contacted the team ( dhvlab@gwi.uni-muenchen.de) and explained what I wanted to do with it. Then, I got a teaching account and was able to create my own lab. After that, participants were now able to  sign up on DHVLab and join my lab.  It is recommendable that you invite the participants before the session starts. If they all visited the virtual desktop once before, it will start faster when the session begins and all members log in together.

Now, the second session of my exercise started. I introduced the DHVLab for 10 minutes and we discussed advantages of remote desktops in general. Then, we started with the web applications and it worked: Java was preinstalled and everybody had the same conditions. It worked with Windows, it worked with Mac, it worked with every browser (the team of the DHVLab recommends Google Chrome if there are any problems with the virtual desktop itself). Afterwards, we didn’t need time to install a software which we needed the next method. It was already installed and we were able to concentrate on its applications.

And what if the server of a web application is down like it happened to me at the end of the first session? Unfortunately, even the DHVLab can’t help – that’s simply bad luck and you should avoid web applications. However, in some cases there is a solution. Sometimes, independent local versions exist. In my case, a  local version of Voyant Tools was just released a few days after the first session of my exercise.

“One can’t go wrong with this,” I thought in the beginning of the second session; and well, thanks to the DHVLab, that was absolutely right. Sign up to the DHVLab, start the application, work with the data. That’s it –  a dream, not a nightmare.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.