I spoke at Futuresonic in Manchester a week or so ago (mentioned previously). A tremendous time was had, with musical highlights being Battles and a Toshio Iwai+2 performance, and then, later, an late-night water-feature tour of Manchester courtesy of F., culminating in paddling with F. and T. outside Urbis at some ludicrous hour. Much fun, much giggling.
But, I spoke!
My presentation is online: Iterative architecture (built on an internet of things). In it, I leapfrog the precise characteristics of the instrumented world and - since I'm not an architect - consider instead a simplistic Iterative City, a gedanken space-ship. Over several generations, how would the inhabitants of a space-ship, with lightness of architecture not afforded by conventional cities, re-shape it? I outline 5 consequences of this, and touch on how they apply to other iterable spaces.
A weblog by Matt Webb.
Korbo, Lorbo, Jeetbo.
You can get updates to this blog on Twitter: follow @intrcnnctd.
About making things, and a little about why innovation is hard:
Thinking through making
Part of the shtik at Schulze & Webb is thinking through making. It was at the core of the Nokia Personalisation project, where (in part) we explored the interactions and experiences that come into being around mobile phones made using new, short-run manufacturing processes. We took some of the materials that could now be used and made non-functional phones out of them. Then, holding them and considering the physical things, we were able to (I hope) innovate, and allow other people who held these objects to do the same.
Tom Hume, on his mobile work:
you can't tell how well something will work until it's sitting there in your sweaty palm.
So right. So right.
Jack, the S of S&W, talks about this method of discovery by citing - of all things - a comment from Donald Rumsfeld that's won an award specifically for being baffling. It's discussed at LanguageLog:
Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know.
When we engage directly with the material - whether that's plastic or code - we test the grain of the object. We see that wooden buttons don't want to be pressed, and we'll need a different operating mechanism. When a material thing sits in our sweaty palm, or on our cluttered desk, we test the grain of the world. A phone with a surface too rough to hold (discussed here) lets us see whether the usual behaviours of constant handling and social display are contingent upon my social world or the mobile's physical form.
The grain of a thing is usually hidden, and I use the term in reference to Manuel de Landa at Tate Modern in 2004, on carpenters:
not sanding against the grain is not a social construction. you can, but it'll look terrible. you're in a partnership with the microstructure of the wood.
What is the grain? We don't know! How should we respond to it? We don't even know that we should know!
Thinking through making is about revealing the unknown unknowns.
Sometimes revealing the unknown unknowns points to opportunities, and that's where innovation comes in. My company is about thinking through making in order to find the innovation possibilities ourselves, and we do that for other people and companies too.
I won't say that there aren't other ways of innovating. But take successful entrepreneurs in this new wave of the Web: they know, deep down, the grain of the business world and the grain of the Web itself. And although a lot of the innovation is done in brainstorms and cafe conversations, eventually prototypes are necessary to think through making. And, before Flickr, Game Neverending [has the GNE Museum disappeared?] was what else but a process of grain discovery?
The online grain is pretty fluid. But the grain of stuff is pretty well-established--and it feels this area is only going to get more important as smart objects get cheaper, grow out of every website, and inhabit our homes. (I barely need add that, as designer-makers who cut their teeth online, helping figure this out is where S&W is positioned.)
When you make a thing which is innovative, you often have to sand against the grain. That's okay, because you can rewrite the technological grain as you go, and the social grain is based on expectations, and you can sometimes shape those too. (Also it's okay because this quality is often what makes something innovative.)
It leads to unsatisfactory experiences when the grain of a product isn't in alignment.
I'll give an example: Availabot (our first prototype product of our own, and part of Jack's RCA Show entry. It's a push puppet that stands to attention when that special buddy of yours come online on IM). I coded some and helped out just a little with the puppet--but I observed everything. Mainly what I observed was that making a thing is tough.
Availabot has three parts: the puppet itself, which can remember IM details; the various mechanisms and chips; the software on your computer. This is not to mention the IM and network infrastructure it requires. Since the game of the puppet is that it's a reverse voodoo doll, that it really is an instance of your buddy, right there on your desk, the whole illusion is unsatisfactory if you consider independently the microcontroller chips or the software on your computer.
The three parts need to be bound into a single object: the Availabot.
In practice, creating the new object was a long and effortful process. The puppet was a little LED, then a mechanism with some more logic, then a badly cut plastic model. The logic sat on a breadboard, plugged into a PC for debugging, a power supply, and a Mac for control. Wires were everywhere. The client software on the computer consisted of prototyping software (without IM support), then replaced with code glue for AppleScript, then replaced with a GUI-less client application (and, of course, another computer on the same IM network).
All the parts had to be carved separately. In the world, mechanisms and microcontrollers and software are three types of thing.
The moment these parts first worked together, I had a glimmer of the object the Availabot might become. But it was still tied down: to the power, to the PC, to the breadboard, to rough-and-ready electronics, to a clunky script that only 2 people could operate and that lived on only a single laptop.
When Brian Cantwell Smith, in On the origin of objects, is figuring out what we identify as objects [p101], he makes a distinction between objects and artifacts. Artifacts are
by definition products of human labor; there is no way to claim that they live independently of us. But once you remove the artifacts and the trees and the animals from the world, he says, you're left only with
infinitely variegated but not very cleanly divided rock outcroppings, muskeg, bramble patches, cloud formations, lichen, and the rest.
I'd make the point that what artifacts, trees and animals have in common is that they're divided from the land. They can move and be moved.
Availabot, as an early prototype, was more like a cloud formation than a movable thing.
Making things is hard
How was Availabot to become an artifact and separated from the land? It turns out that the borders around artifacts are hard fought (this perspective on making things comes from reading Pandora's Hope by Bruno Latour).
Armies are recruited to fight battles.
Simply to make the prototype videoed for the web page, a fabricating and assembling process must be invented to lift the puppet and mechanism from the breadboard. The army of USB standards and factories makes the puppet transferable from desk to desk. Huge libraries of code created by multiple corporations are enlisted to develop software that can be packaged and dropped onto any computer (although the software is still tied to the land of Mac OS X 10.4).
(Going further, to mass production, we'll need to recruit the knowledge of the entire manufacturing industry, for plastics pouring and quality control and so on. Then logistics. Etc.)
To bind all these parts into a single conceptual object, the puppet needs to remember IM details as it is moved around, and we need to bring experience design in to complete the illusion. Argument and presentation is required to allow Availabot to be a puppet, having its own social life and grain, rather than a shallow representation of something else. Without this argument, Availabot is a software application and it'd be hard to fully engage with the physical end of it. Only with all of this can Availabot - both the idea and the thing - be handed from person to person.
Another example: The iPod is a physical thing plus a screen interface plus music plus a management application plus a music store plus marketing. Somehow the experience of it has become
your music in your pocket. Binding these things together so that the thing-people-touch-and-see is also the thing-you-recommend and the thing-you-value is why the iPod is so satisfying, so simple, and why it can be sold for so much (that is, you're happy to pay for the physical thing, and it's not just an outboard version of iTunes which is free). It's also why it's so important for the iPod designers to provide as few breaks as possible in the flow of music from anywhere (be it their store or your CDs) to your ear, and prevent, as much as possible, you engaging with toys on the screen instead of with your music.
Very clever. Very hard. Very successful.
A broader interaction design
While making prototypes, as thinking through making, reveals grain and opportunity, simply making things is sweat and struggle.
But making things well is extremely rewarding.
Making things is also rewarding from an innovation perspective, because it means engaging with the materials of manufacture, marketing and vending. Once interaction design expands its canvas to these huge territories, even more opportunities become available.
I'm one of two principals at Schulze & Webb. We work in prototyping, innovation and interaction design, in product and on the Web. If my comments resonate with you, and if we can help, please get in touch: email@example.com.
Two conferences: I've just returned from We Love Technology, a day conference organised by blink. I hadn't realised how much good work was going on in Huddersfield, or what a pretty town it is. I was also privileged to meet the folks of both TileToy and Troika who blew me away with their friendliness, open hardware and code (the former), and exceptional work (the latter)--especially how they discuss it. Add onto that the many other conversations and people, and it was a tremendous event.
I was speaking about engaging technology. My talk is more a collection of starting points rather than any sustained argument, but it does lead up to my new motto, ACTS NOT FACTS, so I got that out of my system at least. As usual, the talk is online: Engaging Technology.
Next Thursday/Friday/Saturday I'll be at Futuresonic Manchester, attending the Social Technologies Summit. I'm on a panel with Tom Carden and Stanislav Roudavski, discussing "Iterative Architecture (Built On An Internet Of Things)".
I've never been to Futuresonic - or Manchester - before and I'm totally excited by it. Apart from the Summit, Futuresonic is mainly an electronic music and arts festival, so I'm going to absorb as much dirty sampling, clicks, ambient and media art as I can. Please do get in touch if you're planning to do--I might need some showing around.
The 8 latest posts are named
Filtered for nematodes and Uniqlo, Red, yellow, green, bice, plunket, plaid, Coffee morning three, Filtered for storytelling, We Didn't Start the Fire Pedia, Filtered for making and alienation, Filtered for art and other intangibles, and Filtered for top-notch long reads.
2014 December, November. 2013 June, May. 2012 July, May, April, March, February, January. 2011 May, March, February, January. 2010 December, January. 2009 February. 2008 December, November, September, August, July, June, May, April, March, February, January. 2007 December, November, October, September, July, June, May, March, February, January. 2006 December, November, October, September, August, July, June, May, April, March, February, January. 2005 December, November, October, September, August, July, June, May, April, March, February, January. 2004 December, November, October, September, August, July, June, May, April. 2003 December, November, October, September, August, July, June, May, April, March, February, January. 2002 December, November, October, September, August, July, June, May, April, March, February, January. 2001 December, November, October, September, August, July, June, May, April, March, February, January. 2000 December, November, October, September, August, July, June, May, April, March, February.
Interconnected is copyright 2000—2014 Matt Webb.