The content / interface abstraction

At a recent conference, I took part in a workshop for Urban Historians entitled “Workshop: Digital Projects from the Ground Up.” The basic structure was for two halves: first,  a conversation between “experts” on digital projects (me, Mitch Fraas from Penn, and Matt Shoemaker from Temple) and a small group of historians who were starting or considering starting digital projects; second, project-based consultations on each of the specific projects. In the opening question, we were asked about sustainability– how could these historians make sure their digital projects would be sustainable. I jumped in with my standard answer — I advocated separating content from interface in thinking and planning for a project. And I do think that’s the right way to go.  By thinking about the data that your project will produce, and planning for the long term preservation of that data, you can take more risks with interface, think more about the user experience without expecting that user experience now will be the same as user experience in 10 years (it won’t). The librarian in me wants content as flexible and sharable as possible. When we work on our own projects at Haverford, I am committed to making sure we work with systems that will allow us to export content, and to keeping track of which parts of a project will be saved and for how long, and to think separately about presentation.

However, as I look back on that conference session and the conversations we had, I struggle somewhat with the binary that I’m assuming and accepting in my endorsement of the content vs interface approach. Because the notion of Content as separate from (and in some ways, more important than) interface is not nearly so simple. Interface, context and design constitute meaning together, and this idealized “content” I’m advocating for the preservation of embeds a whole system of meaning. It is never and should not be construed as information devoid of subjectivity. By thinking of the project as a set of csv or xml or json or txt files alongside some javascript and bells and whistles, I want to attend to ways that I might be fetishizing “data” at the expense of more important meaning.  I want to make sure that I’m not pretending that the information/content/data is objective, or that by insisting on its re-usability, I’m not ignoring the ways that the system that produced it is full of meaning. As Kate Crawford, Kate Miltner, and Mary Gray  put it

“In an “informatics of domination” that gathers all the data it can to unlock some presumed or as-yet-unknown value down the road, data generation and collection are equated with innovation and scientific breakthroughs.”

Critiquing Big Data: Politics, Ethics, Epistemology, International Journal of Communication 8 (2014), 1663–1672

Ideally, each digital project should be conceived as a whole project where the meaning is built from the intersections of content, experience, design, interface etc.  The argument made in the experience and the data aren’t separable. What does it mean to preserve this notional content as csv, json, or xml when we know that, in every case, the interface matters.

One could struggle with these battling impulses. Lucky for me, my sister reminds me that action = compromise, and that is ok. There are so many seemingly unacceptable compromises implicit in action. I don’t want to engage in this positivistic approach to “data” as abstracted and divorced from meaning. And yet, there I am (here I am) advocating for starting a project with an awareness of which parts of the meaning you hope to construct should be considered “data” or “content” and which parts should be considered “interface”. Plans must be made. And data and content can be re-used, re-imagined, and exported. They should be stored in repositories. For interfaces, we make different plans. Interfaces can be preserved for some length of time, but at this point in development, we probably assume that aspects of them will fade or degrade at some point. In practice, it’s not hard to do that abstracting. Figuring out which parts of a project are ‘data’ and which parts are interface is generally really easy and valuable. It’s just a little dangerous. And that danger is worth paying attention to.

And of course, these are  all thoughts people have had before. But, each new project requires the same work of compromise, the same action.

I’m sure I will continue advocating for the thoughtful separation of content and interface, as I did at the presentation last week. Because it’s the right way to go (of course, on my own projects, we try to save both for as long as it makes sense to do that, but still.) And I suppose that’s the cost of building things.