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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s