December 26, 2006
Review of "Everyware: The dawning age of ubiquitous computing" by Adam Greenfield
(First, a disclaimer: I recently criticized Bill Moggridge pretty strongly for writing a book all about his friends, so I’ll admit up front that Everyware’s author Adam Greenfield is a friend of mine, and he thanks me (along with many others) in the book’s acknowledgments. I also read and commented on bits of Everyware before its publication. Adam’s writing period was bounded roughly by two design events (Design Engaged 2004 and 2005) I organized that he attended. Everyware includes a couple of references to people and projects from those events, and Adam presented an early version of the content of the final section of Everyware there as well. In other words, I’ve had a ridiculously long time to prepare this review. Thanks for being patient, Adam.)
Adam’s thesis in Everyware: The dawning age of ubiquitous computing is that technology and our experience of it will change significantly in the very near future: computer processing will insinuate its way in into our daily lives deeply and invisibly, in a way that PCs haven’t. It will move from our desktops and server rooms into our walls, our furniture, our clothing, and perhaps even into our bodies; everyware will literally be everywhere.
There’s a great Mies Van Der Rohe quote from 1938 I kept thinking of while reading Everyware:
Each material has its specific characteristics which we must understand if we want to use it…. And just as we acquaint ourselves with materials, just as we must understand functions, so we must become familiar with the psychological and spiritual factors of our day. No cultural activity is possible otherwise; for we are dependent on the spirit of our time.
Five minutes with Adam’s other writings (or with Adam himself) will convince your he’s a Modernist , deeply concerned with the honest relationship of form to function and with the material nature of the designed environment. Yet familiar ideas about “form” and “function”, not to mention “material”, break down quickly when talking about invisible technologies. Everyware is in large part an attempt to explore what—exactly—this new “material” is, and what are its specific characteristics? More importantly, what will the the actual experience of this near-future technology feel like?
Adam calls everyware “information processing dissolving into behavior”, a riff on Naoto Fukasawa’s line about “design dissolving in behavior”. Fukasawa meant that the best product design is so unobtrusive that you simply stop noticing you’re using it. (For instance, if you wear a watch, you almost certainly glanced at it a few times yesterday. But can you actually remember doing it? Wristwatches are designs that have fully dissolved in behavior.) Adam’s phrase implies something similar, that ubicomp (“ubiquitous computation”) technologies allow complex data processing to fade from conscious use: think Star Trek’s shipboard computers, summoned with the spoken “Computer…”, as opposed to Windows’ clumsy “Press Ctrl+Alt+Del to login.” But Adam’s version of the phrase also evokes something sinister. “Information processing” has the ring of surveillance to it, of your movements in a city’s shopping district monitored by closed circuit cameras, of your credit card purchase histories tracked and archived, or of your web browsing history living forever on Google’s servers. We don’t necessarily want information processing to become as imperceptible to us, nor to fully “dissolve” into everyday behaviors. Everyware is Adam’s considered vision of both the positive and negative outcomes of pervasive, invisible computation.
Everyware is organized into five main sections, phrased as questions: what is everyware? How is it different from what we’re used to? What’s driving its emergence as a technology and design opportunity? What issues should we be aware of? Who gets to determine what everyware is, and how it behaves? When should we prepare for everyware? And finally, how do we “safeguard our prerogatives” and avoid some of the sinister implications of everyware? Each section answers the question in a series of assertions (“theses” here) of a sentence or two each; each thesis is page or three long.
The Make magazine reader will probably enjoy Everyware, though it doesn’t delve into technical details at all; no homebrew everyware projects here. I hope that ubicomp academics find its points about design ethics valuable as well. But Everware is probably going to find its audience mostly among user experience designers, those of us who have a foot in both technology and design (and probably don’t see too much difference between the two fields). Section 2 (“How is everyware different from what we’re used to?”) is largely framed in terms that those of us in the UX community will respond to. And it’s this longest Section that makes Everyware most feel like it was written for me: a designer working in technology, with a fair understanding of things like networks, protocols, and software engineering, but I’m by no means an expert in them. I’m generally aware of developments around ubiquitous computation, RFID, touch-based computing, and the increasingly sophisticated applications of mobile computing, but I haven’t worked on any of them. Everyware strikes a good balance between the impenetrable proceedings of the UBICOMP conferences and design writing. Adam expects the reader to get references to “Ctrl-Zing something away, “elevator pitches”, and “user experience” and something about how people behave with mobile phones. This is fairly critical to the overall success of the book: by positioning everyware in relationship to more familiar types of software (in Thesis 10), Adam’s able to make his case to the audience—designers—who will eventually find themselves in the position of making decisions about the user experience of an everyware product.
And yet, we may find we’re surprisingly unprepared to do so. The bulk of UX practice—following from academic HCI work—depends on an understanding (or at least sensitivity towards) a user’s “goals” and the “tasks” she goes through to reach them—answering a research question, finding a gift for a friend, and so on. We often do research into users, developing personas intended to articulate these goals and tasks, which we then model as well-defined interchanges between a user and a system: the user does this, the system responds with that. But consider Adam’s description (from Thesis 09) of sitting down to work in an everyware-enabled office: “Whether or not you walked into the room in pursuance of a particular aim or goal, the system’s response to your arrival was probably tangential to that goal. Such an interaction can’t meaningfully be constructed as ‘task-driven.’ Nor does anything in it even correspond with the other main mode we see in human interaction with conventional computing systems, information seeking.” I think it could be argued that some areas of UX design (large-scale collaborative environments like Second Life in particular) have found ways to design contexts, rather than structures for task-completion. But for most designers, Adam’s making a profoundly important point: in everyware, there simply is no “call-and-response” between user and system to predict, model, and design. Interactions may not be initiated by the user at all when “the system precedes the user.” (In Thesis 18, Adam also suggests that the human actor can’t really be called a “user” in an Everyware context.)
Thinking of computing as “no longer task-driven” is extensively treated by Paul Dourish, whom Adam discusses briefly in Thesis 19 (“Everyware is always situated in a particular context”). Dourish has suggested that “task-driven interaction” has always been an illusion anyway. Eric Nehrlich summarizes that view concisely : “the specification of plans makes more sense after the action has occurred, because afterwards we can figure out what actions were relevant to the goal which we were trying to achieve.” In other words, a task like “editing a document” appears to be a procedural behavior only because we can reconstruct the steps that were involved in its successful completion. Dourish outlines a theory of “embodied interaction” appropriate to a relationship with technology that’s not representable by goals, tasks, and mouse clicks. If you’re interested in this stuff, Malcolm McCullough’s Digital Ground also looks at the design implications of pervasive computing and builds on Dourish’s work to explore many of the same issues (and a few of the same research projects) Adam covers in Everyware from a more theoretical perspective.
Designers who prefer a practical discussion around these issues should look at Johan Redström’s dissertation Designing Everyday Computational Things, which works out a framework for the design of ubicomp that complements Adam’s ethical one nicely. Redström’s project was “to develop a more general design philosophy for how to design computational things for presence in everyday life.” To do that, Redström documented his design of several products that he used to test his theoretical framework. Like Adam, Redström is especially concerned with the limited level of engagement that academic HCI (Human-Computer Interaction) research has had with real human values. He writes of the inevitable (and uninspiring) ‘time-saving’ benefits touted by ubicomp researchers:
Many [proposed] devices import values from the workplace into the home, emphasizing the requirements of ‘domestic work’ by allowing chores to be done more efficiently or productively. Others emphasize the desirability of taking ‘time off,’ allowing people to play unproductive games or access new forms of broadcast media. Other values seem rarely to be addressed at all. (Redström p18).
As you’d expect in a full dissertation, Redström provides a more thorough critical overview of the literature than Adam does in Everyware, including an insightful critique of the term “usability.”
Section 5 (“Who will determine everyware?”) is the shortest section of the Everyware, and perhaps its least satisfying. (Though this section has some of the book’s best writing: it’s dense, but conversational.) There’s a short bit on mashup culture here, and a reference to the developer’s “fast-cheap-good: pick two” whiteboard manifesto. But by and large, Adam’s answer to the question is that the big technology vendors (Philips, Sun, Sony) will probably have the largest say in the process, since the development of new technological infrastructures and standards are inevitably costly. Adam does point out that state and local regulatory bodies may be in the best position to impose standards (though not without difficulty), and makes reference to a few “student projects.” Unfortunately he doesn’t address the work of artists at all, even those who have directly engaged many of the issues he’s concerned with. That’s a shame. The RFID category on Regine Debatty’s we-make-money-not-art site is just bursting with weird and clever ubicomp experiments. Sure, there’s plenty of silly and trivial examples out there—an artist gluing an RFID chip to something does not constitute an interesting critical or artistic statement—but there’s plenty of good work that offers valuable and compelling comment on everyware. Julian Bleeker’s projects are whimsical and thoughtful. Design students at the Interaction Institute Ivrea have produced some interesting projects (and an excellent survey of RFID technology and ethics. Adam also doesn’t discuss established artist-designers like Anthony Dunne and Fiona Raby or Natalie Jeremijenko. I’m surprised, since the work of all three is both critical and really approachable.
In fact, most examples Adam discusses are prototypes developed in corporate research labs, which raised some questions for me that aren’t addressed: does labeling prototypes as “future scenarios” (as most of these research groups do) serve to deflect criticism from them in any way? When Philips presents what is essentially a consumer application of surveillance technology as “just research”, does it make us less likely to hold them accountable? These aren’t just research projects; they’re PR and marketing projects as well. Adam does a great job of remaining critical throughout, but positioning everyware as something that only big corporations with research budgets engage in gives the impression it’s a phenomenon that individuals are powerless to affect. A discussion of the work of artists, students, and hackers would have provided some helpful balance to the conversation.
Section 6 (“When do we need to begin preparing for everyware?”) looks closely at what remaining social and technical barriers lie in the way of developing everyware: standards that either don’t yet exist or are still too young to be widely adopted; protocols and design processes that are from an earlier (web-centric) era of digital design; and maybe most importantly, that there’s currently no compelling value proposition for most potential users, no “killer app.” This section felt a little obligatory: the entire rest of the book had already convinced me that the time to begin preparing is right now (although some time ago would have been better), and that everyware’s a “hundred-year problem” that will only gradually replace current computing paradigms. I can see the point of calling this stuff out: it’s important to describe the current state of things in order to make the case that now is the time to make decisions. But Adam’s skeptical voice elsewhere in the book really isn’t as strong here, and parts of it are largely straight descriptions of the current state of various technologies and their marketers’ confident promises about them.
For instance, Thesis 59 (“The necessary processor speed already exists.”) describes Moore’s Law, and notes a few ways that processor speed could be distributed among nodes in an everyware context. Futurist extrapolations of “inevitable” capacity or speed, like “a human’s lifetime experiences will be stored on a device the size of a grain of sand” (p.197) are usually wrong. The history of technology in the long term is not the continued exponential growth curve that marketers would have us believe. Yes, storage is cheaper than in the past, chips are faster, but it’s not correct to assume these curves apply to technology systems as a whole. If tech curves were in fact exponential, we really would have by now bases on the moon (confidently predicted in the 1960’s), and homes would be powered by nuclear energy (predicted in the 1970’s). Cars reached a top speed of 100 mph in 1904 after only a few decades of development; the average car’s gas mileage today is no better than that of a 1908 Model T. Based on those early successes, it would have been reasonable to assume in 1910 that we’d be driving supersonic cars by now (not to mention flying in supersonic planes). Yes, many components of everyware exist, and in some places genuine everyware is already a reality. But Hong Kong’s “Octopus” paycard system may well be ubicomp’s Apollo moonshot: a success that happened to be an end, not a beginning.
I hope that if you haven’t already got Everyware, this review encourages you to pick it up. I’ve been reading Adam’s writing for about five years now, and Everyware is his best. He writes confidently and fluently here, and articulates a point of view unambiguously, something not all design writers can do well: “I mean to assert…that everyware, the regime of ambient informatics it gives rise to, and the condition of ambient findability they together entrain, will have significant and meaningful impact on the way you live your life and will do so before the first decade of the twenty-first century is out.” And though it’s almost impossible to avoid some jargon given the topic, he navigates a path between the technologist’s tendency towards acronyms and vaporware promises, and the designer’s love of meta-discussions and airy abstraction. Everyware’s tone is conversational, but it expects you to keep up: exactly what I want in books like this. This isn’t to say it’s all easy going. There are a lot of paragraphs in Everyware I had to read twice; it’s not Bruce Sterling’s easy ramble of tech words duct-taped together. There are also some flat-out great sentences here: “But it wouldn’t have taken a surplus of imagination, even ahead of the fact, to discern Napster latent in Paul Baran’s first paper on packet-switched networks, the Manhattan skyline in the Otis safety elevator patent, or the suburb and the strip mall latent in the heart of the internal combustion engine.”
A note about citing sources
Everyware contains no citations, and lacks a bibliography (though Adam’s posted one at the book’s website). This is a disappointing omission, and I’m a little surprised that the New Riders editors allowed it. It’s just maddening to read lines like “PARC’s Victoria Bellotti and her co-authors pointed out, in a 2002 paper…” without a pointer to the source1. Missing citations go over very badly in the research and academic communities, the same communities which Adam has heavily relied on for his own work. I don’t mean to single Everyware out—it’s hardly the first book in our field to omit footnotes. But I worry the lack of them here will limit Everyware’s usefulness outside of an audience of designers or casual readers. That’s a shame. Given the urgency the case Adam makes, everyware is as much a social issue as technological. Considering how accessible Everyware is, I can easily imagine it wielding some influence in policy-making had it been more rigorously documented.
1 (It’s from Making Sense of Sensing Systems: Five Questions for Designers and Researchers ; In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems: Changing Our World, Changing Ourselves (Minneapolis, Minnesota, USA, April 20 - 25, 2002). CHI ‘02. ACM Press, New York, NY, 415-422.)
Posted by Andrew at 12:37 PM | Comments (7)
November 27, 2006
Review: "Designing Interactions"
A few weeks ago Bill Moggridge’s new book Designing Interactions arrived at my house. It’s an enormous (more than 700 pages) and nicely designed book. It feels fresh and broad; there are interesting sections on mobile devices, patterns of technology adoption, play, service design, and critical design. Moggridge’s basic premise that good interaction design is the result of learning about people and prototyping solutions is very solid, and his examples illustrate it well. I think if you do this kind of work, you’ll especially enjoy the chapters on the mouse, the menu, or the Palm Pilot, and seeing lots of sketches and diagrams and screenshots. It’s fascinating to see things like Bill Atkinson’s sketches for the Apple Lisa’s menu system. Those glimpses into the field’s past make Designing Interactions an important book, the first attempt at a real cultural history of the field of interaction design, from its beginnings with Douglas Englebart and Xerox PARC, through current work designing for ubiquitous computing. Unfortunately, Designing Interactions suffers from some very serious flaws, and I hope that all readers will bring an especially critical eye to it.
In this review, I’ll focus on a few things in particular that bother me about the book and Moggridge’s approach to the material. First, he overuses (and misuses) the interview format, without providing authenticating evidence for the stories told by his subjects. Long stretches of the book feel like little more than mindless design-star fan journalism about the author’s pals and their companies. Finally, Moggridge never misses an opportunity to use his own company, IDEO, in a case study, or one of its employees in an interview. But by failing to make that vested interest clear, Moggridge turns the book into a marketing project. Bruce Sterling’s jacket blurb describes Designing Interactions as “a labor of love.” In this case, love is, if not blind, than pretty nearsighted. The book really should at the very least have the word “IDEO” in its title.
His story or history?
Designing Interactions reminds me of The Art of Unix Programming (a surprisingly fascinating and readable book, by the way). Like that book, Designing Interactions is a really both a cultural and technological history, made up of case studies, interviews, and technical material. There’s a variety of content, including some hand-drawn diagrams and a photo essay or two. But it’s those interviews that really make up a big part of the text. Moggridge excerpts his interviews at length, sometimes running more than a page of small text. (The complete video interviews come on a DVD with the book and are at the book’s website.)
It’s clear that Moggridge means this to be an approachable book, and the interviews have a good-natured, casual tone. But it’s a cumbersome way to structure a text. Throughout, the reader is constantly jumping between Moggridge’s voice and someone else’s. Several subjects have the annoying tendency to speak in informally dramatic ways, lapsing into quoted speech that’s hard to read. Inside a several-paragraph-long interview excerpt, there are passages like “If an expert comes along and says, ‘Yeah, yeah, I can do that. Where’s the super Orc? This is easy, perfect, perfect, perfect. This is so easy!’ Then we can say ‘Maybe you should be playing in expert mode.’ Then it’s ‘Ah, X, X, X…good? Hey where’d my perfect go? Good? Fair? Whoa, okay, I gotta pay attention.’” Catch all that? That’s an especially awful example (by Bing Gordan from the “Play” chapter), but Moggridge allows that kind of speech far too often.
Conversational speech isn’t an especially good format for deep personal reflection. So naturally, Moggridge’s interviewees tend to minimize their own failures, missteps, or unsuccessful designs, and gloss over difficulties. That makes the whole thing feel like a whitewash. I guess this kind of access is what the MIT Press means by an “industry insider’s viewpoint”, but it unfortunately makes the book something of a hagiography—complimentary biographies of designer-saints, whose every effort is nothing less than beautiful, innovative, useable and useful. Building a history out of fond memories means that Moggridge’s subjects are bathed in a sort of golden California glow of optimistic technophilia, bright ideas, and sudden success.
Jonathan Raban writes about memory in his book Passage to Juneau:
Memory always has its own dark purpose, often hidden from the rememberer; and it is a ruthless editor, with a facile knack for supplying corroborative detail. It’s impossible to draw hard-and-fast distinctions between deep-dredge memory, retrieving material directly from the silt in which it has lain for many years, and the shallow-dredge variety, in which one remembers only an earlier act of remembering.
I kept thinking of those lines as I read Moggridge’s interviews. First-person accounts can add great insight and depth to otherwise dry historical facts or documentary evidence. But that “facile knack” for editing is why historians don’t rely only on other peoples’ memories to write histories. Memory of “an earlier act of remembering” easily becomes nostalgia or drifts into sentimentality, where all the rough edges are smoothed entirely over. This is why Moggridge’s methodology would cause any historian concern: the interviews are quite recent (2002 through 2005). That means many of Moggridge’s subjects are discussing events of ten, fifteen, or even twenty years ago. What Bill Atkinson says in 2005 about something he remembers happening in 1985 might be interesting, but on its own it’s unreliable and unauthenticated. Yet without exception, Moggridge presents his subjects’ recollections uncritically as historical fact, without other material to support (or disprove) them. To be clear, I don’t disbelieve Moggridge’s subjects’ statements. But the lack of secondary authentication means I can’t easily tell their own interests (publicizing themselves or their companies, winning old arguments, claiming turf or expertise) from fact.
I’m guessing Moggridge wouldn’t claim to be a historian, though that certainly doesn’t get him off the hook. Moggridge stakes out sequences of events, trends and forces, and the actors involved in them. He attempts to situate his subjects in particular cultural and temporal contexts; that’s history, and it should be held to a historian’s standards. In his preface, Moggridge calls his approach “tell[ing] true stories about designing interactions, rather than structuring the content around a more polemic point of view.” The worrying term “true stories” aside, would a “polemic” stance have really hurt the overall accessibility of the book? Questioning assumptions and supporting assertions with other evidence wouldn’t ruffle his buddies’ feathers, and might have forced Moggridge to a more critical and insightful point of view.
And who doesn’t imagine going home one evening and inventing a whole paradigm like the menu bar, as Larry Tesler says Bill Atkinson did? It’s a designer’s lucid dream: “He’d thought the whole thing up in one night! I can’t imagine what happened that night.” In fact, other parts of Tesler’s account suggest they’d been working methodically through ideas for months before arriving at that one. Was there really a midnight inspiration, or could 25 years have colored the memory? (Raban again: “All first-person narratives are like this. I thought it was a body. You thought it was a body. We were both wrong.”)
So what, you say? Isn’t the point just to inspire the reader with great stories about clever solutions? Isn’t this just like reading someone’s blog, where everything is obviously subjective anyway? No. The danger of accepting peoples’ memories at face value isn’t just that they might be misremember a fact here and there. Nor is it that the design of buttons and menus isn’t a moral, cultural, and aesthetic imperative; it is. But in “true stories” like Tesler’s, Moggridge implies that the “people and prototypes” approach to design is somehow “natural,” and that designers and their clients who practice it are guaranteed a successful outcome. Another review of Designing Interactions comments that Moggridge’s “team[s] almost naturally followed an iterative prototyping approach to bringing their ideas into the world” (emphasis mine).
I do believe “people and prototypes” is both an effective and appropriate approach, and I recognize Moggridge’s and IDEO’s contributions to it. But what’s missing in Designing Interactions is the understanding that the very idea of “a design process based on people and prototypes” is not “natural”, it is itself a piece of technology, culturally situated and rooted in Moggridge’s Silicon Valley of the last few decades. There’s mythmaking going on here, reinforced by the affable tone of the design gurus on parade. Unable to be critical of his own convictions, Moggridge has written a narrative that can do nothing but reinforce them.
IDEOs Mio!
Throughout Designing Interactions, the IDEO design firm is never far from the reader’s awareness. Few sections fail to include an IDEO product or IDEO contribution. IDEO employees make up many of Moggridge’s interviews. The book’s final section on process and prototyping includes several pretty photos of stylish IDEOers in at work in action-designer poses, includes excerpts from IDEO publications, and promotes the company’s Method Cards. Yet for all of this, Moggridge’s is oddly vague about his own role in founding the company. The fact is stated in the one-paragraph author biography in the book’s flyleaf, then never appears again, though it’s alluded to through mentions of his previous company IDTwo. Moggridge should have made his role in IDEO and his relationships with his interview subjects abundantly clear. Most historians would have difficulty including that sort of biased material in their work, and would at the very least try to broaden it with other sources.
Don Norman’s jacket blurb says: “This will be the book—the book that summarizes how the technology of interaction came into being and prescribes how it will advance in the future.” But the IDEO bias in Designing Interactions should bother all readers. Yes, IDEO played a significant role in shaping some of the major products in interaction design history. But at times it’s as if Moggridge has included a section or interview specifically to give more ink for the company, which hardly needs help marketing itself. Moggridge should have been far more transparent about his own role at IDEO and about his relationship with the people, products, and clients in the book. (I wonder, were IDEO employees paid for their interview time?) After all, he stands to gain personally and professionally from promoting IDEO as the origin of (and exclusive experts on) interaction design. Again, from a historian’s point of view, the conflict of interest here is serious. I hope that the first part of Norman’s blurb won’t turn out to be true.
I found myself asking again and again, who is Designing Interactions really meant for? Its biases would make it a poor student textbook. Is it for other designers? I suppose so, though how useful is a long series of a-ha! moments and reminders to “learn about people” and “prototype often” as a design text? I’m worried that Moggridge is writing mostly for his peers—the ones who appear in the book—as a way of “telling their story”, an approach that’s better suited for magazine articles (maybe) than for a significant work of research. That might explain why there’s so much emphasis on company histories and intrigues: who worked for whom when, who managed what group at what company, and so on. For instance, the section on Will Wright’s company Maxis deals mostly with the company’s financial history, and how its acquisition by Electronic Arts affected internal management. Why include this? Steven Johnson’s Emergence has a far better discussion of the interaction design of Wright’s games. The chapter on the Internet is all but useless, as we get more about Google’s corporate history than on its product development process. That’s a shame, considering Google’s emphasis on rapid iteration on ideas is such a great example of Moggridge’s methods.
Another view: Dan Saffer
It’s interesting to compare Designing Interactions with Dan Saffer’s recent book with a slightly different title: Designing for Interaction. Both authors use interviews, even with some of the same people (Larry Tesler and Brenda Laurel), but are limited to three or four questions and tightly-edited answers. (I’ll also admit that a couple of Dan’s subjects are friends of mine.) Designing for Interaction’s interviews are short sidebars that expand on each chapters’ main idea, without feeling distracting. That’s an appropriate and useful use of that kind of research.
Moggridge’s last two chapters make up a practical section, about the length of Saffer’s whole book. It feels a little rushed. The first 500 pages left me really wanting some solid instructional content that’s not here: task diagrams, wireframes, radio buttons, that sort of thing. Yet Saffer still manages to cover a lot more of the nuts and bolts and day to day work of interaction design. And even though the two books’ titles are close, for me the difference is pretty telling. “Designing for Interaction” follows from Saffer’s definition of the field as “the art of facilitating or instigating interactions between humans (or their agents), mediated by products.” Isn’t there something vital and slightly humble in Dan’s inclusion of “for” and the singular form of “interaction”? Designing for interaction means getting out of the way, designing interactions means deciding what “the way” itself will be.
Posted by Andrew at 09:55 PM | Comments (3) | TrackBack
September 25, 2006
Amazon aStore
Trying out Amazon’s new aStore product for Amazon Associates. Here are some books I like.
Posted by Andrew at 01:26 PM | TrackBack
July 17, 2006
Latest reading
Now that I’m back to about a hour on the bus each day, I’ve been reading. Here’s the latest:
“The Turk: The Life and Times of the Famous Eighteenth-Century Chess-Playing Machine” isn’t worth your time. It’s history writing of the dullest kind: a series of facts chronologically presented. First this happened, then this other thing, then something else. Well, that’s true as far as it goes, but it’s remarkably dry. There’s no poetry in it. It’s too bad, because I hadn’t realized the really important role the chess-playing automaton had in the history of technology. I wish that Standage had used the Turk as a jumping-off point to talk about other strands of tech history, and not just the obvious subsequent history of chess-playing machines: the closing chapter on Deep Blue feels utterly perfunctory that might as well read “and in 1997, they actually built one. The End.”
It’s fascinating that the original mechanical Turk seems also to have been the first “tech demo roadshow”, where a complex machine was paraded around to audiences. Of course, the thing was a fake, a magician’s prop, and those demos nothing more than carefully orchestrated conjuring shows. Of course, there’s still a lot of stage magic (and maybe real magic )in the technology demo, subtle misdirection, rehearsed patter, and a careful handling of details and context. I’d have loved Standage to look at how little has changed in the selling of technology since the 1700’s.
Chris Anderson spoke at Amazon a couple of weeks ago, and I got an advance copy of “The Long Tail”. Even for a pop-business book, it’s pretty slim, and largely just fills out his Wired article with more data. And frankly, it tends to feel like the same data chapter after chapter: Rhapsody, iTunes, and Amazon. The ideas are still compelling, but there’s not a lot of actionable information here besides: “offer more stuff, and make it findable and filterable.”
I also finally got around to reading “The Wisdom of Crowds”, which really is the most relevent of these three to Mechanical Turk, the project I work on at Amazon. I love stuff that debunks common sense and simultaneously suggests all kinds of new ways to think about certain kinds of problems. I remember Mike’s exhortation to us at Design Engaged two years ago to “run to the light of complexity.” Group-aggregation (“crowdsourcing”) is one compelling way to tackle complexity, sort of a human-powered quantum computing. Jaron Lanier’s dire warnings notwithstanding, “Wisdom of Crowds” is really convincing, and James Surowiecki is a teriffic writer. I know I’m two years late to the party on “Wisdom”, but if you haven’t read it, it’s worth it.
Posted by Andrew at 10:55 AM | Comments (1) | TrackBack
June 13, 2006
New Tufte book is out at last
I’m sure I’ll buy it: Tufte’s “Beautiful Evidence” is finally out.
Posted by Andrew at 01:26 PM | TrackBack
October 14, 2005
What does information want from us?
I read about half of a terrific book this weekend, “The Botany of Desire” by Michael Pollan. Its premise is simple but fertile: do plants “use” humans as much as we use them? The domestic dog, by learning to pick up on human emotional responses, has benefited evolutionarily compared to the wolf. Dogs that got along better with people were cared for in return. Likewise, learn to domesticate dogs and you get cheap labor, protection, etc.; the dog-human relationship benefitted both sides. Can the same be said of plants? Examining the relationship from this new angle lets Pollan explore four plants’ (the apple, the tulip, cannabis, and the potato) successful exploitation of human desires as an evolutionary tactic.
It made me think, again, of Ben Cerveny’s Design Engaged presentation from last year (some good notes on it by Timo Arnall). Ben’s take on the botany of information and our “gardening” of it might also be flipped around: what does information want from us? (I don’t think “information wants to be free” is a sufficient answer here.) Ben’s talk pointed to metadata as the catalyst of a “nitrogen cycle” that allows information to live past its original context, find purchase in new applications, or to make itself findable among other information that might compete for attention. Does information “want” metadata from us?
Posted by Andrew at 09:19 PM
June 02, 2005
Review of Thackara's "In the Bubble"
(This review’s been hanging around on my machine for a couple of months now. I never did get around to finding good quotations from the book, but it’s long enough as is.)
John Thackara is has made some great contributions to design without ever having designed a thing. His new book “In the Bubble: Designing in a Complex World” is largley a result of his work over the last 10+ years as the “symposiarch” of the Doors of Perception conference. At those conferences, his role has been to ask the right questions, and to describe the context in which various design problems reside.
It might sound like “asking the right questions” is a trivial, simple or even irrelevant job. It is not. Thackara’s point in “In the Bubble” is that the context has become so complex, fast-moving, global, and even invisible, that design has become a wholly different field than it has been in the past. In a readable mix of statistics, anecdotes, and analysis, Thackara details problems of sustainability, environment, population, and sprawl as problems of design. Problems which cannot be solved by simply making more pretty stuff. Current ideas about Ubicomp, or “ambient smart computing” don’t seem to be the answers, either; the “invisible computer” might merely make us more passive consumers of technology. Instead, Thackara asks designers to contribute to the design of services, relationships, and business models.
He begins with a chapter on “Lightness”, which is a central theme throughout the book. In a world of endless cheap goods, most people are unaware of the hugely wasteful resource expenditures that go into producing, say, a computer. You may remember the promise of the “weightless” economy in the 1990’s, but as Thackara points out, the truth is pretty heavy:
Only six per cent of the vast material flows in the US economy, for example, actually end up in products. The overall ratio of waste to durable products is closer to a hundred-to-one. Most so-called advanced economies are less than ten percent as energy efficient as the laws of physics allow.
So is “Lightness” just a call for designers to “do more with less”? Yes and no. Of course, asking us to use resources effeciently, and sustainably, is part of Thackara’s project. But he’s really also asking for designers to make those resources visible. Did it really take a couple of thousand pounds of material resources to make that computer? What if consumers could be made more aware of that inefficient flow? Bruce Sterling talks about future designed objects—“Spimes”— that “are precisely located in space and time. They have histories. They are recorded, tracked, inventoried, and always associated with a story. Spimes have identities, they are protagonists of a documented process.” (Actually, Sterling talked about “Blobjects, Ruling the Earth. Not just littering it: ruling it.” He’s way more fun to read than Thackara.) Spimes even have future histories, embedded instructions on how to dispose of or recycle them.
Further, Thackara describes “Lightness” as an organizing principle for businesses themselves. His extended example is BodyMedia. BodyMedia initially conceived of around 1999 as a consumer health-monitoring product (which didn’t sell well), then as an online service (which proved expensive and complex), and finally as an integrated product and service, sold through insurance companies. For a company that could easily have been just another dot.com, BodyMedia’s tenacity is impressive. This kind of business model agililty was nicely summarized in a post by Jason Fried of 37Signals as striving for “Less Mass”: “You’re not going to get it right the first time. Change must be easy and cheap.” His lists of “heavy” impediments to change and “light” solutions is worth thinking about. Adaptive Design and the growing importance of open, or at least hackable frameworks are other ways to increase this kind of “Lightness.” “Web service mashups” are already on their way to becoming last year’s meme, but user innovation with these services is impressive. Who’ll be the first company to figure out a business model based on Greasemonkey?
But back to “In the Bubble”. Nearly all of the one-word chapter titles (“Flow”, “Lightness”, “Speed”) were themselves the themes of various Doors conferences; the rest of the chapter titles certainly could have been. Thackara makes liberal use of Doors participants’ work, and in many places cites their on-stage talks from the conferences. Though in places this feels like clubby elitism, in general it’s a good approach. Doors has involved biologists, community activists, artists, architects, designers, musicians (once even a piano tuner), businesspeople, and politicians. There’s a real coherence to “In the Bubble” that comes from so many of his sources having had some personal interaction with each other and with Thackara himself.
The downside of that chumminess is that Thackara’s not really being terribly critical here, even though I think he believes he is. For all of his complaints about the design decisions of corporatations or governments, he’s far too much of an insider in those worlds to really offer deep criticism of them. This is especially obvious in the language of the Introduction (excerpted at his site) and Chapter 1. Although he’ll needle easy targets, like Prada’s pretentious failures, I often found myself wishing he’d go in for the kill and really tear apart some foolish, wasteful project. But the most he ever really musters up are some gently scolding rhetorical questions: does this gizmo sound like the sort of thing we really need? Do we really trust technologists to make such and such a decision?
Considering how up-to-date most of the book feels, there are some odd omissions. It’s surprising how rarely Thackara mentions video games, considering how much they’d add to his arguments. (Indeed, one of the few Doors of Perception conferences poorly represented in “In the Bubble” is 1998’s “Play”.) In “Literacy” he discusses the cultural and economic value of systems literacy, signal-to-noise literacy, and the ability to interpret dynamic “dashboards.” That’s gaming. His description of innovative uses of sound cues in systems monitoring technologies ignores the most obvious and sophisticated examples of dynamic audio in games. Although I’ve only read the New York Times excerpt of Steven Johnson’s Everything Bad is Good For You , there’s a lot there on what video games teach players about narrative complexity, resource management, and “social literacy”.
Although readers looking for deeply theoretical analyses of contemporary design might be disappointed, “In The Bubble” is a very worthwhile read. Thackara’s making some real demands of designers, ones which feel both thrilling and overwhelming.
Posted by Andrew at 05:39 PM
November 18, 2004
Design Engaged book list
Here’s what we suggested by leaving post-its on a wall like this. Set aside a few years if you want to work your way through. There were amazingly few overlaps; I think “A Thousand Years of Non-linear History” was on two peoples’ lists.
I had to guess in one or two places where the title wasn’t clear; if you spot an error, let me know. (Which “The Red Queen” is correct? They both sound good.)
A Thousand Plateaus: Capitalism and Schizophrenia
Signs: Lettering in the Environment
A Thousand Years of Nonlinear History
The Self-Made Tapestry: Pattern Formation in Nature
Abstracting Craft: The Practiced Digital Hand
Where the Action Is : The Foundations of Embodied Interaction
Rules of Play : Game Design Fundamentals
How We Became Posthuman: Virtual Bodies in Cybernetics, Literature, and Informatics
Jimmy Corrigan: The Smartest Kid on Earth
Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing
Crowded with Genius: The Scottish Enlightenment: Edinburgh’s Moment of the Mind
Multitude: War and Democracy in the Age of Empire
Getting Things Done: The Art of Stress-Free Productivity
Building Suburbia: Green Fields and Urban Growth, 1820-2000
Hard-Boiled Wonderland and the End of the World: A Novel
Turtles, Termites, and Traffic Jams: Explorations in Massively Parallel Microworlds
Creative Code: Aesthetics + Computation
The Last Party: Britpop, Blair and the Demise of English Rock
Window Seat: Reading the Landscape from the Air
Human-built World: How to think about Technology and Culture
Imperial San Francisco: Urban Power, Earthly Ruin
The Red Queen: Sex and the Evolution of Human Nature
The Mythical Man-Month: Essays on Software Engineering
Emergence: The Connected Lives of Ants, Brains, Cities, and Software
If on a Winter’s Night a Traveler
Digital Places: Building Our City of Bits
Mind Wide Open: Your Brain and the Neuroscience of Everyday Life
Visual Rhetoric in a Digital World : A Critical Sourcebook
The Future Dictionary of America
Lovemarks: The Future Beyond Brands
Posted by Andrew at 04:00 PM | Comments (0)
September 20, 2004
Like peanut butter and cucumbers
Are the words “PayPal” and Hacks” really ones you want to hear together in a book title? It’s somehow not confidence inspiring. Is it really even a hack to use Paypal as designed (see Hack 10: Send Money to Anyone)?
Posted by Andrew at 01:20 PM
September 15, 2004
Minipops Book
Craig’ Minipop’s book is coming out soon. Amazon.uk calls it “Ideal post-pub entertainment” which does not do it justice. Although I love my Minipops poster, I’m partial to the Normalpops.
Posted by Andrew at 04:19 PM | Comments (1)
August 28, 2004
From the "So you know it's good" department
Is the Matisse Enzer, building contracter mentioned on page 123 of Brand's "How Buildings Learn" the same Matisse Enzer who's the author of Peachpit Press' Visual QuickPro Guide: Unix for Mac OS X? Yep, seems to be.
Posted by Andrew at 12:00 PM
August 02, 2004
Review of Malcolm McCullough's "Digital Ground"
Malcolm McCullough's new book "Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing" is a readable and timely contribution to current interaction design. Using ideas drawn from architectural and design theory, cognitive science, and philosophy, McCullough significantly extends current ideas about pervasive computing and so-called experience design, while building on the foundation of traditional task-centered interface design. It's the best current book on interaction design, and should appeal to both designers and theorists.
Digital Ground is essentially a response to what John Thackara called "the design challenge of pervasive computing" at the Doors of Perception 7 conference in 2002. McCullough builds on the content of Doors 6 ("Lightness") and 7 ("Flow"), and on Thackara's statements in particular. Digital Ground's contribution is an exploration of "embodiment" and of the practice of design for situated technologies.
McCullough's own talks at both Doors 6 ("No Place Like Anywhere: Environmental Knowing and Design") and Doors 7 (also titled Digital Ground) are good introductions to his ideas. A version of the Doors 7 talk he wrote for Archis is reprinted at Doors' site.
McCullough was, as I recall, the only one at Doors 7 to say what seemed to me obvious, that anything that flows needs containers in which to flow:
Anyway, this is the heart of the matter: Flow needs fixity, like a river needs riverbanks. Intentionally fixed settings, also known as architecture, provide a necessary context for Flow.
Digital Ground attempts to define what those fixed settings are, and how they can be designed so that "being someplace digital" has meaning. McCullough's term "digital ground" is a nice one: as digital systems become embedded into the contexts of our lives, they form a background, present but unobtrusive. They function, like the physical built environment, as a context in which other behaviors and relationships exist. "The usability of well-made traditional places (i.e. workplaces, home, a corner of the library) now appears as a rich basis for design of context-aware technology." In other words, McCullough says, "life takes place." Providing a sense of embodiment—fixity and a sense of "place"—is the architectural challenge facing interaction design. The first third of "Digital Ground" explores the ideas of "embodiment," "place", and "context" in detail, and connects them to more concepts familiar to interaction designers (such as mental models or affordances).
McCullough introduces a set of typologies for pervasive computing products. Types are "generative design abstractions", which "unite periphery, passivity, phenomenology, adaptability, affordance, facility, appropriateness, and scale." Although that sounds overwhelming, consider a simple urban architectural type: the sidewalk cafe, which probably suggests to you not just some formal requirements, but some social patterns, behavioral etiquette, and may trigger some memories of experiences. This is embodiment at work. In the middle section of the book, McCullough explores a set of "situated types" for pervasive computing at length, along with ten technological "functions" that form pervasive computing systems (such as "sensors detect action"). The types read something like a cross between Alexander's architectural design patterns and interaction design scenarios, and are the most exciting section of the book. It would be a productive exercise to use the ten functions to brainstorm ideas for pervasive computing within the types.
McCullough isn't alone in exploring questions of embodiment in interaction design (although as far as I know, his use of architecture, and of types in particular, is unique). Inevitably, situated software has a blog (though a google search will find you some rather more human voices). Paul Dourish wrote that "embodiment is an emergent property of interactions" in "Where The Action Is" in 2001. "Embodiment" has concerned several other design writers as well, such as Mark Hansen, who seems to be considering the larger context of "new media art." Many of the Interaction Design Institute Ivrea's 2004 thesis projects deal with situated interaction in some way. (Other Ivrea student projects provide some of Digital Ground's design examples.) Clay Shirky's students' best projects all turned out to revolve around projects "form-fit" to few users, often in a specific physical location, for one-time situations like collecting money from fellow students for some shared expenses. Johan Redström's "Designing Everyday Computational Things" PhD dissertation (2001, but not cited in McCullough) also describes some fascinating and creative situated design projects. Redström's realized projects should speak to working designers and technologists; his dissertation may be more the more instructive text for readers interested in applications instead of theory:
Using experimental design, I have investigated how to design computational things for meaningful presence in everyday life.... The specific results from this investigation ... illustrate a set of parameters, and design opportunities, of this design space.... The more general results of this investigation are formulated as a design philosophy for everyday computational things.
All of this should be somewhat reassuring to designers. "Anytime, anywhere, infinitely scalable" design is a hard problem for designers (not to mention for engineers). And always-on, anytime, anywhere turns out to be a huge waste of resources, if nothing else. It's far smarter and more useful to know enough about local contexts of use to provide those resources at the right time, to the right person. In contrast, true "human-centered design" is primarily about delivering products that fit within human-scaled structures and situations. (I'll point out again that McCullough's typologies, Shirky's form-fit software, and Redström's projects aren't built on hierarchies, the default structural form of most software intended to scale.)
Digital Ground has its faults, though. McCullough brings up, but doesn't deeply engage, ethical and social consequences. Potential military or surviellance applications of pervasive computing are mentioned in passing, but there's no call for designers to take strong critical positions against these. It's easy to imagine how someone coming at this topic from a genuinely critical, even subversive approach would see "the design challenge of pervasive computing" wholly differently. For example, see Adam Greenfield's response to Ubicomp, or much of Anne Galloway's work. And although McCullough cites their work, his outlook is less critical than Anthony Dunne and Fiona Raby.
It's also worth mentioning that the use of the word "architecture" in interaction design, or in software in general, is far from uncontroversial (Peter Lindberg has written several great posts at Tesugen.com unpacking the concept of "software architecture".)
Throughout, I often wondered how McCullough might treat the business side of design. A long discursive section ("Accumulating Value") at the end of the book proposes that traditional economic measures of value that center on utilitarian measures' failure to take into account sustainability as a goal, and that "places remain great accumulators of value." Essentialy: trust me, pervasive computing will find its own valuation criteria, just as all other places do. It's important to differentiate valuation from evaluation, a topic that gets no attention in Digital Ground, yet which is also of market importance.
That's because the most valuable contribution of "user-centered design" may turn out to have been its insistence that the designer's responsibility to the user does not end with idea generation and production. Usability engineering, for better or worse, provides qualitative and quantitative methods for the evaluation of the effectiveness of a given design before your company makes a costly commitment to it. You might prefer that tiny text and fancy drop-down menu, but it's easy to tell when customers don't.
Redström writes "We argue that the coming ubiquity of computational artifacts drives a shift from efficient use to meaningful presence of information technology." Use is pretty easy to evaluate: did someone use it correctly, on the first try, and did she learn to master it in a reasonable amount of time? Has her productivity increased? These questions might have no real meaning when applied to products subsumed into the "digital ground." Should you measure how little a customer notices the product she's purchased, for example? What are the right questions to ask to measure the effectiveness or value of a design? This is a very serious issue once design leaves academic spheres for market-driven ones. It may be that, as McCullough writes, "at the heart of a new economy is the proposition that finance and the means of production are not the only forms of capital," but we still need ways to measure the appropriateness of given design solutions before they're placed into the world--Jakob Nielsen won't be banished easily from the next economy, either.
(Redström, by the way, addresses questions of evaluation at length in Chapter 9 ("From Use to Presence"), although his answers certainly won't satisfy a product manager or channel marketer looking for hard data. This seems to be an attempt at quantifying embodiement, although it's bafflingly specialist.)
It's also nice to see that McCullough's writing voice has evolved in a positve direction. Digital Groundis much more readable and enjoyable than his previous book Abstracting Craft, which really is quite tough going through long stretches. Although I'd prefer a few more concrete examples of pervasive interaction designs and designers in the body of the text, McCullough manages the tricky balance of academic and practical material nicely. Digital Ground should be required reading for anyone interested in where interaction design is headed.
Posted by Andrew at 10:23 AM | Comments (0)