developing a context sensitive tourist guide - CiteSeerX

7 downloads 791 Views 106KB Size Report
Secondly, investment by companies such as Sun in developing low-cost .... HTTP servers running under Linux, a GUIDE client application and a specialised.
DEVELOPING A CONTEXT SENSITIVE TOURIST GUIDE Nigel Davies, Keith Mitchell, Keith Cheverst and Gordon Blair Distributed Multimedia Research Group, Department of Computing, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K. telephone: +44 (0)1524 594337 e-mail: [email protected]

1. PROJECT OVERVIEW 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 endsystems 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 behaviour in order to provide users with an intelligent visitor guide. Browser + new filters and transport mechanisms WWW server + new filters and transport mechanisms

Internet traffic

Communication via WaveLAN ‘microcells’

Figure 1 : The Guide Architecture 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 (see figure 1). 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. 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 user interface for the system and highlight a number of key issues which remain to be addressed.

2. APPLICATION REQUIREMENTS 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. (i)

Flexible Tour Guide The GUIDE system will act as a tour guide for visitors to the city. After studying the different demands visitors make of a tour guide it has become apparent that flexibility in this area is critical. For example, visitors to Lancaster often request city tours or trails reflecting interests as diverse as history, architecture, maritime activities, cotton production and antique dealerships. Furthermore, this information is required at many different levels: from academic scholar to primary school child and in a range of languages. Additional factors which affect a visitors choice of tour/trail include the geographic area to be covered, the duration of the tour, the budget of the visitor (to cover entrance fees etc.), refreshment requirements, availability of different forms of transport and any other constraints, such as wheel chair access.

(ii)

Dynamic Information During our study we found a significant requirement for dynamic information to be made available to visitors during the course of their stay in Lancaster. For example, Lancaster Castle is available for tours only when the court is not in session. Since this can change on an hourly basis depending on trial durations and defendants' pleas such information can not be supplied by the TIC in advance. Further examples of dynamic information include local weather and traffic news, special events and average waiting times at local attractions.

(iii) Support for Interactive Services Studying tourist activities in Lancaster reveals that a surprising number of visitors make repeat visits to the TIC, often during the course of a single day. In most cases this is because they require additional information on activities or landmarks, they have specific questions which require interaction with a member of the TIC, or they wish to make use of a service offered by the TIC, most commonly the booking of accommodation. 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 and 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.

3. USER INTERFACE ISSUES 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.

3.1. Physical and Environmental 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.

3.2. User and Application 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 relative narrow crosssection of users and such approaches are unsuitable for use in GUIDE. 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.

3.3. Context-Awareness 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 labelled local attractions one might intuitively expect this to provide information relative to the area in which the user is 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.

4. STATUS 4.1 End-System Selection We have considered a wide range of end-systems for use in GUIDE including penbased 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 was a strong contender because it includes support for sound, is of compact dimensions and has an easily visible display. However, its lack of support for colour and the poor quality of MessagePad development tools (as compared to Windows based products) counted against it. In addition to the useability issues discussed in section 2 our selection criteria was also motivated by the need to opt for a system which could accommodate a PCMCIA Lucent WaveLAN card for communication and a GPS compass for additional positional information. As a result of our analysis we selected the Fujitsu TeamPad 7200 as the GUIDE endsystem. 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 slow speed of the processor enables the unit to function for over ten hours on a single 3"x2"x1.5" battery. Further details on the TeamPad can be found at [Fujitsu, 98].

4.2. Application Development The GUIDE system comprises the following software components: standard Apache HTTP servers running under Linux, a GUIDE client application and a specialised broadcast protocol.

The broadcast protocol is 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 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]. Information is broadcast according to a schedule which is itself broadcast at frequent intervals. 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. Development work on the GUIDE client software is at an early stage (see figure 2). The” overall system is based on current WWW technology and the interface has been constructed using Microsoft ActiveX components.

Figure 2 : The Guide Prototype The screen display is divided into a number of areas. The uppermost area contains the navigation controls. These reflect the application domain and are more specialised than standard browser controls (e.g. buttons to view local attractions). The second (i.e. central) screen area provides the main area for information display. Information which clients request or which is acquired on their behalf, for example as part of a guided tour, is displayed in this area. The final screen area displays dynamic information such as new information updates and the user's current location. When a user enters a new cell this is reflected by an update in the third area of the screen. They may then choose to update their main display area (area two) to provide more information on this cell or they may continue to read the information already displayed. This solution 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).

4.3. Cell Deployment 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. The final system will comprise ten separate cells each with a link back to the Tourist Information Centre via either a wired or wireless

link. To date we have surveyed three sites and these cells will be deployed by the time of the workshop.

5. CONCLUDING REMARKS In this extended abstract 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 cellbased 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.

REFERENCES [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, [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 Technical Page. http://www.fjicl.com/TeamPad/teampad72.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., [Weiser, 93] Weiser, M. "Some Computer Science Issues in Ubiquitous Computing." Communications of the ACM Vol. 36 No. 7, Pages 74-84.

Suggest Documents