Thesis 09

Everyware has profoundly different implications for the user experience than previous paradigms.

Contemporary designers of digital products and services speak of the "user experience": in other words, how does it feel to use this?

Where complex technological artifacts are concerned, such experiences arise from the interplay of a great many factors, subjective ones and those which are more objectively quantifiable. Consistently eliciting good user experiences means accounting for the physical design of the human interface, the flow of interaction between user and device, and the larger context in which that interaction is embedded.

In not a single one of these dimensions is the experience of everyware anything like that of personal computing. Simply put, people engaging everyware will find it hard to relate it to anything they may have experienced in previous encounters with computing technology.

Let's compare a familiar scenario from personal computing with a correspondingly typical use case for everyware to see why this is so.

The conventional case is something that happens millions of times a day: Driven by some specific need, a user sits down at her desk, opens up her computer, and launches an applicationa spreadsheet, a word processor, an e-mail client. via the computer's operating system, she issues explicit commands to that application, and with any luck she achieves what she set out to do in some reasonable amount of time.

By contrast, in everyware, a routine scenario might specify that, by entering a room, you trigger a cascade of responses on the part of embedded systems around you. Sensors in the flooring register your presence, your needs are inferred (from the time of day, the presence of others, or even the state of your own body), and conditions in the room altered accordingly. But few if any of these are directly related to the reason you had in your mind for moving from one place to another.

The everyware scenario is still based on the same primitives the desktop interaction relies upon; at the very lowest level, both are built on a similar substrate of microprocessors, memory, networking, and code. But should you happen to distribute those processors in the physical environment, link them to a grid of embedded sensors and effectors, and connect them all as nodes of a wireless network, you have something markedly different on your hands.

The PC user actively chose the time, manner, and duration of her involvement with her machine, and also (assuming that the machine was portable) had some say regarding where it took place. That one machine was the only technical system she needed to accomplish her goal, and conversely she was the only person whose commands it needed to attend to. Thus bounded on both sides, the interaction fell into a call-and-response rhythm: user actions followed by system events. In a way, we might even say that an application is called into being by the user's task-driven or information-seeking behavior and shut down when her success conditions have been achieved.

Compare these facets of the experience to the situation of everyware, in which the system precedes the user. you walk into a room, and something happens in response: The lights come on, your e-mails are routed to a local wall screen, a menu of options corresponding to your new location appears on the display sewn into your left sleeve. Maybe the response is something you weren't even aware of. Whether or not you walk into the room in pursuance of a particular aim or goal, the system's reaction to your arrival is probably tangential to that goal. Such an interaction can't meaningfully be constructed as "task-driven." Nor does anything in this interplay between user and system even correspond with the other main mode we see in human interaction with conventional computing systems: information seeking.

Could you use everyware instrumentally, to accomplish a discrete task or garner facts about the world? Of course. But that's not what it's "for," not in the same way that a specific function is what an application or a search engine is for. It simply "is," in a way that personal computing is not, and that quality necessarily evokes an entirely different kind of experience on the part of those encountering it.

Even the ways that you address such a system, or are kept apprised of its continuing operation, are different than the ones we're used to. As PARC's victoria Bellotti and her co-authors pointed out, in a 2002 paper, designers of user experiences for standard systems "rarely have to worry about questions of the following sort:

• When I address a system, how does it know I am addressing it?

• When I ask a system to do something how do I know it is attending?

• When I issue a command (such as save, execute or delete), how does the system know what it relates to?

• How do I know the system understands my command and is correctly executing my intended action?

• How do I recover from mistakes?"

All of these questions, of course, come into play in the context of everyware. They go directly to the heart of the difference between ubiquitous systems and the digital artifacts we're used to. What they tell us is that everyware is not something you sit down in front of, intent on engaging. It's neither something that is easily contained in a session of use, nor an environment in which blunders and missteps can simply be Ctrl-Z'ed away.

What it is is a radically new situation that will require the development over time of a doctrine and a body of standards and conventionsstarting with the interfaces through which we address it.