Everyware_ The Dawning Age of Ubiquitous Computing - Adam Greenfield [90]
And this only gets more problematic because, as we've seen, so many applications of everyware rely on machine inference, on estimates about higher-level user behavior derived from patterns observed in the flow of data. A perfect example is the "smart coffee cup" Tim Kindberg and Armando Fox refer to in their 2002 article "System Software for Ubiquitous Computing," which "serves as a coffee cup in the usual way, but also contains sensing, processing and networking elements that let it communicate its state (full or empty, held or put down). So, the cup can give colleagues a hint about the state of the cup's owner."
But the word "hint" is well-chosen here, because that's really all the cup will be able to communicate. It may well be that a full mug on my desk implies that I am also in the room, but this is not always going to be the case, and any system that correlates the two facts had better do so pretty loosely. Products and services based on such pattern-recognition already exist in the world—I think of Amazon's "collaborative filtering"–driven recommendation engine—but for the most part, their designers are only now beginning to recognize that they have significantly underestimated the difficulty of deriving meaning from those patterns. The better part of my Amazon recommendations turn out to be utterly worthless—and of all commercial pattern-recognition systems, that's among those with the largest pools of data to draw on.
Lest we forget: "simple" is hard. In fact, Kindberg and Fox remind us that "[s]ome problems routinely put forward [in ubicomp] are actually AI-hard"—that is, as challenging as the creation of an artificial human-level intelligence. The example they offer—whether a technical system can accurately determine whether a meeting is in session in a given conference room, based on the available indicators—could be supplemented with many another. Knowing when a loved one's feelings have been hurt, when a baby is hungry, when confrontation may prove a better strategy than conciliation: These are things that we know in an instant, but that not even the most sensitive pattern-detection engine can determine with any consistency at all.
So there's a certain hubris in daring to intervene, clumsily, in situations that already work reasonably well, and still more in labeling that intervention "smart." If we want to consistently and reliably build ubiquitous systems that do share something of the nature of our finest tools, that do support the finest that is in us, we really will need some help.
Thesis 72
Even acknowledging their contingency, some explicit set of principles would be highly useful to developers and users both.
Almost all of the available literature on ubiquitous computing is academic. That is, it emerges from the methods and viewpoints of applied science as it is practiced in the collective institution of higher education.
As part of their immersion in the scientific method, academics are trained to be descriptive. A proper academic paper in the sciences is neither proscriptive nor prescriptive; it expresses no opinion about what should or should not happen. Much of the discourse around ubiquitous computing has to date been of the descriptive variety: This is a system we contemplate engineering; this is how far we were able to get with it; this is where our assumptions broke down.
But however useful such descriptive methodologies are, they're not particularly well suited to discussions of what ought to be (or ought not to be) built.
This is not to say that such discussions do not take place—of course they do, whether in person over a cold beer, on electronic mailing lists, or in any of the fora where people working in the field gather. The debates I've been lucky enough to witness are learned, wise, contentious, impassioned, occasionally hysterically funny...but they rarely seem to show up in the literature, except as traces. The realism and the critical