In Section 1, we explained why rapid prototyping and frequent iteration with minimal downtime were necessary in ubicomp applications development. In Brooks' terms, ubicomp applications need to grow organically [5]. One barrier that stands in the way of this goal is the difficulty of modifying an existing system made up of a complex collection of interacting parts. If the designer is not careful, modifications to one part of the system can easily have undesirable ramifications on other parts of the system.
In Classroom 2000, the initial system contained a single electronic whiteboard surface with audio recording. Over time, and due to requests from users (both teachers and students) we included an extended whiteboard, an instrumented Web browser (initially built by one of the users and integrated into the system in a matter of days), video, and improved HTML notes. While this growing of the system was not without pain, we never experienced a downtime during a quarter's classes and frequently introduced new functionality in the middle of a quarter. This evolution was possible because very early on we adopted a structure to the capture problem that separated different concerns cleanly. This structuring divides the capture problem into four separate phases [2]:
We did not have the same experience of organic evolution with Cyberguide. Nor did we have this success with one other major context-aware project, CyberDesk [11]. The main reason for this is that we have not yet succeeded in separating issues of context gathering and interpretation from the triggering of application behavior. The analogy with GUI programming mentioned in Section 4 is again appropriate here. One of the main advantages of a GUI toolkits and user interface management systems is that they are successful in separating concerns of the application from concerns of the user interface. This allows flexibility in changing one (usually the presentation) without affecting the other. For context-aware computing, we need to be able to effectively separate the concerns of the application from the concerns of the environment. That is why we are currently developing a generic context server which holds pieces of contextual information (time, identity, location, and entities associated with sensors) organized in a way that allows an application to register interest in parts of the environment's context and be automatically informed of relevant changes to that context. It is the responsibility of the context server to gather and interpret raw contextual information.
The requirements on the context server are more complex, however. Context is dynamic. The source of a piece of context may change while an application is running. For example, as a tracked individual walks outside, a GPS receiver may broadcast updates on his location. Stepping inside would mean a switch to any number of positioning systems. The context server must hide these details from the application, which is only interested in where the person is, not how that location is determined.
Context sensing devices differ in the accuracy with which they record information. GPS might be accurate to within 100 feet, but a building location system might have a finer resolution. Different positioning systems can deliver the same information but in different forms. GPS delivers latitude/longitude, whereas an Active Badge [25] indoor system delivers position via cell identities that are separately mapped to building-relevant locations. The context server needs to insulate the application from these worries.
Finally, different forms of context can become available at different times. In essence, an application may not know what kinds of context are available to it until run-time. The context server needs to be able to discover context-generating resources dynamically and inform running applications appropriately. An example of this resource discovery problem occurs in Classroom 2000. Different instrumented classrooms provide different recording capabilities and those recording capabilities do not always work. A context server that serves the Zen* system would inform particular capture clients of the functionality of recording streams in its environment, allowing the client to customize its interface appropriately.