This Graph is my Graph, this Graph is your Graph

There is no better way to acknowledge that you are an academic or digital humanities arrival than finding yourself on the receiving end of a class act hatchet job on your work. This year at DH2014 Stefan Jänicke, Annette Geßner, Marco Büchler, and Gerik Scheuermann of Leipzig University’s Image and Signal processing group and Göttingen’s DH Center presented a paper firmly criticizing the graph layout that CollateX and StemmaWeb apply. Tara Andrews (who is responsible for the programming that makes the backend kick) and I presented some work on graph interactivity for StemmaWeb at DH2013. We have been working on the graph representation and interactivity because it is fun and pretty cool—a primary but often overlooked motivator of much DH work as Melissa Terras pointed out at her DHBenelux keynote. The academically more serious part is in the interaction between scholars and text. That is for me in any case, for Andrews it is the stemmatological component. I want to know how tools and interfaces either or not support scholar-text interaction. Hint: GUIs do more bad than good. Mostly I want to know how they–and the code that makes them tick–affects scholarly interpretation. Not many may know this, but I am the one that programmed the graph visualization and interaction in StemmaWeb. So I guess I am entitled to say one or two things on the work of Jänicke et al.

Let me first of all point out that I think their work is a very welcome and timely addition to the thinking and practice of graph interactivity. Not much work has been done on how graphs can be read as an aggregative representation of witness texts. Yet that work is essential in that it pertains to how scholars perceive their material. So the more, the merrier—which in general is my attitude anyway I believe. Above and beyond that, it is great to learn that someone is working on an actually JavaScript library for this type of scholarly lay out. I think Ronald Dekker, who works on CollateX, is already compiling the needed information to actually allow TRAViz to interoperate with CollateX.

So far the good. Now for the bad and the puzzling. Jänicke et al. argue for a number of design rules. Some of these make sense to me, like “Bundle major edges!”. In fact in StemmaWeb we wanted to have weighted edges, we… just didn’t get around to it first time round. Apparently this feature now present (the edge width is a function of the number of witnesses) wasn’t there yet when Jänicke et al. checked. The thing is, all the work was done in our copious free time, so weighted edges took a little longer. That takes me to the first puzzling. It took two computer scientists and two digital humanists to pull off the creation of a set of rules? The StemmaWeb graph visualization and interactivity components came around a little more economically, and with less ceremony in any case. The good part is that apparently there is much programming capacity around. It cannot be stressed enough how valuable it is to have some computing effort going into creating and maintaining a reusable code library specific to this type of visualization. We built the graph interactivity on top of the standard GraphViz layout engine that is based on a number of default graph design principles. The abstracting of that graph interaction and decoupling it as a separate library from the specifics of StemmaWeb logic has been a long standing wish for us, but given our primary research concerns we never got around to that. This summer we are trying again. Unfortunately I have a suspicion that again other academic and not so academic stuff will get in the way. And oh, did I point out we really seriously value collaboration?

Other rules really do not make sense to me. Not labeling edges? Why not, it is pretty essential mostly to scholars to know what witnesses coincide. Color coding that? We tried, it doesn’t work beyond seven witnesses, that’s when you run out of the colors of the rainbow, and humans are very bad at distinguishing shades of green. Thus color coding is limited, and above that it hides actual information. Abolish backward edges because of cognitive load? Reading James Joyce is a cognitive load, not following a backward edge. But going along for the purpose of it: how do Jänicke et al. treat transpositions in that case? “Rule 5: insert line breaks!” Again that exclamation mark. “Why shouldn’t we adopt the behavior of a text flowing in a book (with line breaks) for Text Variant Graphs?” Well, because it is not a book, and I am interested in new ways of reading. That is my take, but there’s no reason why we could not differ of opinion by good argument.

That takes me to the core of what I find unhelpful about this set of rules. They are hammered out in the style of god given dogmas. Even if this rule set has empirical user studies and design principles underpinning it, the dogmatism is still unpalatable. Especially the “line breaks” rule seems to suggest that print paradigm was heavily over represented in the user survey. The point is that if you ask users from the print paradigm what they want and what they like, chances are you will end up with a digital mimesis of print paradigm. I don’t mind if you want to get what you got by doing what you did, but raising that to absolute rule is not very explorative to say the least. What Jänicke et al. fail to appreciate is the digital humanities and human computer interaction potential here for experimenting with design choices and learning how they affect our reading, use, and interpretation of variant text representation. Instead they boilerplate a number of rules mostly based on print paradigm assumptions. And again: why does this need to be in this forbidding shouting of dogmatic rules? Will I be shot the next time I violate them for the sake of experimentation? I like the remarks they make on iterative approach. We have been reading the Agile Manifesto since 2001, and we fully embraced evolutionary development. But this goes for rules too: they are there to be iteratively questioned and purposely broken for the sake of progressing our knowledge.

For years there has been a quote under my email signature, which kind of says it all: “Jack Sparrow: I thought you were supposed to keep to the code. Mr. Gibbs: We figured they were more actual guidelines.”