Archives
Author Archive
June 24, 2013
Hacking and Engineering: Notes from DHSI
A few weeks ago, at DHSI, I was giving a demo of a prototype I had built and talking to a class on versioning about TEI, standoff markup and the place of building in scholarship. Someone in the audience said I seemed to exhibit a kind of hacker ethos and asked what I thought about that idea. My on-the-spot answer dealt with standards and the solidity of TEI, but I thought I might use this space to take another approach to that question.
The “more hack less yack” line that runs through digital humanities discussions seems to often stand in for the perceived division between practice and theory, with those scholars who would have more of the latter arguing that DH doesn’t do cultural (among other forms of) criticism. That’s certainly a worthwhile discussion, but what of the division, among those who are making, between those who hack and those who do something else?
I take hacker to connote a kind of flexibility, especially in regards to tools and methods, coupled with a self-reliance that rejects larger, and potentially more stable, organizations. Zines. The command line. Looking over someone’s shoulder to steal a PIN. Knowing a hundred little tricks that can be put together in different ways. There’s also this little graphic that’s been going around recently (and a version that’s a bit more fun) that puts hacking skills in the context of subject expertise and stats knowledge. Here, what’s largely being talked about is the ability to munge some data together into the proper format or to maybe run a few lines of Python.
This kind of making might be contrasted with engineering—Claude Lévi-Strauss has already drawn the distinction between the bricoleur and the engineer, and I think it might roughly hold for the hacker as well. In short, the bricoleur works with what she has at hand, puts materials (and methods?) together in new ways. The engineer sees all (or more) possibilities and can work toward a more optimal solution.
Both the bricoleur and the engineer are present in digital humanities work. The pedagogical benefits of having to work with imperfect materials are cited, and many projects do tend to have the improvised quality of the bricoleur—or the hacker described above. But many other projects optimize. Standards like the TEI, I would argue, survey what is possible and then attempt to create an optimal solution. Similarly, applications and systems, once they reach a certain size, drive developers to ask not what do I know that might solve this problem but what exists that I could learn in order to best solve this problem.
My point here has little to do with either of these modes of building. It’s just that the term “hack” seems to get simplified sometimes in a way that might hide useful distinctions. Digital humanists do a lot of different things when they build, and the rhetorical pressure on building to this point seems to have perhaps shifted attention away from those differences. For scholars interested in the epistemological and pedagogical aspects of practice, I think these differences might be productive sites for future work.
November 11, 2012
Interface Design and the Modernist Versions Project
My name is Daniel Carter, and I’m a PhD student in Information Studies at the University of Texas at Austin. I’m currently working with Dr. Tanya Clement on the Modernist Versions Project and wanted to write briefly about what we’ve been thinking about in relation to digital editions and collation.
My role in the Modernist Versions Project is currently to think about the design of tools used for collation and of the interfaces that are used to display versioned texts. My background is in Modernist literature (MA from The Ohio State University) and web development and design—so this is work that’s more than a little in line with my interests.
At the moment, I’m working on reviewing existing tools for collating texts and for presenting TEI-encoded versions. I’m also working on prototypes for interfaces that would allow users to more easily view and annotate multiple versions of texts. Screenshots of (very early) progress are included below.
Related to this work is an attempt to think about how design methods function (and don’t) in a humanities project. In this, I follow Stan Ruecker and Alan Galey in arguing that design “operate[s] in the messy middle ground between interpretation and making, and … can contribute to a theoretical framework for new questions facing humanists” [1]. On one hand, I think this line of thought encourages us to consider the ways the interfaces that we currently work with are structuring our relations to and conceptions of things like texts, editions, collections, etc. On the other hand, it gives us license to imagine new ways of working with text.
This “messy middle ground” is a place where the multiple theoretical positions that the humanities promotes can mix it up with the considerations of real users and technologies that an information school focuses on. It’s a fun area to be working in, and I’m looking forward to sharing more of our work as prototypes and sketches work their way toward, well, probably more prototypes and sketches. I’m grateful for EMiC’s support, and I look forward to meeting many of you this summer in Victoria.
—–
The version of “Ancestry” shown above is borrowed from Tanya Clement’s In Transition: Selected Poems by the Baroness Elsa von Freytag-Loringhoven.
1. Galey, Alan, and Stan Ruecker. “How a Prototype Argues.” Literary and Linguistic Computing 25.4 (2010): 405–424.