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.
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.