I just need to jot this down so I don’t lose it.
Mike Rea is an artist. This is his artist’s statement which brings together this wonderful relationship between fiction, underachievement, flaws, and failures. Lovely.
I just need to jot this down so I don’t lose it.
Mike Rea is an artist. This is his artist’s statement which brings together this wonderful relationship between fiction, underachievement, flaws, and failures. Lovely.
I’ve been away for awhile so obviously I’m just now catching up with some notes for the events and activities of the last few weeks. One thing I want to make a note about is the fun workshop that Nicolas and I facilitated at the Swiss Design Network conference in Basel Switzerland late last month. The workshop was largely Nicolas’ organization and we took advantage of the conference theme of “Design Fiction” to consider the topic of failure in design — failure as a guide and approach and provocation together with the considerations that design fiction can offer.
Nicolas has posted the notes from the workshop
It was a relatively short workshop — a couple of hours in total. Initially I was nervous that there would be not enough guidance to allow the participants to grab onto the material enthusiastically. That proved to be wrong. After an initial presentation that went over the topic of design fiction and failures that Nicolas had prepared, we broke the approximately 30 or so participants into groups of four or five individuals. There were three assignments that we had prepared that each group was meant to conduct. After completing each assignment — which lasted from 20-25 minutes each — the group turned inward and shared some summary insights, results and conclusions. They didn’t know all the assignments ahead of time.
The first assignment was to consider where and when failure happens in design. Without a specific definition of what constitutes failure, the assignment was meant to warm things up by creating a debate and set of examples as to what failure was and when and how it occurs. From Nicolas’ notes (my notebook has escaped me temporarily):
This assignment was useful to begin the thinking about failure. The goal was less about creating a definitive or definitional list and more about thinking beyond and using examples as motivators and things to think with.
The next assignment was essentially the first but to create examples that one might anticipate as a typical failure in the future — the design fiction failures. Things that could occur given that everything fails to meet our highest expectation or (as I’m particularly interested in) the highest of the hype that surrounds new designed stuff. Epic failures, or just routine annoyances were all open for consideration. How might the cloud computing promise fail in both the major disaster ways — as well as the small, wtf!? sort of ways.
Again, from Nicolas’ notes:
I was particularly taken by the 3D printer example. There’s of course lots of excitement about the possibilities of 3D printers in the home so that everyone makes their own stuff that they need. But, making stuff is hard and inevitably open to all kinds of crazy failures such as described here. Also — what do people do with the materials when they mess something up? How is the plastic (or whatever it ends up becoming — maybe noxious nasty stuff) get recycled? Will there have to evolve an entire system of rematerializing the goop? What about the equivalent of the print failures we often experience where one document ends up printing one letter per page, after page after page and we don’t notice until fifty sheets of paper have been used? Or when we scale something wrongly and the machine blindly goes ahead and prints something at 3 meters when we meant 3 millimeters? All these sorts of things will happen — can we use these insights to help make decisions about what and how to design? Can we start to communicate these failures as a way to design not with the expectation that the world is perfect — but that the results of designs have chinks and kinks in them?
The final activity was to think about possible taxonomies for designed failures — what are the types and kinds of failures as we’ve discussed them in the previous two assignments?
Why do I blog this? Well — just mostly to get some notes from the workshop up to share. I’m learning quite a bit from Nicolas on the failures theme, and perhaps its a way to answer a question that Chairman Bruce has lofted — now that we “get” the idea of design fiction and it seems to be inspirational for folks and useful in that regard — witness the theme of the Swiss Design Network conference this year. But..okay. We get it. Now what? How does the idea of design fiction either operationalize or become part of specific sorts of design practices in some informal or formal ways? It’s happening of course — all over the place and not because of this idea of design fiction itself, either how I’ve discussed it over the last 18 months or so, or how it’s been described and enacted by many people and agents. It’s not just about science fiction of course — and this was the topic of a paper at the conference that I may have the energy to describe in an upcoming post. But it is useful in very direct ways with the activities and goals of design generally speaking, that much is clear.
Since the *winter holidays here in Los Angeles, which is a strange thing for an East Coast boy, especially as I hear reports of epic dumps of man-killing snow in New York City, my favorite photography spot has been the recently opened Venice Beach Skate Park and the equally awesome Venice Skatepark. I’m not a skater, nor a Sk8r, nor a photographer inclined to action-y things, but being in the mix, under threat of kicked out boards and lawless aerials
makes the park an invigorating and challenging photography playground — and quite addictive.
I don’t want to attempt a rough-shod bit of metaphor-stretching — or at least not too much — to try and rationalize sharing this *non sequitur of a post, except to say that, as pertains the last photo, I have been obsessed with these moments when something tried..fails. The failure has this curious, no-fear character to it. Trying the thing that seems impossible, over and over again. Getting closer, or moving away from the original idea and into something else, &c. It’s never a failure out right, at least as I see it through a viewfinder. There’s always something quite lovely about the moment when the board stays where it is, and the skater goes somewhere else.
Why do I blog this? *shrug.
Continue reading Predictably Not Quite Failing
For no particular reason — perhaps a salute to Nicolas who will be presenting his work on design for failure at IxDA this week — I bring you this image taken during DE2008 in which Aaron Straup Cope discusses designing engineering systems with failure contingency as the critical path.
Why do I blog this? I find this perspective intriguing — it assumes system meltdown, anticipates it and delivers appropriate data to indicate when it might happen. If I remember correctly, there is no specific interest in being exact about failure, just that it will happen and you might be told roughly how long until it happens. So the effort is to help stave it off by various means — adding more servers to spread activity loads around, optimize queries, increase caching, whatever you need to do. This makes me think of the intractability of designing for deletion. If someone wants to extricate themselves from the databases of a service or system, there is almost certainly no quick and easy way — in fact, I doubt there is anyway at all, and most services are not obligated to handle these situations. If I told Google that I wanted to check out fully and completely, even if they wanted to do this, it is doubtful they could. Would someone have to run through all the backup *whatever — tapes? — wherever they may be? It’s not just the live systems, and its not just purging caches and so on. All of our data is on its own, like orphaned snapshots of moments in our lives, somewhere. I don’t necessarily find this chilling or anything like that. I’m just curious about this notion — designing for intractable, ugly, messy circumstances, like failure or deletion. Things that run counter to the intuition — we usually design for the beautiful, full, glorious 32-bit conditions.
Continue reading Design for Failure
Design tactics from Imagination Lancaster at the Design Connexity conference dinner. Relevant to the Near Future Laboratory’s Bureau of Failures and Frack Ups.
I swear to GOD this is a friend’s “sig” line in her emails (she’s the hardest working IT person at a university department with lots of whining, illegal-software-downloading, computer-breaking-and-never-fixing, softdrink-drinking-right-by-fancy-computer-equipment students, so I have complete sympathy.)
Various Disclaimers:
MAD AT ME? My email load is heavy and some things end up in spam folders. If you think I have forgotten about you, re-send your email or send me an SMS.
ERRORS? I use a TabletPC. (Handwriting recognition is almost perfect.)
Why do I blog this? It occurs to me that these are all ways of anticipating failures of various sorts. Failures in the handwriting recognition software (inevitable..); failures to respond and anticipation of people getting upset because there’s no response inevitably resulting in a follow-up email with thinly veiled expressions of piss-offedness, etc. What are the ways that our technology forces anticipated failure? Does anticipating failure lessen the consequences? Can anticipated failure become part of specifications so we get out of the land of fantasy-advertised-feature-richness and get back to the pragmatics of how things actually work out in the wilds of normal, human real social practices?
Continue reading Anticipating Failure
Complete Ubicomp fail. I mean..they can’t even get this most simple of scenarios straightened out and they want to put my refrigerator and toaster oven on the network? WTF. Seriously. Anytime I hear the alpha futurist-y featurists get all excited about some kind of idea for how the new ubicomp networked world will be so much more simpler and seamless and bug-free, I want to punch someone in the eye. They sound like a 5 year old who whines that they want a pink pony for their birthday. Ferchrissake. Just think even once about all the existing hassles that pink pony wishers have brought into the world and be happy that you can still breath the air around you.
Okay. Fancy hotel with all the bells and whistles. Sensor in the bathroom because some over competent architect/engineer or other member of a hubris-heavy discipline assumes I can’t find a light switch because I’m stupid/drunk/tired. Sensor detects my buffoonish/loaded/sleepy body in the bathroom and turns the light on for me. End of “use case.” Only, this sensor just cuts the light on whenever it pleases. In the middle of the night.
Solution: Door closure.
Result: Less sleep and a resentful blog post.
Why do I blog this? Observations about why Ubicomp is done better in sci-fi movies than in real life.
Continue reading Ubicomp is like a 5 year old wishing for a pink pony