Let me be the first to assure you that it rapidly becomes obvious, at least to me, when I’ve opened a can of worms: my post last week on the distinction between “location-based services” and “context-aware applications” has generated some really tasty pushback from readers, including a rather pointed missive from someone who we’ve agreed shall remain nameless here, and who felt my definition was unduly reductionist.

As will occasionally be an occupational hazard for the would-be human boundary object, in trying to convey something important from one of the communities I’m involved in to another, I oversimplified. It turns out that I myself was guilty of committing just the lapse I’d set out to address in the broader discussion around these themes, leaving out some important pointers to the history of shared assumptions on which I built my distinction. So everything that follows here hopefully redresses that, and explains (for those who care) just why and how I arrived at the definition I did.

It’s not for everyone, but if you’ve even occasionally heard the phrase “context-aware” being bruited about your workplace, you may find it of some interest and utility. Leastways, I hope so.

Paul Dourish’s 2004 “What We Talk About When We Talk About Context” is the classic discussion of the theme. As is always the case, Dourish brings the most welcome sort of intellectual richness to the table, catnip to those of us who get dispirited when the scope of conversation narrows to some arcane matter of engineering.

He starts by identifying the critical break between positivist and phenomenological approaches to understanding context, a break that renders so many of the discussions designers, engineers and strategists have around the subject exercises in frustration.

Briefly, heirs to the positivist tradition conceive of the world as a place in which things (and people) have concrete, stable identities, each of which is capable of being usefully described by an objective observer. Some other important things tend to follow from this way of understanding reality – the notion, for example, that such objects also have positions in time and space which are knowable and susceptible to specification at arbitrary precision. It’s an orderly, Newtonian universe, and it’s the one many if not most of the people you know who were trained as engineers are comfortable inhabiting.

But it stands in stark contrast to the phenomenological take on things, which is premised on the instability and subjectivity of the things we perceive, and on the irreducible importance of these perceptions as they register on the lived body, i.e. you, now, here, in your own skin, heir to your own history of experience. On the phenomenological side of the house, all of the grandeur resides in the act of interpretation – which is always somebody’s interpretation, crucially inflected by their situation. (For those folks you no doubt know who tend to put the phrase social sciences rather pointedly in quotes, and whose legs start to twitch the moment any hint of Frenchness is invoked, you can refer them back to the basic Heisenbergian insight that the very fact of observation affects that which is being observed; I wouldn’t imagine anyone would have heartburn with that idea at this late date.)

The phenomenological approach – and this is the worldview that stands, either explicitly or otherwise, behind the entire field subsuming design and user research and ethnography, at least as those things are practiced by the people I know – insists that the world in its richness cannot be reduced to datasets. Or not, anyway, without doing fatal damage to everything that truly matters.

Dourish identifies four problematic assumptions that go hand-in-hand with the positivist stance:

- that context is a form of information. From this follows the notion that you can make a “context object,” that everything relevant to the understanding of a given situation can be encoded as the single state of a computational system;
- that it is delineable, i.e. given the above, that there is some stable way of determining what constitutes “relevancy” and what does not;
- that it is stable – reasonably self-explanatory, I’d think;
- and that context and activity are separable, so if I am drinking coffee at the Wayne’s on Yrjönkatu, “drinking coffee” is the action of interest, and the Wayne’s, the weather, who I am with, and what I’m wearing are merely increasingly elaborate ways of describing an envelope inside which that activity proceeds, and which we’re choosing to call “context.”

If you’re inclined to accept a positivist construction of things, the only real problem remaining for you as a would-be developer of context-aware applications is one of representation: how do you best model and encode the apparatus of objects and states in the world which between them determine the relevant context for a given activity?

But Dourish argues (persuasively, I think) that this is the wrong question. For him, this mysterious thing context is something that only be arrived at through interaction – “an achievement, rather than an observation; an outcome, rather than a premise.” It’s relational in the deepest sense of the word, a state of being that arises out of the shared performance and understanding of two or more parties (actors, agents, what have you).

And why do we want to characterize this state of being in the first place? “[T]o be able to use the context in order to discriminate or elaborate the meaning of the user’s activity.” That’s it.

This points back to Dey, Salber and Abowd’s earlier definition of context as “implicit situational information” – in fact, any information “that can be used to characterize the situation of an entity…a person, place or object that is considered relevant to the interaction between a user and an application, including the user and the applications themselves.” And this is useful, or even necessary, because, as Lucy Suchman had already argued, most of the dispositive factors in human interaction tend to become explicit only in the event of some default or breakdown in communication.

In other words, we do all this work to capture facts about the environment in which an activity transpires in order to infer the meaning of that activity to its participants. Once we have that in hand, we can propose appropriate services, interface modes, alerts and so forth – services that will seem to “effortlessly” and even “magically” anticipate desire. And therefore make good on the Weiserian promise/premise still embedded in most contemporary ubicomp scenarios, however occult it’s become.

That’s the work that “context” does in interaction design. And that understood, maybe we can now unpack together the shorthand definition I offered last week. If Dourish, particularly, persuades us that robust context “awareness” is the very definition of a Hard Problem, that any static encoding of such an awareness is in itself problematic, and that the tools and methods engineers tend to trust and rely upon are constitutionally ill-suited to the attempt, my question is: why even bother? (This is especially true when modeling human behavior with any sensitivity is, shall we say, external to the envelope of demonstrated competence on the part of whatever development organization you work for, and is likely to remain so for the foreseeable future.)

Why even bother to do all the work of reconstructing the unwieldy, ill-defined actor-networks that make up our lives in real time, that is, just to anticipate desire by a few seconds? Don’t try to model and infer; do recognize instead the simple, material constituents of the local potential for action.

And twelve hundred words downstream, this finally leads us back to the (comparatively rather stripped-back) definition of context awareness I offered last week: that a mobile device’s “capabilities and available interface modalities at any given moment are largely if not entirely determined by the other networked objects around it.”

Is this a lasting way of ducking the hard problems? No, not really: everything Dourish argues still holds, and will assuredly still sneak back in during the design of the above. Providing for an acceptably good user experience will still require subtlety, finesse, discretion, and other things chronically in short supply in technical development organizations. But what it is is a way of being parsimonious about the interaction design challenges our organizations do take on, with an eye toward reducing the complications of context (and the attendant opportunities for default, misunderstanding, misfire, time-wasting, and humiliation) to some manageable minimum.

Is this not so terribly far from what Yvonne Rogers means, in suggesting that we move on from Weiser? You bet. Am I happy with such a relatively constrained scope of ambition? For the moment, sure. Fair enough?