Context Wars: the long version

There is a shorter version of this post.

One of the basic, implied, premises of context-sensitive computing seems to be that an application can find out enough about the world to make informed decisions. How the application finds out about the world, through sensors and then contextual states made up of the bringing together of the input of those sensors, is the subject of a lot of interesting research.

My point about Practice and the ever-changing-ness of context is that I don't think an application can ever know enough about the world to make decisions that are always correct. When I say that context is ever-changing, I don't (just) mean that the specific values of context-data are changing but that the relevant context-data is ever changing and which parts of context-data are relevant is an emergent property of any particular situation.

As Ricky said:

So how does an application decide what is relevant, without being pre-configured with a static set of entities that the programmer/administrator/user has deemed to be relevant to the scenarios in which the application will be used? Now there's a real research problem.

Any context-aware system is hampered by it's imperfect, incomplete, awareness of context. The context the system is aware of is not the same context of which the user is aware - and I don't believe it ever can be. There will inevitable arise a situation where an important aspect of relevant context is unavailable to the system. Even if a system can acquire new context-data, adding it to the pool of available context-data, determining if that new context-data is relevant and how to use it is a very difficult problem (as Ricky said!).

This is not to say that I think context-aware systems are useless or that there should be no work done on them - far from it - just that context aware systems need to be designed with this mismatch between what the system knows about the current context, what the system could ever know, and what the user knows, in mind.

In seamful design (advocated by Matthew Chalmers, though originally Mark Weiser's idea), the goal is not to make interaction with a thing seamless but to expose the "seams", or places where joining of two things takes place, to the user as a way to empower the user to allow them to be more in charge of their interaction. Chalmers writes:

We suggest that deliberately affording knowledge and use of seams need not be a defensive or pragmatic choice—making a ‘design feature’ of a flaw—but a positive and empowering design option.

though he cautions:

Designers should ask themselves whether, given the particular settings, technologies and users under consideration, revealing seams in a system design will offer useful opportunities for user understanding, will merely be distracting and intrusive, or dangerous or counter–productive.

Relating specifically to context, places where ever-changing context is relevant to practice (or use within a larger context) but is not practical or possible to capture all of the relevant context, I suggest that a seamful design that includes the worker in the decision-making process of the application is more appropriate than one that attempts to remove the worker from the context-based decision making process. Such a system could capture the more stable available aspects of context but could include the user as a part of the decision-making process, allowing the user to leverage their knowlege of the context unavailable to the application to guide decisions.

When Ricky says:

What is needed are solutions to the problems of modelling, incomplete information, filtering, scaling and the derivation of context information from existing context information. Basically we need to figure out how to remove the current limiting factors so that it can be applied more generally and with predictable results that make sense to the user.

I have a problem because it seems to me there is a danger of creating applications that try to remove the user from the process of making decisions and to pass those decisions on to the application. This removal of agency (or, if you like, autonomy on behalf of the user) is dangerous because it could lead to situations where a user is powerless at the expense of a system that is making bad decisions through no fault other than it does not have access to all the relevant context, some of which is unavailable.

However, Ricky's statement could equally be taken in a person-centred, seamfully-sympathetic way where the results from the system are not complete decisions but information gathered and summarised from the myriad of context-sensors that the application has available to it.

Such an approach does not even preclude applications from making decisions where it the designers are confident that the all the relevant context is available to the application.