CIMAD Note 2006-07-25

From MobiComp

Some thoughts and questions on functional requirements for the application builder following the Bologna meeting on 17/18 July 2006.

1. We decided to target context-dependent information delivery systems using web-based content. The main application area here is landscape, site and museum visitor guides, with the added potential for use in other areas such as collection management. All content will be delivered in a web browser and all user interaction will be through the browser. Nevertheless, the need for future extensibility to handle more complex applications must be central to the design process.

2. The purpose of the application builder is to support non-expert users in the rapid development of applications by providing a structure for the content and associating individual content items with contextual events.

3. The issue of how to incorporate specialised data collection interfaces (e.g. FieldMap GIS) is left for future consideration. Kent will put some effort into refactoring the current FieldMap application to maximise the possibility of reusing its components, but we do not expect the first generation application builder to be able to construct a complete replica of the current program. Nevertheless, this is part of the CIMAD specification and so should be a background thread as we develop the application builder. For now, it should suffice to recall that all data input in FieldMap is through HTML forms and Java servlets. In principal, this should be compatible with the dynamic web-based and context dependent delivery mechanisms discussed here.

4. The application builder should support the construction of a tree/network of interconnected web pages. Each page may contain any necessary navigation links to allow the user to navigate freely in the absence of contextual triggering, or to override contextual triggering.

a. Web pages may be hosted on a remote server or on the mobile device. In general, we assume a networked environment, but it should be possible to support disconnected use.

b. Pages should be delivered in a form that matches the device capabilities. In the case of server-hosted pages:

i. does the device capability information come from the page request or from the device context?

ii. do we build appropriate pages on-the-fly from common source, or pre-build pages in several formats?

c. Content may be adapted to user preferences or profile information, such as level of interest/expertise in particular topics. Taken with device capabilities, this argues for a common mechanism for context-based dynamic page generation. It also raises the question of whether this can be supported on a disconnected device.

d. If the user is allowed to navigate freely away from the context-determined page, there should always be a “back to current context” link on each “non-current” page.

5. The application builder will associate each content page with the context that triggers it. For each page there will be one or more simple rules for triggering a request based on available contextual information, e.g.

if <context> then request url

Typically, we expect the context of interest to be a location or some location surrogate, such as a beacon device, e.g.

if location within 50m of <point p> then request url

or

if beacon id=xxx then request url

or, where device has a location that matches that of another entity,

if location matches <entity e> then request url

More complex rules might combine location with orientation:

if location within <area a> and

azimuth > 110 and azimuth < 130 and

elevation > 30 and elevation < 50

then request url

The context matching rules might also include time of day, day of week or other environmental conditions. Device capabilities and user preferences, interests or expertise might also be included. However, if as discussed above, these are used on the server side for dynamic creation of content, it would probably be more appropriate to send these to the server as request parameters. The application builder will generate a configuration file containing all required rules. At runtime, the rules will be evaluated by a listener component that monitors all context events and invokes the web browser with the appropriate url (and request paramenters).

6. The application builder will use a schema describing all available MobiComp entity types, trackers, listeners and other components. For each tracker, the schema will include a name, Java class name, description, and specification of all context elements that it generates. The information provided in the schema will be used to enable the user to choose components needed for their application and for the application builder to generate the context matching rules and a configuration file for the application. The configuration file will specify which MobiComp components should be instantiated in the application, together with any required initialisation parameters.

nsr 13:59, 1 August 2006 (BST)