This one’s long and weird, but stick with me: I’m using this blog post to clarify a bunch of ideas that have been kicking around for a while.
In the latest The Ministry, Warren Ellis talks about books with a digital shadow:
On the assumption that in the Western world few people buying comics are too far away from a library or internet cafe at the very least, the potential exists to build an accessible data shadow above any book.
In fact, it could be done in very sophisticated ways. Electronic hyperlinks could be built right into the pages.
…Vertigo books from the ’90s — INVISIBLES, PREACHER, TRANSMETROPOLITAN — were books about ideas. The three of us were writing about our discrete areas of interest, and, in large part, we were telling you about the things we knew. Which isn’t a bad thing. Some people balk at writers having any opinion, interest or intent beyond banging out a neutral yarn, but, you know, fuck that noise. Comics are an educational tool, used for anything from instructional pamphlets for civil disobedience to workplace hygiene. The best fiction, like the best reportage, is about the writer telling the reader where they think they are today, and what they think it looks like.
That would be an interesting way to do a modern comic. One that has its own electronic universe standing behind it, accessible through an URL printed on the front of the book, or multiple URLs seeded throughout the book. The book would not rely on them for its effect and textual integrity, but it would be supported and extended by a directory of information about the book, produced both by the creators and those of its audience who wished to extend their consumption of and involvement with the book.
Let’s explore the possibilities that this opens up.
Let’s say you are a budding comic artist or writer. You read Ellis’s latest epic, which is all papertagged with semacodes or NFC tags, or something else that’s much less clumsy. You start looking through it, and (on the second or third reading, maybe) you follow the hyperlinks.
You find that, in addition to the supplemental creative material that Warren talks about above, the comic has links to a development wiki set up for the purpose of developing the technology that makes the comic project run. It has HOWTO files, source code, downloadable client binaries, the works. The discussion pages have the developers and Warren talking about what the thing should do, and how.
You can see where the dead ends were, and how they were worked around (or not), and a development roadmap for the project. Maybe even a mailing list or separate wiki for it.
There is also a trail of the research and writing Warren did while developing the idea, which already (to an extent) exists: here you see where he bookmarked Semacode with the tag spimeworld; here you see his notes, some links to other peoples’ blog posts on the topic, and the ministry article where he first started publicly talking about the idea.
In short, you see the germ, flowering, and development of the physical object you hold in your hand, both creatively and technically; you have its DNA. The source code. And it can teach you how to do the same.
So, you take that, and you branch off of the wiki, creating your own project, which contains the old, at least in the form of links back to it. You start researching your worldbuilding, and slowly build it with a melange of newspaper articles and sketches and scraps of your own writing.
You write the script, and you and an artist pull it all together, and carefully craft both the work itself, and the links to the source material. Months before the comic is published, the site goes public, and (if you’re lucky), a community forms around it. The paper comic becomes a physical extension of the digital shadow.
More: the comic becomes a coherent structure that takes the big pile of digital mess and cruft and shapes it, and relates it all together in a way that helps tell a story, build a world, and make sense of it, in a way that’s substantially different from the website. It’s a lens to look through.
And the next writer or artist to pick it up can follow the trail back to Warren Ellis’s comic, and the evolution of the system continues. Eventually, you have whole generations and branches of trial and error, and failed experiments, and successful ones.
These become design patterns, embodied in physical objects, which are born from the digital shadow of their source material and the contributions of the artist, writer, fans, critics, geeks, and hackers.
The comic becomes a “theory object.”
Okay, digression time.
Last year, I ran a year-long kind of experiment, where I used index cards exclusively, both to work (i.e. to sketch and to write), and to track the work, using the Getting Things Done “project” paradigm.
It became a sort of meta-meta-project, where I took notes on the process, using the process, and used the cards to brainstorm and sketch better ways to organize the cards, which I then used to organize the sketches and notes. And that testing allowed me to iterate and improve. It was a bootstrap process that was far more fun than you should really legally be able to have while fully clothed and playing with office supplies.
Of course, I didn’t really get much else done, which is a real flaw of any do-it-yourself tool for work tracking. (Most of the hackers I know who have run into this, of course, were doing it on the computer, using python and emacs planner and applescript, and many of those folks ended up using paper. I followed the opposite course, which is itself yet another example of something.)
In any case, I did manage to get some work done, in between experimenting with manila tabs versus coin envelopes for structured card piles, and noticed something interesting as I did so.
That is, when the tool you use to work is itself the tool you use to track your work, the completed work seems to end up as a richer and more meaningful object.
Because it is linked to, or even contains, the sum of the decisions, mistakes, variations, source material, notes, comments, and other metadata that you’ve used to track and manage the project, the thing has a kind of DNA. It’s as though it were food that contains, not only the recipe, but the history of how the recipe was worked out, by trial and error.
I didn’t really have a way of articulating this until I read Julian’s post, Theory Objects and Design Patterns:
The “Theory Object” is a kind of design pattern for design itself. It’s about thinking by creating, and revealing the trail of discovery in the process of making things. And it has this recursive characteristic ‚Äî not just revealing the process in the documentation or the manual or the “write-up” or the “post-mortem”, but actually embedding all of this within the designed Thing itself.
If I’ve got this right, what Julian means, here, is that a “Theory Object” is where you’ve got a prototype, not only in the literal sense, but in the psychological sense of an invariant representation. It holds the set of decisions and design concepts that it embodies within itself, as its digital payload.
Which brings us back to Warren Ellis and his ideas about digital shadows.
This is much like Doug Engelbart’s 1962 vision of an augmented architect’s toolkit (scroll down), where the research and calculations that an architect makes while drawing a home are embedded within the digital blueprint.
The core concept is that the deliverable, itself, is only one (minor) artifact of the creative and critical process, and there is a whole network of theory, concepts, decisions, other possible variations, and other information that, right now, is neither interconnected, nor archived, and is certainly not connected to the deliverable itself.
Thus, the deliverable often needs explanation, or ends up creating a lot of rehashing of the work already done. However, if the deliverable was a theory object, where the documents referenced, history of decisions, discussions, and other elements that created the deliverable, you would have something very much like r0ml’s vision of open source… where the food is served with the recipe that created it.
But in this case, it’s not just the recipe. It’s the lineage of the experimentation and variation that led to the food, which is one physical instantiation of that lineage.
Julian:
The Theory Object is a way of making things ‚Äî of doing design ‚Äî that reveals the process of design, all of Latour’s inscriptions, all the iterations all the trials and failures and wrong turns. Why? To make things public in this way reveals the “made”, “hand-crafted” social character of things. And it’s better, politically and for better futures, to know that something was made this way rather than that way, why such decisions are made, and by whom.
…
Here, finally, is the Theory Object recursion I was talking about: the Theory Object is the design pattern and the instantiation. It is a way to design — a pattern — and the outcome of adhering to that design pattern.
This idea is compelling.
It certainly rubs hard up against some hard-held ideals of design and intellectual property; would a product designer really want her design sketches and notes accessible via the manufactured object? She might (certainly it would extend the reach of her portfolio), but odds are the manufacturer and patent holder might disagree.
What about the prototype, then? Internally, after several years of working with theory objects, a corporation or design firm would have a set of objects surrounded by digital data clouds, living design patterns to be picked up and re-applied when the next revision is due.
Anyway.
Many of the ideas you read about in ubiquitous computing and smart spaces have to do with entertainment: rock videos following you around the house, books that make the room act as sound effects and lighting and things like that.
But there is real value to be had in the idea of objects gaining digital shadows that goes beyond getting people to buy a new stereo so they can play with your latest woo-woo toy. I’m interested to see what else Julian comes up with, and inspired to start developing some of these ideas, too.
As soon as I figure out how, because PalmONE won’t open the camera up on my Treo to use semacode.
(Any tips on where to start from those already playing with this stuff would be much appreciated! :))
