No, this is not about big data, at least not the sexy kind of big-data that makes venture capitalists and ed-tech analytics companies sit tall. Rather, I write to bemoan the challenges of teaching Digital History in the world of the cloud. Before the play begins, please note I write not to criticize the folks who create the DH tools mentioned below. Rather, I write to note there is an epistemological predisposition towards solo work in DH that makes teaching it at community colleges challenging.
Act one: GIS. Omeka is a content management system that I teach to my students as it helps them understand the need for standardized metadata when it comes to history presentations. It also helps them learn how historians always weigh what to put in and what to leave out when explaining the past. A stupendous plugin called Neatline lets students plot points and shapes on a world map and associate a variety of metadata, including dates, explanatory text, and html links to the original sources. I host my Omeka install with Reclaim Hosting, the best server option I've encountered and with banging customer service.
When all 45 of my students start inputing data into the same map, Omeka bogs down. I've checked my usage stats on Reclaim, and it's not their servers, it's just how the Omeka software processes changes. Truth in advertising, I know just enough code to know I don't know diddly about coding, so I can't say why Omeka slows with lots of folks using it. More challenging for me, when I go review the maps my students have made, every changed focus takes 5-12 seconds of "loading" time. Grading 80 GIS points requires I click, wait. . . . not long enough to do something else. . . wait. . . and read. Then I input the rubric in the learning management system, click in Omeka and wait. . . . .
To be clear, Omeka is by far the best teaching tool I've found for digital history, replacing four separate other tools. And there's a new beta version of the software that appears to be more attuned to group usage, called Omeka S. That said, to teach my student now (and I've been doing this for a couple years) I have to counsel a great bit of patience with tools that were never designed for a standard undergraduate class. To be sure, Omeka is open source, so I could teach myself how to self-host an instance of it on a local college server, and that may be what I need to do, but again, it doesn't look like my server is being overwhelmed with bandwidth issues, just too much data moving in an out of Omeka.
Act 2: Distant reading. Voyant Tools allow students to do distant reading in a fantastically-well-designed user interface. Like Omeka, you can download a local instance of it and install it on your local computer or on a server. In this instance, it my college's IT rules that prove a challenge. Running Voyant locally requires Java, which my college's IT no longer supports due to security issues. So, the obvious fix to overwhelming the free service the Voyant team provides through their web-version of Voyant won't work right now. I may try to find a way to load a Java Runtime Environment, browser, and Voyant on a flash drive and then copy that package 45 times for a DH on a stick option. Again, brilliant tool, wonderfully executed, frustratingly slow when used in a 45, person classroom.
Act 3: As part of an introduction to how historical GIS can help us ask different questions I have the students use the Stanford Geospatial Network Model of the Roman World. I ask students to calculate distances and speeds from different cities in the Roman world and then to explain why historical actors may have chosen to act is certain ways. The map is in it's 2.0 version and, by and large, works flawlessly, even with 45 students using it at once. Until it stops working. To be fair, I can get it to do some things, but not others. Right now I need it to calculate distances and times between cities so I can double-check my students' answers. Stanford will probably get back to me in a reasonable amount of time and it is entirely possible (probable?) that my user error is causing the problems. Still, I can't grade right now and anything that slows down grading for a community college professor is the root of all evil. UPDATE: I DM'd Jason Heppler at Stanford (he taught the intro to R course I took this summer) and he waved a magic wand. ORBIS is back up. Which reminds me that making great stuff is important, and having responsive support is equally important. Noting my gratitude for both the tool and the support.
Now, the field would not exist in its present state but for the hard-working humanists, coders, and other digital workers that created many of these tools. So, complaining that tools don't work well for lots of people seems a bit akin to a restaurant review claiming "such poor food, and so little of it." With that, however, I want to note that almost all of the tools I encounter that are easy to use, are not easy to teach to large groups. Those DH tools that are easy to teach to large groups (say Markdown) are not easy to use in a robust way. No, I can't ask my students to install MALLET to avoid a web-interface: many of my students only have the computer I place in front of them. Yes, I could use other services that disaggregate work on a single server, reducing bandwidth issues. For example, I taught historical GIS using Web ArcGIS. But that requires a separate login and is not well-connected with the other more historically-minded work that we do in Omeka.
Perhaps this is just where we are as a field, with mostly 2.0 tools that are good, but not enterprise ready. Perhaps I'm asking too much of 1st-year students when it comes to doing DH work. And perhaps we, in DH, need to start thinking big when we create tools, so that the tool works well with 50-100 first, before we add new features.
