Learning by Doing: Labs and Pedagogy in the Digital Humanities

The digital humanities adore labs. Labs both symbolize and enable many of the field’s overarching themes: interdisciplinary teamwork, making/building, and the computing process itself. Labs give digital humanists a science-y legitimation that, whether we admit it or not, we find appealing. Labs aren’t necessary for doing digital humanities research, but in terms of infrastructure, collaboration, and institutional backing they certainly help. Along with “collaboration” and “open” (and possibly “nice”), “lab” is one of the field’s power words. With a period of accelerated growth over the past five years, world-wide digital humanities labs and centers now run into the hundreds. We overwhelmingly focus on labs in this kind of context: labs as physical research spaces. I’d like to move away from this familiar ground to discuss the role of lab assignments within a digital humanities curriculum. While reflecting on my own recent experience of designing and using labs in the classroom, I realized it spoke to many of the current issues facing the digital humanities.

Let me start with some background. This past autumn I taught my first college course, “The Digital Historian’s Toolkit: Studying the West in an Age of Big Data.” It was one of Stanford History Department’s Sources & Methods seminars, which are classes aimed at history majors to get them working intensively with primary sources. When I was designing my course a year ago, I decided to blend a digital humanities curriculum with more traditional historical pedagogy. Under the broad umbrella of the nineteenth-century American West, I used a specific historical theme each week (mining, communications, tourism, etc.) to tie together both traditional analysis and digital methodology. As part of this, over five different class periods students met in the Center for Spatial and Textual Analysis to complete a weekly lab assignment.

In designing the course, I wrestled with a problem that faces every digital humanist: the balancing of “traditional” (for lack of a better term) and “digital.” How much of my curriculum should follow a seminar model based on reading and discussion? How much should it follow a lab model based on technical tools and techniques? As is often the case, pragmatism partially informed my decision. Because my class was part of a required series of courses offered by the department, I couldn’t simply design a full-blown digital humanities methods course. It had to have a strong historical component in order to get approved. This juggling act is not uncommon for digital humanists. But more philosophically, I believed that digital tools were best learned in the context of historical inquiry. An overarching theme (in my case, the late nineteenth-century West) helped answer the question of why a student was learning a particular piece of software. Without it, digital pedagogy can stray into the bugaboo waved about by skeptics: teaching technology for technology’s sake.

I designed my labs with three goals in mind. First, I wanted my students to come away with at least an introduction to technical skills they wouldn’t otherwise get in a typical history course. Given my background, I focused largely on GIS, textual analysis, and visual design. I didn’t expect my students to become geospatial technicians in ten weeks, but I did want them to try out these kinds of methods and understand how they could be applied to historical problems. This first goal speaks to the alarmist rhetoric of a “crisis in the humanities,” of falling enrollments and shrinking budgets and growing irrelevance. In this caricature, the digital humanities often get remade as a life-boat for a sinking ship. This view is obviously overblown. But it is important to remember that the vast majority of our students are not going to end up as professors of history, literature, or philosophy. While there is a strong case to be made for the value of the humanities, I also think we need to do a better job of grafting other kinds of skills onto the field’s reading/writing/thinking foundation.

Second, I wanted students to learn technical skills as part of a larger intellectual framework. I pursued this in part by assigning specific techniques to answer larger questions. For instance, how does Mark Twain’s western novel Roughing It compare to other iconic nineteenth-century works of literature? Instead of assigning thousands of pages of text, I had my students use topic modeling to compare Roughing It to other books such as Uncle Tom’s Cabin and Little Women. But labs were also an effective way to concretize some of the contemporary issues swirling around technology. In one of the labs, students applied different kinds OCR software to a sampling of pages from an Overland Trail diary they had read earlier in the week. This gave them a chance to peer behind the curtain of large-scale digitization projects. When you experience first-hand just how many words and characters the OCR process can miss, it makes you think more critically about resources like Google Books or LexisNexis. Teaching in the digital humanities should, in part, force students to think critically about the issues surrounding the tools we use: copyright, access, marginalization.

Finally, I wanted students to learn by doing. There’s a certain passive mode of learning endemic to so many humanities courses: go to lectures, write a few papers, study for an exam, make comments in discussion. Student passivity can be inherent to both the pedagogical form itself and how it’s practiced, as anyone who has sat in a lecture hall or watched a student coast through discussion can tell you. Don’t get me wrong: bad labs can be just as passive as lectures. But done right, they emphasize active learning based on immediate feedback. As much as I’ve soured on the term “hacking” and all the privileged baggage it can carry, it is a useful term to describe the type of learning I want my students to engage in. Try something out. If it doesn’t work, try something else. Under this rubric, mistakes are a necessary part of the process. Feedback is more immediate in a way that enables exploration, tinkering, tangents, and restarts. It’s a lot harder to do this with traditional assignments; trying out something new in a paper is riskier than trying out something new in a lab.

This last goal proved the hardest to meet and constitutes one of the major hurdles facing digital humanities pedagogy. We want to teach digital methods not for their own sake, but to fit them within a broader framework, such as how they help us understand the past. But to get to that point, students need to make a fairly substantial investment of time and energy into learning the basics of a particular tool or technique. I tried to scaffold my lab assignments so that they became less and less prescriptive and more and more open-ended with each passing week. The idea was that students needed heavy doses of step-by-step instruction when they were still unfamiliar with the technology. My first lab, for instance, spelled out instructions in excruciating detail. Unfortunately, this led to exactly the kind of passive learning I wanted to avoid. I liken it to the “tutorial glaze” - focusing so much on getting through individual tasks that you lose track of how they all fit together or how you would apply them beyond the dataset at hand. The ability to teach early-stage technical skills involves a litany of pedagogical challenges that humanities instructors are simply not used to tackling.

By contrast, my final lab gave students a dataset (a map of Denver and enumeration district data from the 1880 census) and asked them to formulate and then answer a historical question through GIS. By nearly any metric - enthusiasm, results, feedback - this proved to be the most effective lab. It forced students to engage in the messy process of digital history: exploring the data enough to formulate a question, returning to the data to answer that question, realizing the data can’t even begin to answer that question, formulating a different question, figuring out how to answer it, and deciding how to visualize an argument. I was even more satisfied with their reflections on the process. Some described the frustrations that came with discovering the limits or gaps in census data. Others remarked on how their own mapmaking decisions, such as changing classification breaks or using different symbology, could completely alter the presentation of their argument. It’s one thing for students to read an essay by J.B. Harley on the subjectivity of maps (which they did). It’s another for students to experience the subjective process of map-making for themselves. Learning by doing: this is what was labs are all about.

To try and help others who want to integrate labs into their curriculum, I’ve made the labs and datasets available to download on the course website. Even as I posted them, though, I was reminded of one last problem facing the digital humanities: the problem of ephemerality. I spent hours and hours designing labs that will likely be unusable in a matter of years. Some of them require expensive software licenses, others rely on tools that could fall completely out of development. That’s one of the downside of labs. Ten years from now, I’ll still be able to re-use my lesson plan for discussing Roughing It. The lab on topic-modeling Twain and other novelists? Doubtful. But ephemerality is one of the necessary costs of teaching digital humanities. Because labs, and the broader pedagogical ethos of the digital humanities they embody, are ultimately worth it.