I’m sure you’ll agree that the world hardly needs another blogging or meta-blogging service, but it’s worth signing up for Tumblr just to check out its design. Like online portfolio service Carbonmade, it nails some current design trends—big fonts, gradients, “simplicity”, clever writing—in really thoughtful and appropriate ways, without looking merely trendy. In both applications, stuff you do once is big and easy, and stuff you do often is accessible and quick. Even the sign-up confirmation email is lovely. It’s also nice that Tumblr’s not overly Ajax-y, too, except where it’s really useful (like previewing your design changes).

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 source¹. 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.

¹ (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.)

But I don’t think that Chrysler’s ad department got the message. Before reading that story on Time’s site, I had to click through an ad, where I was told…

I’d paid off a different smaller set of loans with Unipac Nelnet about a year ago, and I was amazed that they sent me no letter of confirmation that the loans were fully paid, thanks very much, not even an email (I ended up phoning them to make sure), and that they’d simply closed my account on their website. Just a “login failed” to tell me something’s changed. There’s no way to look at my payment history, confirm my payoff date, or do anything at all.

So yesterday, I was pleased that at least Sallie Mae’s site didn’t instantly treat me like I’d never existed and close my account, though they now seem to think I owe them -$1.05 (keep it, guys!). But how’s this for a congratulatory message?

Luckily, the main account view is more helpful; this is a detail page for a payment plan that’s no more. I’m not looking for a gold-foiled certificate suitable for framing, but I’ve been a steady customer for more than a decade with these companies, would it be so hard to help me enjoy the moment a little bit here?

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.

There really wasn’t much about IDEA I was disappointed with, though I was unimpressed with Linda Stone’s talk (repeated verbatim from Supernova in 2005) about continuous partial attention. It’s clearly a valuable observation, but her talk was based on sweeping, unsupported, and a-historial generalizations about “everyone”, what “we” do, what “kids today” do, and tidy 20-year cycles of behavior. She’s done the research to back up some of her points—too bad it came across as anecdotal and casual here. The second day’s “Next Generation Libraries” panel somehow never gelled, despite all three speakers having something interesting to say. MAYA’s work on libraries is great, a genuine integration of information architectures (Peter has a good summary of the project from a couple of years ago). I’d really hoped Seattle “City Librarian” Deborah Jacobs would talk more about how the SPL’s had to work with some rather austere and user-unfriendly aspects of the Koolhaas library with boring stuff like, you know, actual signs. Unfortunately things were running late and Jacobs disappeared right after her talk.

Highlights for me included Dan Hill, who reprised and extended his “Movements in Modern Media” talk. It was a pretty dense set of ideas—being already pretty well-read in Dan’s stuff helped :-). He told me afterwards that most of what he’d shown, including a note-perfect facsimile issue of the Economist imagining the BBC in 2015, he’d put together for work presentations, not just to illustrate his talk. It’s impressive and confident stuff. Definitely look for his slides at cityofsound.com at some point, they’re worth a close look.

I’d heard of some of Local Projects’ work before, StoryCorps in particular. Jake Barton’s terrific talk followed on really beautifully from David Guiney’s; both understood the emotional connection their work made with people. The Stamen boys showed a selection of their work, which looked great, of course. I think everyone in the room was impressed by their co-presenter Fernanda Viégas’ “Many Eyes” project (out soon, hopefully). It’s IBM Research’s effort at “democratizing data visualization.” They’ve cracked one of those problems that I hadn’t even really noticed before: the ability to point at and bookmark states of, or places in, data visualizations, which can facilitate blog-like conversations around those bookmarks. It’s the difference between being able to bookmark a few seconds halfway through a film rather than having to fast forward to that point again.

Bruce Sterling closed the conference in his full professional keynoting-curmudgeon mode, often bouncing up and down like a toddler dancing to a marching band. Although it was actually quite an indictment of information architecture, it was a fairly thrilling speech. Though he’d looked to be engrossed in his laptop in the back of the room for two days, he’d clearly been listening closely. We could tell because the first five minutes or so of his talk was a William Burroughs-style cutup of the IDEA speakers’ own words, with all the professional jargon and high-end designer flourishes intact. It’s a technique he’s used elsewhere, but it was especially appropriate at IDEA. Speakers had talked about building structures or processes that would elicit user-generated contributions (Jake Barton, for example, talked about “designing a process that created an exhibition”). Sterling was basically saying: you guys like that user-generated stuff, well how do you like this. Sure, IA is guilty of being a bit in love with its own academic and technical jargon (though I’d say it’s more down to earth than other design disciplines), so sure, that petard was sort of sitting there for him to hoist us on. But Scott Berkun pointed out in his notes, what professional conference wouldn’t be to some degree an excuse to indulge in insiders-only language for a couple of days?

Sterling also compared IA work to the “useless voids” in Koolhaas’ library building (yeah, we were kinda asking for that one by having IDEA there), he had a pretty simple point: there are real problems out there, mostly due to petro-centric and destructive legacy production systems, that need solving. That need solving now, by designers who can do better than their predecessors, and do it faster. So stop building your fancy craft marketplace web sites with their clever little color wheels and go fix the shit that’s killing us. Ok, Sterling didn’t specifically call out young Robert Kalin, who’d had the bad luck to have the next to last slot on the schedule, but you get the idea. He’s right, of course. Even purely digital stuff’s starting to affect the environment directly.

And it was at this point that David Guiney’s two sessions on design at the National Park Service suddenly felt most relevant to me. Here’s a hundred-year old organization, responsible for looking after and providing access to a staggering amount of collectively-owned resources in the face of budget cuts, environmental decline, and waning public interest.

Guiney spoke about the NPS’ role as “interpreters” of their resources, which it defines as “the process of helping each park visitor find an opportunity to personally connect with a place. Each individual may connect to the place in a different way….” In other words, it’s a designed process that depends on negotiating both facts and feelings, frequently through narratives. The best “architectures of participation”, like Local Projects’ work, or the trends Dan mapped out around Lost, work best when filled with something like storytelling. As Eric once said to me of data visualizations: “this stuff’s gotta sing.” I think that’s why Cooper’s work at the Getty Museum didn’t seem to sing, despite the user-centered process used to create it. I’m wary of art or design which has as its aim merely to “make people think” or to “raise awareness”; Sterling’s point was that that’s not nearly enough.

Hey, I had almost exactly the same idea for a desktop widget back when Apple’s Dashboard came out. :-) Of course, Blossom is much more configurable. It’s a fine example of calm technology, and is a lot like the stuff Jack and Matt have built

But isn’t there something depressing about statements like this one from the developer?

…there is a productivity problem with people who are online during work—checking the news, slashdot, MDA, or playing a game, and later feeling upset that work is not done. Blossom execution and marketing must address that need in a simple and fun way.

Does it always have to be about productivity? You’re wasting time! Someone’s probably using their time more effectively! I mean, you’ve got to be effective! Is what you’re doing right now really worth it…and are you willing to pay the price for all that time wasted? Does it really make me want to do better work to know that there’s yet another channel for monitoring my time? Why does beauty—and Blossom really is quite beautiful—have to be put in the service of getting me to spend more hours tapping away at my keyboard? Why not help me grow relationships with friends who’ve laid fallow in iChat, or whose emails have gone unreplied-to, or whose numbers haven’t been dialed recently, or whose recent photos haven’t been viewed lately? This software Chia-pet-Tamagotchi taskmaster sounds perfectly grim to me.

(BTW, I can’t resist pointing out that my grad school paper is the first Google result for “medieval marginalia”!)

Matt’s “Atom for Applications” idea is especially great: instead of delivering just a chunk of content, also deliver a user interface widget with which to deal with that content. We’re starting to see that in trivial ways already with things like FeedFlare, which adds relevent services to feed entries. (Like this blog post? Digg it now!) Basecamp’s project milestone calendar feeds include links to let you check off that you’ve finished a task. What if this were even better? Amazon could deliver a feed of books with “Buy now” buttons embedded in it. Netflix could deliver a simple queue manager widget in feeds of suggested films. Neat.

“What does the Zune use the built-in WiFi for? Why, Zune-to-Zune sharing of music, of course. You can give your friend a song from your Zune and they can play it 3 times over 3 days, and then they get the option of purchasing the track (if it is available on the Zune Marketplace, which is the iTunes Store for Zunes).”

There’s also a short article in Seattle Weekly this week that describes this a bit more:

“It’s about being online and sharing your favorite playlist—at the school cafeteria and on the ski lift,” says [Microsoft’s] Stephenson, alluding to an online store, like iTunes, that will be connected to Zune. In the near future, Microsoft plans to add broadcasting functions, so Zune users can act as DJs, allowing random, nearby users of the device to tune in to what they are playing— or specifying their broadcasts for a select group of users.

Maybe it’d be nice to easily “borrow” a song from a friend, but is it really so much better than how you’d do it now that you’d be willing to put up with poorer battery life and the inevitable connectivity annoyances? (“Heather’s Zune is trying to connect, do you really want to allow this?”) And if I had files I didn’t want to share, I’d have to bother flagging them as private? I somehow don’t think kids in the school cafeteria have much trouble learning about and getting hold of new music easily.

And walking down the street or sitting on a bus browsing other peoples’ music collections has always struck me as a design exercise, not an evident need. Anyway, randomly sampling music is already easy: turn on the radio. I want more thoughfully curated suggestions, not fewer.

There are certainly ways the iTunes/iPod combination could do social music sharing in similar or better ways even without Wi-fi. Sharing can be asyncrhonous and still be useful: let me subscribe to iMix playlists that contain the short preview tracks from iTMS. I could listen to those playlists, then choose stuff from it I’d like to be buy next time I sync.