Digital Humanities as Thunderdome

Elijah Meeks

Recently at a workshop on digital tools for the humanities, a Stanford graduate student rather poignantly noted that oftentimes collaboration with computer scientists felt more like colonization by computer scientists. This statement, even if not true, is far too sharp to ignore. Frankly, I think it is true. Not long after that workshop, I attended a THATCamp, where I spent my time teaching folks how to use Gephi, and I tried to spend some time telling them that the network they create is the result of an interpretive act. I don’t think they cared, I think they just wanted to know how to make node sizes change dynamically in tandem with partition filters. This is an issue that has concerned me for some time: the way wholesale importation of digital tools, techniques and objects into humanities scholarship tends to foster a situation where rich, sophisticated problems are contracted to fit conveniently into software.

I love Gephi; that’s obvious, but it isn’t built for humanists, because nothing is truly built for humanists; the closest we can get is something built by humanists. At their core, the systems, protocols and logical framework that are our digital world are created by and for a very pragmatic minority of our society. Engineers and scientists, by and large, do not problematize the “best practices” developed over a long and successful period of creating digital tools and objects for design, medical care, advertising, manufacturing, and so on. Yet the very languages, standards and applications that are used for digital humanities scholarship are a result of various collaborations between engineers and their professional clients. Add to this the fact that there is little in the way of domain specialization in the field of humanities scholarship among software engineers, and you end up with a situation I once described as trying to use a satellite built for mapping elevation to instead map culture.

Gephi is not built by humanities scholars, nor is it built for humanities scholars, and as such it has core logic that requires subversion in order to represent complex and uncertain digital humanities arguments. I point to Gephi because I use it all the time, and I know the people who code it, and I’ve written some code to extend it, but this is a fundamental fact not only of all software that wasn’t written specifically for a scholarly humanities audience, but for all software itself, which is still embedded in the pragmatic, engineering mindset from which it was born. Johanna Drucker suggests that scholarly objects born of this process lack “many humanities principles developed in hard-fought critical battles of the last decades,” offering her “short list”:

the subjectivity of interpretation, theoretical conceptions of texts as events (not things), cross-cultural perspectives that reveal the ideological workings of power, recognition of the fundamentally social nature of knowledge production, an intersubjective, mediated model of knowledge as something constituted, not just transmitted. For too long, the digital humanities, the advanced research arm of humanistic scholarly dialogue with computational methods, has taken its rules and cues from digital exigencies.^[1]

There are groups who have more experience with adapting digital tools and objects to their work than digital humanists, though I don’t think they are the answer. Archaeology, for example,  is traditionally pretty pragmatic in its use of technology, and museums and business are oriented toward a different audience than humanities scholarship at a Research 1 university. The digital humanities “segment of the market” doesn’t, as yet, have a corresponding set of domain specialists in computer science to help fashion UI/UX, data modeling and requirements for proper digital humanities scholarship and I really don’t think we ever will–there simply isn’t the market for it; the work is too sophisticated, specialized and absurd. The best we can do, if we go the traditional route, is to latch on to best practices from journalism, or public humanities like museums and library science. All of these, I think, carry with them the problems of authorial bias toward simplifying scholarly humanities problems.

The other option is to not touch the filthy digital, which would keep humanists clean but make them fundamentally divorced from the modern world. A third path is for humanities scholars themselves to pick up coding, write weird and not-at-all pragmatic software and, perhaps, create standards through practice or, more likely, just create lots and lots and lots of weird code that better describes queer black artists in the twenties or a republic of letters or Walt Whitman or James Joyce or Søren Kierkegaarde.

Regardless, the first step is awareness of what a tool or method is doing and how it will inflect your research. I’m concerned that humanities scholars show a willingness to defer to tools, but I’m more concerned that they may simply surrender to tool builders. When I got to Stanford, I felt superior to long-tenured faculty members because I knew how to code and they didn’t, and this circumstance was reinforced by the fact that they had to ask me whether something was possible. That’s a horrible burden to put on a young scholar or alt-ac type like me. It’s quite the temptation to answer questions like those as if I really knew all the possibilities of digital representation of humanistic inquiry. Because, really, the answer I’d give is only based on my limited coding skills and my even-more-limited understanding of the domain of the scholar I’m supporting.

What makes this doubly dangerous is that the sense of power and authority afforded in this situation is a useful tonic for the lack of official respect accorded to alt-ac staff members who work with faculty in Research 1 universities. I’ve tried, I hope with some success, to actively combat it by engaging my faculty collaborators in the nitty-gritty details of the logical systems that are being put in place to translate their work into the digital realm, all the while foregrounding the fact that, like any act of translation, it is interpretive and limited. I now playfully mock and goad humanities scholars when they claim to be incapable of understanding models and code, because I want to put an end to this dance being done to show some level of respect for, but also a willingness not to intrude on as well as a separation from, the domain of the tech support.

As my work has involved ever more input from humanities scholars on the most fundamental functions of the models and interfaces that they create, I have become far more aware of the years of work that scholars have put into truly understanding their fields. My knowledge of how to code does not necessarily overcome my relative inexperience in the understanding of or engagement with humanities scholarship. However, this isn’t meant to be some kind of self-abasing paean to the great and glorious tenured humanities faculty – if they want to do sophisticated digital humanities work they’ll need to learn how code works, if not actively become coders.

As it stands, it is all too common that a respected scholar with years of experience in their subject matter is constrained by a masters student in computer science who, in the best of cases, is a charitable ally with little knowledge of the domain and its many, thorny issues.^[2] This situation is much like that found in the classic film Mad Max: Beyond Thunderdome. For those not familiar with this particular artistic work, its title comes from an arena where “two men enter, one man leaves.” I think we’re replaying that moment over and over again in the digital humanities, with pragmatic, clean, idealized, “best practices” on one side and the queer, messy, uncertain and post-modern on the other. It’s not nearly as good an analogy as Cecire’s Harlem Renaissance, I know, but it has the benefit of being available via BitTorrent and YouTube. It isn’t really a gladiatorial death match between computer scientists and humanities scholars, though, because the two combatants are much more primal than that–a poeisis (poetic, emergent, and contingent) form of knowledge expression to struggle with the techne (technical, crafted, or objective). It’s about transitioning the representation of humanities knowledge out of text and into the digital without transforming it into a simplified version.

Success is a pragmatic ideal, but in this case I’m willing to employ it in an attempt to transition from defining the digital humanities into defining success for the digital humanities. I see it as creating a humanities that is not as simplistic and flat and technical as that envisioned by engineers and computer scientists, but as rich and sophisticated and poetic as that described in our libraries and seminar rooms and long discourses. The liminal quality of the narrative text format that we’ve used to present humanities knowledge is something to foster and integrate into a successful scholarly digital object, and not something that needs to be stamped out because it does not fit into the patterns of data management and manipulations established by the early adopters of digital tools, objects and methods. And I need to be clear, it’s not something we should maintain because it is a cultural artifact, but because it allows for a more accurate, if less precise, representation of human experience.

 

Originally published by Elijah Meeks on November 5, 2011. Revised March 2012.

1. ^[1]Johanna Drucker, “Blind Spots,” The Chronicle of Higher Education (April 3, 2009): B6.↩
2. ^[2]I think Molly Des Jardin provides a telling perspective on the view of the humanities among early-career computer scientists.↩