There’s a lot of talk in Digital Humanities about “born digital” content. But what we are really talking about at this point is different kinds of digital, and the politics of competing standards.
My project for this institute is to create a digital companion for my mp3 book. The purpose of the site is to present some core concepts from the book in alternative form, and in some cases to audify them with sonic examples that would be impossible to provide in print. And if we can get the scripts right, to do some fun things with the web. This, of course, involves porting some of the book’s prose into an online environment and reworking it for the more modular form of the web.
Here we run into a standards and path dependency problem (the very two concepts for which I was starting to build pages today): the writing platforms on a computer aren’t truly interoperable. For my entire academic career, I’ve used word processors. By any measure, all of my scholarship has been “born digital” — but the kind of digital matters. I wrote MP3 in Microsoft Word. Microsoft Word has some kind of insane text encoding that makes it impossible to paste formatted text into a WYSIWYG editor. Pasting it as plain text into an html window works, but then there’s the process of marking it up.
At the same time, the platform we’re working on, Scalar, is new to me and under development at the same time. This is an unavoidable situation — and Scalar has many advantages over WordPress. It’s brilliance comes from the lack of presupposed hierarchy that one finds in WordPress, and also the ability to mark up the media one comments upon in real time. I can immediately see advantages. Concepts that show up across chapters in the book can be directly linked via tags in the web version. But at the same time, it means that every time I can’t get it to work the way I want, I have to figure out if it’s simply a matter of learning a new workflow (“user error”), whether I don’t get what they’re trying to do (“it’s not a bug, it’s a feature”) or whether the software needs further development (which is why we’re here).
For instance, right now footnotes (which I looove) are a somewhat laborious process. You have to decide how you want to tag or indicate them — for now I’m following Alex Juhasz’s approach and using a superscripted “[cit]” — then format that indication, then write the note, then return to the document I was working on. I’m hoping I can convince the designers to set up a script to do this more efficiently.
Writing in the digital humanities is like that. Part of the issue is the lack of existing interoperable standards between different writing platforms. And I’d love to say that open standards would be the solution–I am a believer in the gospel of open source and open access–but the reality is that you also need interoperability, and sometimes proprietary formats exert path-dependence effects: MS Word and Adobe’s .pdf format are great examples of that. Just try being an academic and refusing to use those two standards.
Part of the issue is that you are creating the tool as you’re using it, and making up the conventions as you go along. The frustrating part is something electronic musicians know very well: when you’re learning the interface, you’re not making music.