Making Poetry Digital: Laying Foundations and Pondering Process

I’m currently involved in a handful of DH projects right now, so there’s a lot to talk about, but one of them I’m particularly interested and really¬† excited to introduce you to…

This year, I have had the privilege of working with Dr. Karis Shearer at the University of British Columbia Okanagan on creating what is essentially the foundation for what will hopefully be a unique and rich digital poetry archive, which we currently call “POSA”. Right now, it’s an archive that mainly focuses on Western Canadian poets, but we have an eye to expand our scope to much wider reaches. The archive will contain the standard biographical information for authors and links to downloadable audio material that we have, but we are working on visualizations of that audio data in such a way that it makes end-users view and think about their poetry in a slightly different way than they might be used to — almost as a pedagogical tool in a way. Right now the scope extends primarily to a web-based interface, but there are lots of ideas about other mediums which we can tap for the project.

I am quite unhelpful with the details of that I know; the major reason being that, in general, we are still working out the finer details and approaches to all of the major site components and how they will work. And, there’s not much I can say in the way of the general stuff until we get further along.

But, what I will focus on is a bit of the thought process that has guided me thus far, and perhaps it might be some useful insight. So, in a way, this is more of a reflective “meta-DH” post than a post of my literal day-to-day work.

In the case you are not already familiar, I am a freelance web developer who has a love for media-centric interfaces. I have worked with sites before that needed to address issues of data architecture, or user-friendly interfacing with some other data store, but this poetry archive allowed me to focus on those two components together and give me a really fun challenge.

The central question we ask of of course is what poetry looks like off the page? How do we represent it?

There’s a lot more to answering that question than simply interface designs and things like skeumorphism and media players which have cool little buttons/features, but it is certainly a key part in translating poetry to a relatively foreign realm. It is taking poetry into a medium which isn’t static, but one which is dynamic and has all sorts of possible ways of being read, extracted, and manipulated.

A major part of my work (though not my sole role by any means) for our project focuses on designing the interface elements and acting as an “architect” of sorts; I get to figure what sorts of web tools we can use (and build) to achieve our ultimate goals, and then try and coalesce them into whatever code foundation we write on it to make it all work beautifully.

But there’s a lot of technical considerations that go on as well, and in the rest of the post, I’ll cover two of the biggest things I’ve been learning about and tackling in my relatively new “DH career”…

Utilizing New Technologies — and Grafting Old Ones

If you’re developing a modern web interface that utilizes media in any interactive fashion — especially audio — then Flash in almost all respects is very much a dead product on life support. Adobe by their own admission has pushed for HTML5 as part of their strategy for moving forward, and from a performance perspective, it’s still quite a resource hog. It’s also not friendly to team-oriented projects such as this, which needs to keep components as “decoupled” as possible. In other words, no part of the site should be a highly-specialized and boxed-in part that exists and functions separately from the rest of the site. All parts of the site — whether its a simple page about a piece of audio, or the actual audio player — should have the ability to talk to each other and integrate with each other as simply as possible. That of course means that a common codebase is a necessary place to start.

On the flip side, majority support amongst web browsers for even most of the HTML5 spec is very inconsistent, with Internet Explorer of course being the laggard. Going with an all-or-nothing approach is quite dangerous, not just for the obvious reason of leaving a very significant and valuable chunk of your potential user base behind. To get around this, we have tools like various Pollyfills and SoundManager, for audio, which each have their own ways of “grafting” support for newer technologies onto older browser versions. And, in the case of SoundManager, if you happen to be using a browser which does not support the HTML5 audio specification, it can fall back to a Flash-based player when necessary, and still has the ability to “talk” to the browser and other DOM event listeners through its own set of “hooks“. For a front-end developer like me, this is absolutely fantastic to have at my disposal.

In the end, we want to build something that is rich, adaptable, and maintainable.

Building The Present With an Eye to the Future

It’s that last point which is of especial concern for me and my fellow project members, because the project is something that eventually will be passed into the hands of future developers, artists, and poetry aficionados alike that share the same passion and drive for what we are doing. And it’s a lot of work to just simply dump on people! Therefore, documentation, in both code, and in general work, is of great importance!

Maintainability is itself a multi-faceted term. It’s not just about making things “easier to change”, but it’s also about creating a platform which can remain relatively stable through many changes, especially ones that are quite drastic.

Coming back to the “easier to change” bit, maintainability means of course providing some facility for administrators to come in and add and change content without having to make such changes “manually” directly inside the working logic of the application (a.k.a. the code).

Maintainability also means that developers now and in the future will be able to extend and add additional features to the project in an efficient way and one which does not require other subsequent changes to another core part of the system, at least not without reason. In essence, for example, I should be able to update existing data-handling functions for a media player on a page in a way that it doesn’t affect how it will be rendered or interacted with.

Content Management Systems are a notorious love/hate relationship for me in this respect, because they fulfill one part of that maintainability “mantra”, but virtually none of the others. WordPress, Drupal, Joomla, and even lesser-known solutions like MODX, all fulfill the aspect of providing ways for people to easily “manage” content, but the technical implementation that’s abstracted away in all of that is one that essentially chains you down to doing everything “their way”. And that is something I completely understand — since they need some kind of convention or language to base themselves on so they can understand how to work with the user-generated content you give them.

However, what every CMS seems to fall miserably short on are the areas of custom metadata and data sharing, two areas, which I will admit are perhaps not pertinent to every project out there, and thus not something of high concern for such a broad-purpose tool like WordPress or Drupal.¬† However, these are facilities I think would be useful nonetheless, even if only a foundation was given that was easily extensible. Software like Omeka is a rare exception here that comes close by providing a refreshingly wonderful custom metadata definition builder, and it does have its own implementation of a REST API, but one that is substantially limited — unless your platform also runs on Omeka.

There are of course going to be questions and suggestions just to write a “wrapper” library or some script that translates the internal data structure to whatever is desired, but to do that right now is one rather involved (and often messy) hack job to do well, especially where semantics are of a concern. I’ll leave more of that for another post, but this is actually another project I’m actively researching and working on in hopes to close the “gap” between simply adding data, and being able to communicate about that data in a semantic and meaningful way, and being able to share it in such a way that it isn’t “bound” or “locked in” or “coupled” to a fixed piece of software.

And that’s the kind of things that I have tackled and continue to tackle and learn about on a daily basis as I work in the field of DH. Exhausting it is sometimes, sure, but it’s “work” that you enjoy losing track of time on and incrementally working on — at least, I do anyways.

The semester may be done for most people, but we are still hard at work, and there’s more to come! We hope to have a prototype of its design (though largely non-functional) this summer. I for one am really excited!