Distributed Multimedia Research Group,

Department of Computing,

Lancaster University,

Lancaster, LA1 4YR.

telephone: +44 (0)1524 65201

e-mail: mitchelk,kc,nigel@comp.lancs.ac.uk

The Guide project is investigating the provision of context-sensitive mobile multimedia computing support for city visitors. In essence, the project is developing systems and application-level support for hand-portable multimedia end-systems which provide information to visitors as they navigate an appropriately networked city. The end-systems being developed are context-sensitive, i.e. they have knowledge of their users and of their environment including, most importantly, their physical location. This information is used to tailor the system's behavior in order to provide users with an intelligent visitor guide.

The project builds on the ideas of Ubiquitous Computing as proposed by Weiser in [Weiser,93] and borrows heavily from the work of Schilit [Schilit,94] and Brown [Brown,97] on context-sensitive computing.

The key strategic decision we have taken is to design our system based on a distributed cellular architecture. In particular, all of the information required is broadcast by cell base-stations to portables either as part of a regular schedule or in response to user requests (see figure 1 below).

Figure 1 : The Guide Architecture

The obvious alternative to this approach is to develop essentially stand-alone portable end-systems which have all of the information they require pre-installed as typified by, for example, the Cyberguide project [Long,96]. This approach is likely to have performance benefits since it does not rely on wireless networking. However, we believe this approach is limited and unlikely to be adopted in the long-term for two reasons. Firstly, our requirements study has highlighted the need for interactive services which require a communications link to the portable end-systems (see section 2). Secondly, investment by companies such as Sun in developing low-cost specialised web-clients (which are expected to retail for less than $500) makes it possible to envisage that in the medium term portable versions of these machines will be widely available. These will make ideal GUIDE units by being both cheaper and consuming less power than stand-alone PCs.

Based on their location and user preferences the end-systems receive information tailored to their current context. Information for a given geographic area is held at specific base-stations hence enabling the system to scale adequately and obviating the need for high-performance communications links between the base stations. Support for interactive services and time critical information is provided by both fixed and wireless links between the base-stations and the tourist information centre.

In this paper we present the results of our requirements analysis and early development work on the GUIDE system. In particular, we focus on the requirements for the end system’s user interface and highlight a number of key issues which remain to be addressed.

We have derived a set of requirements for the GUIDE system through a process of semi-structured interviews with members of Lancaster's Tourist Information Centre (TIC) and observation of the workings of the tourist office over a period of several days. In order to scope the development of the GUIDE system we have decided to focus on requirements in the following three categories.

By supplying city visitors with a GUIDE end-system we hope to address each of these requirements. More specifically, the electronic nature of GUIDE should enable the system to offer greater flexibility than conventional pre-printed information sheets. In addition, the network-based architecture we have adopted should enable us to keep visitors up-to-date with dynamic information and offer interactive services such as accommodation booking.

We are in the process of developing the GUIDE system to address the above requirements. In designing our system a number of key user interface issues have arisen. In particular, the integration of physical and virtual contextual information places new demands on user interface design techniques and toolkit components. In the following section we discuss the requirements for the GUIDE user interface as motivated by three main areas of concern: physical and environmental, user and application oriented and contextual awareness.

By its very nature the GUIDE system must be sufficiently portable to enable it to be carried and used by city visitors for extended periods of time. As a consequence, the display area available for the user interface is limited: anecdotal evidence suggests that devices of similar proportions to today's notebooks will be unacceptable to end-users in this application domain. In addition, since the system is designed primarily for use outdoors, the interface must be visible under a range of lighting conditions and, because many visitors travel in groups, from a variety of viewing angles. Given the limitations of current display technologies the possibility of using an entirely audio based interface must be considered, though such an approach is not, of course, without problems. The requirement for outdoor use also implies that the end-system must be relatively robust and weather-proof enough to survive everyday use. This in turn places restrictions on the type of end-system, and consequently user input and presentation technologies, which can be used.

As discussed in section 2, the GUIDE system is designed to support a wide range of users and information requirements. This clearly demands a system which can be quickly tailored to meet the needs of the end-user. While tailorable user-interfaces have become commonplace in commercial applications these tend to support a relatively narrow cross-section of users and such approaches are unsuitable for use in GUIDE. One possibility is to design a number of different user interfaces, with each interface designed to suite a particular class of user. For example, there could be one user interface to suite those visitors who are not familiar with browsing the web and do not require web browsing functionality on their tour of the city.

Furthermore, the GUIDE system must support both information retrieval style applications and interactive services within an integrated environment while subject to the physical and environmental considerations described in section 3.1.

The GUIDE end-systems are required to react to changes in their environment. In particular, as users move around the city of Lancaster they require information which is relevant to their physical location. Furthermore, this information may replace existing information with which they have been presented. The implication of this for the design of the user-interface is significant since it raises the problem of integrating changes in physical location with changes in information within the system. For example, if the GUIDE system provides a button labeled local attractions one might intuitively expect this to provide information relative to the area in which the user is currently located. However, users accustomed to web based systems are likely to be confused by a system in which returning to previously visited pages does not provide the same information. Furthermore, since a user might wish to check out the attractions local to their destination rather than their current location a means of simulating changes in their physical location must be included and supported by appropriate navigation tools.

Although development work on the GUIDE project is still on going, the project has made a number of advancements and the system is now starting to take shape. In particular, the project has established a suitable portable end system, designed a basic GUIDE infrastructure, developed a prototype client application and deployed a small number of cells.

We have considered a wide range of end-systems for use in GUIDE including pen-based tablet PCs and PDAs. The selection process has been complicated by the need to balance a wide range of factors relating to the end-systems and their development environments. For example, the Apple MessagePad 2000 [Apple,97] was a strong contender because it includes support for sound, is of compact dimensions and has an easily visible display. However, its relatively low-resolution display and the poor quality of MessagePad development tools (as compared to Windows based products) counted against it. In addition to the usability issues discussed in section 2 our selection criteria was also motivated by the need to opt for a system which could accommodate a PCMCIA WaveLan [WaveLan,97] card for communication and a GPS compass for additional positional information.

As a result of our analysis we selected the Fujitsu TeamPad 7600 [Fujitsu, 98] as the GUIDE end-system. This is a compact unit measuring 8"x9"x1.5", is based on a 486 100 Mhz processor and has been ruggedised to withstand drops from approximately 4 feet onto concrete. The relatively poor performance of the processor is of little concern to us since we are not anticipating running CPU intensive tasks. Furthermore, the modest power requirements of the processor enable the unit to function for over ten hours on a single 3"x2"x1.5" battery. Initially it was hoped to use a full colour, TFT based, version of the TeamPad. However, on evaluation, the colour unit proved to be practically unreadable when used out of doors in direct sunlight. Fortunately, a greyscale version of the TeamPad is soon to be released, utilising a transflexive screen. This screen provides a very high contrast display that is readable even in direct sunlight. The other benefit of this display technology is that it provides a very wide viewing angle thus enabling a number of people to read the Guide’s display.

The current prototype GUIDE system utilises the cell based method for realising the current location of the city visitor. However, due to the limited accuracy provided by this method (and the fact that the user may wander into areas without cell coverage) later versions of GUIDE will also use the DGPS based solution.

The design of the GUIDE communications infrastructure was influenced by the following factors:

Following the analysis of these factors it became clear that the familiar request-response, unicast method of data delivery is inappropriate. Instead, the GUIDE system implements a broadcast protocol to provide server-push based data delivery and interactive services.

The broadcast protocol is being designed to replace TCP as the means of communication between clients and servers. In more detail, the protocol builds on previous work on broadcast disks as a means of disseminating data [Acharya,95], [Acharya,97] to allow the system to effectively support a large number of clients within each network cell whilst making efficient use of the available bandwidth. In addition to enabling the system to scale, this approach has two further advantages. Firstly, it obviates the requirement to support Mobile-IP [Johnson,96] since clients can receive information anonymously. Secondly, we avoid the well documented problems associated with using TCP in a wireless environment [Caceres,94].

The broadcast cycle can be considered as a number of slots, each of which provides data to the end user. Information is broadcast according to a schedule which is itself broadcast at frequent intervals. The broadcast schedule will be created dynamically based on: the type of information to be broadcast and the priority of the data item. By examining the schedule for forthcoming transmissions of interest, clients are able to conserve power by electing to await future broadcasts rather than transmitting explicit requests. The broadcast protocol includes spare time-slots in which clients can choose to either transmit a request for information (if the information they require has not already been scheduled for transmission) or to communicate with the base stations as part of an interactive service session. The use of the broadcast protocol is transparent to both clients and servers.

The diagram below (figure 2) shows how the GUIDE communications infrastructure.

Figure 2 : The Guide Software Architecture

On the server side, the server agent receives DGPS corrections, HTML pages from an Apache HTTP server (running under Linux) and provides a consistent interface to the underlying broadcast protocol and scheduler. This scheduler is used to control the transmission of data across the wireless link to mobile users. The broadcast schedule dynamically schedules the next item to be broadcast based on criteria such as the type of information to be broadcast and its priority. For example, due to its time critical nature DGPS corrections will take priority in the broadcast cycle over an HTML page broadcast.

On the client side, the client agent performs a similar role to that of its peer. The client agent is responsible for caching data received from the broadcast protocol and its primary aim is to ensure that data relevant to the user, based on their user profile, always remains in the local cache. This enables users to have access to some services even in the event of the user becoming disconnected.

An initial client application has been developed which provides visitors with access to Guide services and the ability to perform traditional web browsing. The application was constructed using Microsoft ActiveX components and has a user interface resembling a traditional web browser. The interface required a number of modifications in order to enable users to access specific areas of GUIDE functionality, such as the route guidance service. One of the key issues when designing the user interface for the application was deciding how closely to mimic the traditional web browser. The advantages of strongly basing the user interface on that of a web browser is that people familiar to web browser should find the interface quite familiar and easy to use. However, the disadvantage of this approach is that users familiar with typical browsers might assume a certain level of functionality and overlook the enhanced features provided by the GUIDE system.

A screen display showing the design of the current prototype application’s user interface is shown below in figure 3.

Figure 3 : The Guide Prototype

The application’s display window is divided into a number of areas each focusing on specific areas of functionality.

The top left area of the window contains controls for enabling the user to obtain general tourist information. More specifically, the user can ask to see a summary of their current location, information on forthcoming events, information on places of interest that are close to their current location or a map of the area. The area at the top centre of the window provides the user with controls for accessing GUIDE’s interactive services, namely requesting information on the city’s cinema and reserving accommodation. The controls at the top right of the window provide standard web page navigation functions, namely, go to previous page, go to next page or reload and redisplay the current page.

The main, central, area of the window is used for displaying information which clients request or which is acquired on their behalf. For example, this area is used to display any web pages which have been explicitly requested by the city visitor and is also used to display tour guidance information when needed.

The bottom left area of the window is used to present the user with dynamic information, such as the user's current location and local news and traffic information. When a visitor enters a new cell this is reflected by an update to this area of the display. The visitor may then choose to update their main display area to provide more information on this location. Controls for activating GUIDE’s route guidance services are located at the bottom right of the application’s window.

The currently adopted user interface is clearly unsatisfactory since there is significant potential for users to become confused when reading information pertaining to a cell in which they no longer reside. However, the alternative of automatically updating the central display area as the user moves could give rise to the situation in which the information a user is currently reading is overwritten and the user has to physically retrace their footsteps to trigger the previous page to be reloaded (the equivalent of pressing the back button on a conventional browser).

We are currently in the process of deploying cells within the city of Lancaster in order to enable us to field trial the GUIDE system. Currently four cells have been deployed although the final system will comprise over ten separate cells each with a link back to the Tourist Information Centre via either a wired or wireless link.

The proposed cell deployment map can be seen below in Figure 4.

Figure 4 : Proposed Guide Cell Deployment

The placement of cells has not been an arbitrary process, rather the cells have been placed so that they cover areas of interest e.g. the castle. By placing each cells’ WaveLAN transceiver at an appropriate geographic location it has been possible to limit each cells coverage to that required. The actual area covered by a cell depends on the cell environment and the height of the WaveLAN transceiver. For example, in a flat environment with the transceiver placed at a height of approximately three feet the cell has a coverage radius of approximately five hundred metres. However, in a built up city environment, the area of coverage would be greatly reduced. This is because, given its operating frequency, WaveLAN signals are unable to pass through solid concrete walls.

In this paper we have described our on-going development of a context sensitive tourist guide for visitors to the city of Lancaster. The requirements for such a guide have been presented and we have outlined the case for adopting a distributed cell-based approach to meet these requirements. The implications for user interface design of meeting such requirements have also been discussed under three main headings: environmental considerations, user and application requirements and support for contextual awareness. Finally, we have presented our initial prototype of the GUIDE system and highlighted a number of shortcomings of the system.

The GUIDE project will deploy a significant number of cells throughout the city of Lancaster and is required to conduct a field trial involving real end-users at the end of the project. The issues we have discussed remain to be addressed and input from members of the research community with respect to the design of the GUIDE user interface would be most welcome.

[Acharya, 94] Acharya, S., R. Alonso, M. Franklin, and S. ZDonik. "Broadcast Disks: Data Management for Asymmetric Communication Environments", Brown University. December.

[Acharya, 97] Acharya, S., M. Franklin, and S. Zdonik. "Balancing Push and Pull for Data Broadcast." Proc. ACM SIGMOG, Tuscon, Arizona,

[Apple,97] http://www.newton.apple.com/newton_overview/newton_overview.html.

[Brown, 97] Brown, P.J., J.D. Bovey, and X. Chen. "Context-aware applications: from the laboratory to the market place." 4 No. 5, Pages 58-64.

[Cáceres, 94] Cáceres, R., and L. Iftode. "The Effects Of Mobility on Reliable Transport Protocols." Proc. 14th International Conference on Distributed Computer Systems (ICDCS), Poznan, Poland, Pages 12-20. 22-24 June 1994.

[Fujitsu,98] Fujitsu TeamPad Page. http://www.fjicl.com/TeamPad/teampad76.htm.

[Johnson,96] Johnson, D.B., and D.A. Maltz. "Protocols for Adaptive Wireless and Mobile Networking." IEEE Personal Communications Vol. 3 No. 1, Pages 34-42.

[Long,96] Long, S., R. Kooper, G.D. Abowd, and C.G. Atkeson. "Rapid Prototyping of Mobile Context-Aware Applications: The Cyberguide Case Study." Proc. 2nd ACM International Conference on Mobile Computing (MOBICOM), Rye, New York, U.S., ACM Press,

[Schilit,94] Schilit, B., N. Adams, and R. Want. "Context-Aware Computing Applications." Proc. Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, U.S.,

[WaveLan,97] http://www.lucent.com/netsys/systimax/catalog/WaveLAN_PCMCIA_Interface_Kit.html

[Weiser,93] Weiser, M. "Some Computer Science Issues in Ubiquitous Computing." Communications of the ACM Vol. 36 No. 7, Pages 74-84.