[[page created automatically from word-processed document]]
Peter J. Brown
Computing Lab., The University, Canterbury, Kent CT2 7NF, UK
There are a number of different technologies that can detect the user's current location: GPS, DGPS, mobile phones [1, 2], PARCTabs , active badges , tags, and, for cases where the user actively records their location, barcodes placed at defined locations. The field of location-sensing is blossoming so much that it has been suggested that in the future it will be standard for every computer operating system to know the location of the computer it is running on, just as at present every operating system knows the time (albeit perhaps modulo 100 years).
For portable devices, such as a PDA coupled to a GPS system, this opens the way to location-aware applications, and in particular to applications that automatically trigger information that is relevant to the user's current location. Simple applications are in tourism, where information is given about sights that the user is passing, and in maintenance, where the user is automatically given information about nearby equipment. In some applications, e.g. those concerned with the logging of events, the act of triggering causes a program to be run.
We have been working in this field for the past five years -- the original inspiration coming from Xerox Research Centre Europe in Cambridge -- and the purpose of this paper is to present some of the lessons learned. In fact our work has been in context-aware applications in general: thus we are not just interested in location, but other elements of the user's context that may be detected by sensors, e.g. time, orientation, current companions, nearby equipment, temperature, the relative position of the nearest public transport vehicle, etc. A good deal of power, in terms of relating triggered information closely to the user's needs, comes from bringing together several contextual elements. As an example, information presented to a tourist might depend not only on the location, but on the time of day, the season of the year and the current temperature. Nevertheless, although our interest goes beyond just location, location is often a sine qua non of the applications that we have worked on.
Our prime aim is to make context-aware applications easy to create and to use: to move them from the research laboratory, where most of them still reside, to the marketplace . Specifically we aim to make authorship of applications simply a creative process, akin to creating web pages, rather than a programming challenge. To accomplish our aim, we have confined ourselves to discrete context-aware applications that involve triggering discrete pieces of information that are attached to discrete contexts, e.g. some information attached to the context of the location of the cathedral with a time in winter. We do not cover continuous applications where the user interface is continually changing as the user changes context. Continuous applications require programming effort, and provide a bigger authorship challenge.
An oft-quoted saying in hypertext is: "Customers do not want hypertext: they want solutions. Hypertext is only likely to be part of any solution". The statement is equally true if `context-aware computing' is substituted for `hypertext'.
Not surprisingly, therefore, all the applications we have worked with involve combining context-aware technology with other software and hardware technology. Two software examples of this are:
In order to cater for such needs, we have developed a model  that allows:
In this model, each piece of context-aware information is called a note. Each note is a set of fields: there might, for example be a <location> field, which specifies the location that the information is attached to, and a <body> field that gives the information to be triggered. A note does not say which fields are "context-aware" fields to be used for retrieval: this is done by the application, and is thus controlled by the user. Notes are collected into context-aware documents. A document might, for example, be a set of notes giving tourist information about various points in a city.
The more we work in context-aware applications, the more we are convinced that the key to success is techniques that work both in a real world and a pretended (simulated) world, and, indeed, in a combination of both. Some examples of this are:
Most user interfaces for context-aware applications involve a visual representation of the context. For location this visual representation will be a map. In order to act as an overview, it is useful if the map shows the locations where information can be triggered, e.g. a red dot (circle, rectangle) at each such location. Generally the visual representation and the context-aware document should be de-coupled from one another: thus a context-aware document should be usable with any map of the area the document covers, and, on the other side of the coin, a map of a city should be usable with any context-aware documents for that city. (This means of course, that our red dots would need to be superimposed dynamically on the map, depending on the document(s) in use.) Although this ideal of de-coupling may seem obvious, we have had a lively debate in our group on whether it should be relaxed in some practical applications.
Our work is mainly based on PDAs. Clearly the human interfaces on these PDAs for authorship/capture of context-aware information and for its subsequent use present many challenges. These have mainly been addressed by Pascoe, Morse and Ryan in .
One issue at a somewhat higher plane is levels of triggering. This is illustrated by the following example, which relates to context-aware information for a maintenance engineer, and gives three different levels at which triggering may occur:
The need for these different levels of triggering has led us towards our flexible, user-controlled, model for the context to be used for triggering .
Sometimes a context-aware document is an amorphous set of notes, each note to be triggered when the user enters its context. At other times there is a need for structuring that defines connections between notes. A simple example is a tour of a city. There may be a context-aware document describing tourist sites in a city, and on top of this it is useful to have tours, i.e. a sequence of locations that a user is recommended to take. In the user interface, a tourist taking a tour will have a Next button, which:
Our initial implementation embedded tours and other structures within the document that they applied to, but it is much better to keep the two separate. Separation has two advantages:
In our latest implementation, a tour is just a sequence of contexts; it need not be a tour of locations: it could, for example, be a sequence of different temperatures, used to test what is triggered in an application concerned with safety information.
Thus overall we have the context-aware information separate from the applications that use it, and, on top of this, we have the structuring of the context-aware information separate from the information itself.
The ultimate success of any context-aware application depends on its accuracy, as perceived by the user. If the user is regularly fed with information she thinks is irrelevant, then the application will soon be discarded. We had experience of some of the problems in this area when we first tried our tourist application in Cambridge. At one point the user triggered information for a certain museum, on the assumption by the system that they were about to pass it; in fact they were at least ten minutes walk away, and were likely to pass a number of other sights in the meantime. The reasons for this were:
There are answers to these problems (use DGPS, wait for SA to disappear, adjust authorship techniques to avoid dependence on very accurate positioning, introduce a knowledge of the terrain), but overall there are salutary lessons that a technology-driven application cannot ignore all the trying application-specific problems that so often arise.
On the positive side, my colleague's application in a game reserve in Kenya had none of these problems, because it was open country, and, given the lack of maps, a GPS reading, albeit a slightly inaccurate one, was a huge advantage .
Another practical detail, which is present in most applications, but which manifested itself most strongly in our maintenance application, is the representation of location of physical objects. Assume, for example, there is context-aware information about a water pipe (its capacity, original date of installation, recent maintenance history, etc.), to be triggered by an engineer when he is near the pipe. The pipe might have a complex shape, involving many turns. If the author needs to specify this shape as a set of rectangles, circles, etc., this can be very tedious. Instead it is much better for both author and user to work in terms of some name for this object, e.g. "water pipe from Physics Laboratory to main source", and let the system deduce the detail. When there are CAD drawings, for example, that associate named objects to locations, the context-aware application should extract location information from these, and allow the author/user to work in terms of the names used in the drawings.
More generally, this illustrates the need for context services, which allow authors and users to represent contexts in terms of a hierarchy of named objects ("Canterbury", "Canterbury Cathedral", "Canterbury Festival Week", "Summer", etc.). A really good context service would also provide context elements such as location in a ubiquitous way, independent of the type of sensor used to detect it.
Finally we will briefly discuss a topic where our experience is limited, but nevertheless is a key to many applications: this is the distribution of information.
Context-aware applications may be distributed in many ways:
Our limited experience of distributed applications involves using SMS and data calls between a PDA and a central server. Issues of distribution, which are largely complementary to the issues we have been tackling, are covered much more fully by the GUIDE project at the University of Lancaster .
We have described some diverse experiences of context-aware applications, but there are three threads that bring them all together.
Firstly our experiences have reinforced the saying quoted earlier, that location-aware technology, or context-aware technology in general, is only part of the solution to any real-world problem. For some applications, it is a significant part, for others just a useful starting point.
Following on from this, data used for context-aware triggering may have other roles within the overall application; it is thus vital that data has a flexible and portable form. We have carried this flexibility to two levels by keeping the data separate from the applications (and from visual representations, such as maps, used by applications), and the structuring information separate from the data.
Finally, if context-aware applications are to become mainstream applications, authorship must be made easy; we have made what we think is a good start start to this. The availability of good context services, which allow authors and users to work in terms of physical objects, would allow this to be carried further.
Several of my colleagues have contributed greatly to this work: I would especially like to mention John Bovey, Xian Chen, David Morse, Jason Pascoe, and Nick Ryan.