• Choose a category
• All
• Classic-Fiction

All of these things are signed off on by the client, after which they are released to the software development engineer, who is then responsible for the actual coding of the site.

When done conscientiously, this is an involved, painstaking process, one that can go on for many months and cost hundreds of thousands of dollars. Success in the endeavor depends vitally on accurate deliverables that clearly convey what is required.

No such deliverables currently exist for everyware. If everyware presents situations in which multiple actors interact simultaneously with multiple systems in a given environment, in three dimensions of space and one of time, we lack the conventions that would allow us to represent such interactions to each other. If everyware implies that the state of remote systems may impinge quite profoundly on events unfolding here and now, we scarcely have a way to model these influences. If everyware involves mapping gesture to system behavior, we lack whatever equivalent of choreographic notation would be necessary to consistently describe gesture numerically. And where the Web, until very recently, was governed by a page metaphor that associated a consistent address with a known behavior, interaction in everyware lacks for any such capacity. As designers, we simply don't yet know how to discuss these issues—not with each other, not with our clients, and especially not with the people using the things we build.

At present, these challenges are resolved on a bespoke, case-by-case basis, and development teams have tended to be small and homogeneous enough that the necessary ideas can easily be conveyed, one way or another. This is strikingly reminiscent of design practice in the early days of the Web—a glorious moment in which a hundred flowers certainly bloomed, and yet so terribly disappointing in that ninety-six of them turned out to be weeds.

Just as was the case with the Web, as everyware matures—and especially as it becomes commercialized and diffuses further into the world—there will be a greater demand for consistency, reliability and accountability, and this will mandate the creation of deliverable formats to account for all of the relevant variables. It is true that such design documents did not exist for hypertext systems prior to the advent of the World Wide Web, and that a practice developed and to some degree became formalized within just a few years. Nevertheless, with regard to everyware, this conversation hasn't even properly started yet.

Thesis 58

As yet, everyware offers the user no compelling and clearly stated value proposition.

The last of the inhibiting factors we'll be discussing is the deep and as yet unaddressed disconnect that exists between the current discourse around ubiquitous systems, and any discernable desire on the part of meaningfully large populations for such systems.

Inside the field, however elaborated they've become with an embroidery of satisfying and clever details, we've told each other these tales of ubiquity so many times that they've become rote, even clichÉd—but we've forgotten to ascertain whether or not they make any sense to anyone outside the contours of our consensual hallucination.

HP's Gene Becker describes the issue this way:

The potential uses and benefits of ubicomp often seem 'obvious'; most of us in the field have spun variations of the same futuristic scenarios, to the point where it seems like a familiar and tired genre of joke. 'you walk into the [conference room, living room, museum gallery, hospital ward], the contextual intention system recognizes you by your [beacon, tag, badge, face, gait], and the [lights, music, temperature, privacy settings, security permissions] adjust smoothly to your preferences. your new location is announced to the [room, building, global buddy list service, Homeland Security Department], and your [videoconference, favorite TV show, appointment calendar, breakfast order] is automatically started.' And so on. Of course, what real people