Digital Humanities: Defensive Design

Research and publishing the old fashion way might have been laborious and slow, but at least it was fairly robust. A scholar could produce  texts in journals and monographs, and not worry that the ink was going to become obsolete on the paper on which it was printed, or that the reader was going to have to upgrade their eyes in order be able to read your work in 5 years.

The brave new world of Digital Humanities is changing many things, including the representation and delivery of research and publishing, with many complicating factors. I offer here a few thoughts on considerations you might keep in mind as you design and implement your Digital Humanities project, in order that it might have as much staying power as possible — even if it won’t outlast the paper book or papyrus.

Mockups and User Testing

Get feedback from people – especially the kinds of people who will use your project – as much as possible, even before you have your first prototype running by sketching it on paper or by creating a minimally functioning skeleton. Here’s an interesting new design tool made for such a purpose.

Ask your test users:

  • Is it simple enough to figure out how to use this tool? You’re going to eliminate most of your users if people have to read a manual to figure it out.
  • Does it actually support the kinds of research questions or educational purposes for which you’d like to use it?
  • Is there some aspect of the content or context which your tool is not supporting but which users will expect?

The sooner you find out any limitations you’ve not anticipated, the easier it will be to address your shortcomings, even if just by leaving some design aspect open for extension later.

Use Secure Standards

You don’t want to develop your Digital Humanities project using a tool or vital piece of technology that is going to become obsolete quickly. Try to plan conservatively by leveraging standards as much as possible, which will mean consulting with software specialists who can give you an idea of what technologies are being embraced by a wide range of manufacturers or developers, and which are going the way of the dodo. Sometimes this is an arbitrary matter of industry rivalries and jealousies, but it could have a major impact on your investment.

Keep Your Data Retrievable

Digital Humanities projects typically require a huge investment in data collection, curation and collation, and it may be extremely expensive to lose that data, perhaps even impossible to get it again. Build into your system some way of getting the data back out of the system in a form where it can be easily inspected (by a human), backed up, and re-inserted into future projects.

For example, you might enable users (or perhaps only your system administrator) to download data in the form of XML files, CSV (comma-separated value) files, PDF files, RTF files, or JSON files. Again, the use of durable standard formats is important, as is keeping backups of your data!

Make Your Programmers Document Their Code

Some programmers are very resistant to documenting their code as they write it, insisting that it is so clearly written that it is self-documenting. This, unfortunately, is seldom the case for anybody but the original programmer and only within a short timespan of the original time of writing. Your programmer may leave you for greener pastures and leave a mess for your next programmer to figure out.

The “logic” for web-based applications can be very complex and spread over several different places. An application written in Grails and running on a web-server, for example, has logic spread across controller files, view files, GSP Templates, and JavaScript files. Where are the interdependencies between these sets of code documented? Where it is explained what parameters passed between different parts of the system, or the side effects produced or relied on by them?

Documenting code dependencies is also very important because a single web-app will likely rely upon a number of different technologies (jQuery in your browser-side user interface and a Hibernate plug-in in your web-server application, for example). The more of these are used, the more brittle this Rube Goldberg-like machine is going to become. A change in the code of one of them could cause the whole system to become useless. Document your assumptions, what versions of each tool worked for you, and what you did to fix incompatibilities when new versions were released.

Facilitating Digital Humanities Designs

In the last few weeks I’ve been working with Dr. Cece Conway of Appalachian State University on a digital humanities project she’s working on about the history of the banjo. She’s a scholar of Appalachian folklore who wants to make her research come alive in digital media and I’ve been helping her think through what that means in terms of data sets and user interfaces.

That led me to the question: What is the best set of questions that I could pose to a humanities scholar without any particular knowledge of computer technology to figure out what s/he is trying to do so that I design the best possible implementation in digital format?

There may well be a good discussion out there on this topic, or even a handbook for practitioners that covers this area of design. However, I came up with my own set of questions based on my own experience in software design and as a humanities scholar myself. Note that I try to stay away from specific technologies and implementations as much as possible and try to focus on the high-level goals and resources.

This is the list of questions that seem useful to me, as a starting point for discussions, but perhaps others can suggest improvements, refinements, or additions. I hope that others might find this set of questions of use as well if they are trying to facilitate humanities scholars to go digital.

(1) What is the goal and purpose of your project (from a high-level perspective)?

(2) Does your project have pedagogical goals or methods?

(3) Who is your target audience?

(4) What are your data assets? In what media or digital formats are they?

(5) What are the relationships between these assets?  Are they grouped logically in some way?

(6) What should the user experience “feel like”? How should information be conveyed? How should the user navigate through the information space or interact with the system generally?

(7) How will the user experience meet the goal and pedagogical methods of your project?

(8) What examples do you have of other similar projects (on the internet or otherwise)? How do these differ from what you’d like to do? What aspects of these examples do you think are successful or unsuccessful, and why?

(9) Are there any further considerations for the design or implementation of your project?