Thesis 37


Everyday life presents designers of everyware with a particularly difficult case because so very much about it is tacit, unspoken, or defined with insufficient precision.

One of the reasons why networked bathtubs, explicitly ordered friendship arrays, and the other artifacts of everyware we've encountered can seem so dissonant to us is that they collapse two realms that have generally been separate and distinct in the past: the technical, with all the ordered precision it implies, and the messy inexactitude of the everyday.

Everyday situations pose a particular challenge to the designer because so many of their important constituents are tacit or unspoken. They lack hard edges, clear definitions, known sets of actors, and defined time limits, and this makes them exquisitely difficult to represent in terms useful to system engineers. Significant aspects of a given transaction may not even be consciously perceived by participants, in the way that things seen too often disappear from sight.

Information technology, of course, requires just the opposite: that as much as possible be made as explicit as possible. In programming, for example, software engineers use tools like Object Management Group's Unified Modeling Language (UML) to specify application structure, behavior and architecture with the necessary degree of rigor. (UML and its analogues can also be used to map less technical procedures, e.g., business processes.)

Make no mistake about it, "specify" is the operative word here. UML allows programmers to decompose a situation into a use case: a highly granular, stepped, sequential representation of the interaction, with all events and participants precisely defined. Such use cases are a necessary intermediate step between the high-level, natural language description of a scenario and its ultimate expression in code.

In a valid use case, nothing is left unspecified or undefined. Every party to an interaction must be named, as well as all of the attributes belonging to (and all the operations that can be performed on) each of them. To an non-engineer, the level of attention to detail involved can seem almost pathologically obsessive. In order to write sound code, though, all of these values must be specified minutely.

Now consider such requirements in the light of everyday lifespecifically, in the light of those everyday communications that appear to lack content, but which nonetheless convey important social and emotional information: so-called phatic utterances. These present us with a perfect example of something critical to our understanding of everyday life, which is yet highly resistant to technical specification.

We're familiar with quite a few kinds of phatic utterance, from morning greetings in the elevator, or the flurry of endearments with which happy couples shower each other, to "minimum verbal encouragers"the odd grunts and "uh-huh"s that let you know when someone is listening to you. Responding appropriately to such communications means accurately picking up subtle cues as to the communicator's intent, and those cues are often nonverbal in nature. They may reside in the speaker's body language, or in the context in which the utterance is offered. Either way, though, we understand that when a neighbor says "Lovely weather we're having, isn't it?," this is a performance of openness, availability, and friendliness, not an invitation to discuss the climate.

Most nonautistic adults have internalized the complexities of parsing situations like these, but designers of technical systems will find them very, very difficult to represent adequately. And if phatic speech poses real problems, at least it is speech. What about the pauses, ellipses, pregnant silences, and other signifying absences of everyday communication? How do you model profoundly meaningful but essentially negative events like these in UML?

This isn't a rhetorical question. The fuzziness, indirection and imprecision we see in everyday speech are far from atypical; they can stand in for many human behaviors that are not exactly what they seem, many situations whose meaning is the product of an extremely subtle interplay among events both tacit and fully articulated.

If we are ever to regard the appearance of computing in everyday life as anything more than an annoyance, though, someone will have to do just this sort of thing. Someone will have to model fuzzy, indirect, imprecise behaviors. Someone will have to teach systems to regard some utterances as signal and some as noise, some facts as significant and some as misdirection, some gestures as compulsive tics and yet others as meaningful commands.

These are clearly not trivial things to expect. In fact, challenges of this order are often called "AI-hard"that is, a system capable of mastering them could be construed as having successfully met the definition of artificial human intelligence. Simply describing everyday situations in useful detail would utterly tax contemporary digital design practice and most of the methodological tools it's built on.

Again, I am not expressing the sentiment that we should not attempt to design systems graceful enough for everyday life. I am simply trying to evoke the magnitude of the challenges faced by the designers of such systems. If nothing else, it would be wise for us all to remember that, while our information technology may be digital in nature, the human beings interacting with it will always be infuriatingly and delightfully analog.



Everyware. The dawning age of ubiquitous computing
Everyware: The Dawning Age of Ubiquitous Computing
ISBN: 0321384016
EAN: 2147483647
Year: 2004
Pages: 124

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net