Rehabbing DH101

I’m teaching Introduction to Digital Humanities for the third time this year, along with Francesca Albrezzi, my wonderful two-time teaching assistant, and I’m really enjoying it. It’s a challenging but rewarding class, with 45 students, a 10-week quarter, and a large number of moving parts. I reworked the syllabus quite a bit for this iteration, and I thought it might be useful to talk about what I’ve done differently and why.

As I’ve taught through the class a few times, its purpose and value have become more clear to me. My version of DH101 is about developing a humanistic attitude toward data. To me, that means the ability to hold in one’s mind simultaneously the value of any particular dataset and its inevitable poverty, compared with the phenomena it purports to describe. I want students to be able to “work” with data — that is, to analyze, visualize, and map it — but also to retain a perpetually critical, interrogative stance toward it.

In the service of this goal, I’ve completely rewritten the students’ final project assignment. The previous assignment, which I first inherited and then adapted, was for students to work in groups to build Omeka projects on topics of their choice. This had the benefit of exposing them to the demands and complexity of Dublin Core metadata, but I felt that the students were spending too much time describing objects and not enough time working directly with data. Since Omeka has no real export function, they weren’t able to do much with the metadata they were creating, besides build exhibits.

I also have a lot of students in my DH101 class who are not humanities majors, and I’ve discovered that asking students who’ve come from other fields to pick a topic, develop a research question, and learn a completely new set of methodologies was just too much. So this time around, I pre-selected eight datasets, which I’ve distributed to eight groups of students in the form of “project capsules.” The capsules contain the actual datasets (as CSV files), but also information about their provenance, links to more information, the name of an expert who’s agreed to be interviewed on the subject, a couple of books to start their research, and the appropriate librarians to ask for research help. (I allowed students to register their first, second, and third choices for datasets, but reserved the right to assign anything, with an extra two points awarded to any group that doesn’t get one of its top choices).

The projects, once they’re completed, will contain written narratives, data visualizations, maps, and a timeline, all on a server the students administer themselves. They’ll also contain “data critiques,” annotated bibliographies, and well-documented About pages. The students got their datasets a couple weeks ago, and while I certainly felt anxiety in the room (the vast majority of my students are very new to digital work), I’ve promised them that we won’t ask them to do anything we don’t actually teach them to do.

My original idea was that students would work with metadata drawn directly from UCLA Special Collections, which would allow them to compare data about objects with the objects themselves. The Digital Library and I couldn’t quite coordinate our schedules this year, but we’re set to go for next year, having arrived at a good workflow for exporting library metadata as CSVs. So far I feel good about this assignment, although I do feel it’s quite challenging for students. Last Friday, Francesca and I showed the students how to use OpenRefine to clean their data, and it was heartening to hear students having exactly the kinds of conversations I’d hoped they’d have: about whether to discard data complexity in favor of legibility, for example, or whether they should iron out misspellings or leave them in the data. These kinds of conversations get students a lot closer to the thoughtful, discerning orientation toward data I’d like to foster. Some other important changes we’ve made this year:

• Rather than allowing students to choose their own groups, as we have in previous years, we’ve assigned them to groups of similar skill levels (as measured by a technical self-assessment). Experience has taught us that in groups of varying technical abilities, the technical work tends to gravitate to the more experienced students, just out of convenience and efficiency. We want students to push each other and work together.
• We’ve asked students to assign roles from a defined list. This both helps students allocate work and allows us to convene groups of “specialists” from time to time. For example, we can call all the web specialists together to share information, which they then impart to the rest of their groups.
• We’re allowing students to choose their own content-management systems (or flat HTML files, if they wish), which each group administers through a cPanel-fronted VPS, jointly purchased from Reclaim Hosting. This will, we hope, demystify the process of getting a document from one’s computer to the internet. As in years past, the students themselves will decide whether to maintain the projects or let them lapse. Meanwhile, we’ll archive static versions of the sites on UCLA servers (using HTTrack), so that the students will always have a record of what they’ve done.
• Lots of large and small changes to the reading list, as well as changes to the timing of lectures and lab, so that the topics we cover align more closely to students’ project work.