Theory, Digital Humanities, and Noticing

Patrick Murray-John

When disciplines collide, as they do throughout digital humanities, the various practitioners mutually benefit from the different knowledge and skill sets that others bring to our collaborations. But there is also an inevitable gap between how different individuals working in different areas understand their various tools and techniques, and in how they understand their own thought processes. For THATCamp and digital humanities, that causes two related tensions as programmers and critics move more closely together in their joint work. The first tension is the relationship between “hack” and “yack” in the phrase often heard at THATCamp: “more hack; less yack.” The second is the broader question of the role of theory in digital humanities — its perceived absence among some and what steps can be taken to recognize what others call theory in digital humanities. Those tensions, though, will be easily resolved by addressing the disjunction between what coders know to look for as being important and what critics look for in their work to develop theory. In short, the two groups do not yet know what the other notices (in text or in code) as the first step toward understanding their work.

The prominence of hacking and building things — specifically through digital tools — led to a perception that the THATCamp workshops represent a colonizing of the humanities by computer science. I would argue, however, that it is really the reverse, that the workshops are more about the humanities pushing into computer science. Not necessarily at the institutional level, but rather at the level of practices from the humanities influencing the way programmers and web developers approach their work. Many of the principles of writing code seem antithetical to much of how the humanities works. Coders like to keep things simple. We like to produce the most efficient algorithms, with very well-defined inputs and outputs. Especially with test-driven development, the code we write should have very precisely-defined functionality and purposes, and once written shouldn’t change (or break).

Roughly, that’s good coding, and good project management. Breaking those principles leads to scope creep, and to not getting projects done. A plugin for Omeka that I started years ago is still unfinished because each time I built a new piece of functionality I noticed that it could be expanded upon to produce new, more interesting results. Parts of the input (RSS/Atom feeds) could be interpreted in a variety of ways, and so I wrote code to make the various meanings explicit. There are assumptions and ambiguities built into the input formats that I wanted to unpack and explicate for the user.

“Expand upon,” “make various meanings explicit,” “unpack and explicate.” These are the words of a dissertation writer. I was writing code like I was writing my dissertation, which led to what a computer scientist or project manager would call scope creep. Yet I think that that kind of unpacking and examination can ultimately benefit a project. Bringing the questions that humanists tend to ask into the process of writing code can help us identify why we are writing the code in the first place and help us recognize what promising directions or ideas are available. Or, at least, it can help us be aware of the implications of the choices we make at the level of code, and what ramifications they will have in where the final project might stand culturally. That is, thinking patterns familiar to humanists are making their way explicitly into the process of writing code and building sites and applications. That is a helpful outcome of THATCamp workshops, even though, as I found, there is a danger of it interfering with the successful completion of a project.

That’s why I’m so impressed with Jean Bauer’s ability to build awesome things, with theory and the humanities in mind, and actually, you know, finish them.

But I’m not terribly surprised by the reaction that she describes in “Who You Calling Untheoretical?,” of people asking, “But where’s the theory?” I’m not surprised, because, in general, I don’t think theorists know what to notice yet. Our graduate programs are naturally still dominated by fairly traditional “texts,” and theory rooted in them. And our theory has done a good job of complicating various notions of “text” (note to non-humanist coders: complicating ideas is a good and productive thing to theorists). Whatever our theoretical approach to whatever we are calling a text, we know what to notice in them. That’s what much of our grad school training in theory is about — what do we need to notice in the text, and how does our theory help us describe what we have noticed?

This is not surprising either, because unlike any of the various theoretical notions of text floating around, most people don’t have an experiential grounding in database as text or API as text. One doesn’t need to be a poet to do literary criticism on poetry, though the poet and critic will share a common knowledge base. But (unless you are a medievalist or classicist or doing comparative literature) you don’t need any special training to be able to begin noticing things in the text. There is a base line of experience with reading and discerning meaning that you can start with.

Imagine farther back to an introductory course in literature or in writing. These courses have a goal of teaching students to be more aware of the texts that they read and write. That training often starts with skills at close reading, which works well because we can guide students to noticing patterns in the text by starting with what is already accessible to them: the basic meanings of words they already know and use (but usually in an unreflective way). Noticing can start at the easily accessible moment of observing a word’s meaning. We can start training up our reading skills because we don’t need to be taught the basic meanings first. From there, we bring in complications in an effort to show that the first, most accessible basic meaning is not the end of the story. We encounter the question, “Why can’t I just read for fun?” exactly when students begin to move beyond that easiest, immediately accessible meaning and begin to make what they first perceive as the obvious meaning more complicated. But it starts with helping them to notice the meaning they immediately saw, without the additional training.

Of course, different techniques of noticing become more important as we continue our training. Developing skills of noticing in Toni Morrison and in Beowulf require building upon more sophisticated techniques of noticing. As we train up, the required knowledge and skills diverge by discipline and subdiscipline until many of our core skills are mutually inaccessible.

I see a very different trajectory in the digital world. A good user interface is designed specifically so that you don’t have to deal with the inner workings of the application. In general, people should not see the internal structures of an application — the database, the public and private methods in the core code. Unlike our, or our students’, first experiences with reading in more interesting and complicated ways, the first starting point — the language — is specifically (and, in closed-source applications, legally) hidden away from us. And so, there is no ability to even begin noticing what’s notable.

This is where crit-code studies seems promising. There might be strong analogies to crit-code training and methods and comparative literature, but that’s something for someone more knowledgeable about both of them to figure out.

As digital humanities begins to tackle what theory is and does in our discipline, we are in the interesting position of disciplinary convergence, rather than the divergence that typically characterizes our training. In broad strokes, training in the humanities begins with noticing the immediate meaning of a word or phrase in our early undergraduate courses, then, through graduate school and publications, learning how to unpack and explicate meaning with increasingly complex methodologies, each of which depend on different skills and techniques of noticing.

With the collision of the worlds of computer science and humanities in current digital humanities, we have a situation that calls for a confluence of noticing skills from different specialization that are in new kinds of conversations. To computer scientists, code will be accessible in a way that it is not to humanists without familiarity with programming languages. They will have a basic ability to start noticing things analogous to the basic ability to start noticing that our intro-level humanities students have. Instead of reading it for fun, they will want to read it for efficiency or for good application design. The humanists unfamiliar with code won’t have that opening ability to start noticing, but once they do, they will have important things to say about what is implicit in the code and what needs to be explicated, and not just for fun or efficiency.

I’m not sure I’d go so far as to say that to do theory in/on digital humanities one needs to learn to code or design a database. But one does need some training to be able to start noticing the difference between two data models that at surface appear to describe the same things. And, coders should be ready to learn what useful things theorists can offer that, despite a first appearance of scope creep, might just be valuable things to consider building into the code.

As a concrete example, I sometimes fret over the centrality of the item in Omeka. An “item” is the fundamental unit of information, and we have lots of ways to describe them with metadata, mostly Dublin Core. But “items” can become complicated very quickly. Some of my fellow colleagues at the Roy Rosenzweig Center for History and New Media are struggling with how to put scrapbooks into Omeka. Is the scrapbook the item, or is each individual thing in the scrapbook an item? Where do pages in the scrapbook fit in? I’m guessing that there is theory that could be useful here, and could lead to an Omeka plugin that is designed to implement a theoretical approach to scrapbooks that lets us work with a more complex notion of “item” in our data model. I need some theory to help me notice things about scrapbooks, and to help me notice things about Omeka’s notion of “item.”

Producing a plugin that complicates Omeka’s model of “item” by consciously building theory into the code would be a great code hack in harmony with theory yack.

 

Originally published by Patrick Murray-John on November 10, 2011. Revised March 2012.

---

The original blog post that developed into this piece was primarily a response to Natalia Cecire’s “When DH Was In Vogue; or, THATCamp Theory“, Jean Bauer’s “Who You Calling Untheoretical?“, and the resulting comments and twitter conversations.

Many thanks to PressForward, and especially to Natalia Cecire, for their help in developing this from the original post into its current form.