on archiving digital products

Khoi Vinh’s post on An Archive for Interaction Design is worth reading. Vinh argues that…

Every time a site or an application gets a major upgrade, every time an interface is overhauled, it represents something learned, knowledge accrued to advance the craft. But we won’t benefit easily from these revelations if we don’t do the hard work of archiving these steps forward.

It’s hard to argue with that. The business and craft of digial interface design should be learning from its past, even when that past is as recent as last year or last month. The Internet Archive, god bless it, is necessary but not sufficient. It was built for a page-centric web, which makes it useful for nostalgic geezers like me, but it doesn’t archive embedded media, and it wasn’t designed to replicate the rich, hashbanging applications of today’s web.

Some archiving approaches have touted virtualization as a savior — we can archive more complete software experiences by snapshotting the environments they run in, and then running them inside today’s (and tomorrow’s) machines. Which is theoretically interesting, but today’s digital products don’t live in a hermetically sealed virtualizable bubble.

Take an article from The Huffington Post, for example. Regardless of whether you think that it’s an example of good interaction design, there would be no practical way to recreate the experience of that page ten years, ten months or even ten days from now. That page is part of an interlinked set of systems — real time article recommendations, social tools, ad servers dynamically targeting flights of campaigns, etc. — all of which would be impossible to capture, virtualize and maintain. Are you going to keep an entire copy of Facebook running? Twitter? Ad servers? Article recommendation and commenting engines? No.

In his post, Vinh compares the challenge archiving a digital experience to archiving a conversation: you can record and transcribe the words, but it’s nigh impossible to recreate the entire context of the location, environment, body language, location, etc. But the metaphor that I think we should using when thinking about digital archiving is architecture.

Three reasons why.

1. Like architecture, digital products are things people use and experience. They’re designed for a purpose, and have an impact on the inhabitants / user’s emotional well-being, productivity, relationships with others, etc.

2. Like architecture, digital products are highly dependent on their context. A building lives in relationship to its inhabitants, the land it sits on, the city it lives in, the street its on, the surrounding buildings, traffic patterns, zoning laws, noise regulations, tax laws, etc.

3. Like architecture, digital products evolve over time, because of their users. Stewart Brand’s How Buildings Learn has been potentially overused (and abused) by digital product designers as a source of metaphor, but the fact remains that buildings and digital products are shaped for and by their users to become a better fit to actual needs over their lifecycle.

So what does this mean? I’m nowhere near the digital archiving community, but as an outsider I’d argue that the we should be thinking about archiving digital experiences in the same way that we think about “archiving” architecture. You can’t archive a building and its context, but you can archive documentation about the building, artifacts of its construction and use over time, and the stories and experiences of the people that used those buildings.[1]

Similarly with digital products, we shouldn’t focus so much on placing a product in a hermetically sealed virtualized box, but instead document the experience of using that product (through screencasts, videos, etc.), the rationale behind the product (requirements docs, design docs and other development artifacts), information about the context the product lived in (technical context, market/competitive context, social context, etc.) and the impact the product had on its users and the world at large.

Future generations of digital product people would benefit from this approach to digital archiving; to understand the decisions we made, the tradeoffs we had to live with, and the context in which we operated. It’s why reading Tracy Kidder’s The Soul of a New Machine is still useful to us today, while spending time with the Data General Eclipse MV/8000 (if you could even get your hands on one) isn’t. In 20 years, even if you could get a page of the Huffington Post to render faithfully, it wouldn’t do much for you. But if you had archival footage of the HuffPo user experience, combined with insight into the decision making process of the design team, combined with background information on the economics of content and online advertising in 2011, along with an understanding of how Twitter and Facebook worked — that would be much more useful, and would give you a richer understanding of both the product and its context.

---

[1] I deliberately stayed away from the word “preserve” here. I’m talking about making reproductions of the architecture and its productive media, not entombing structures themselves. Entombing structures feels to me to be about as useful as entombing digital prouducts.

Thanks to Bryan Boyer and Matt Jacobs, both of whom reviewed drafts of this post and gave me invaluable feedback.

Comments

[Judith]

A quick plug for the Personal Digital Archiving conference next week at the Internet Archive. Lots of smart people talking about how this plays out for individuals, commercial products and collecting institutions. http://www.personalarchiving.com/2011-schedule/

[Michael Sippey]

Yes! That's a good plug, sounds like a great event.

[Debbilboy]

Paradoxical that the acknowledgements for your copy-editors/proofreaders appear right after a typo (see the article's terminal word). Good essay, nonetheless.

[Michael Sippey]

Yes, indeed a paradox. Those lazy friends of mine, offering substantive feedback on the ideas in the piece, and not doing copy editing for me. Those jerks. I clearly need better friends.

[Chris Zahller]

No soup for them! ;-)}