Where to go and what to do, in the limited amount of time available, are common problems encountered by tourists when visiting a city for the first time. In effect, cities are large information spaces, and in order to navigate these spaces visitors often require numerous guidebooks and maps. However, because guidebooks are general-purpose references, they tend to contain a significant amount of information of little relevance to the interests of a particular individual. When considering the design of a hypermedia system for supporting the information needs of city visitors, the use of “adaptive hypermedia” appears the obvious choice for tailoring the information to the interests of the visitor. However, to meet the requirements of this particular application domain, the traditional approach of using a user model as the sole means for driving adaptation is not sufficient. Indeed, GUIDE represents an example of a visible application stream in adaptive hypermedia research, one in which applications are context-aware [3, 10] and able to use context, such as the user’s current location, to adapt the presentation of hypermedia. Examples of other applications in this stream include [5] and [7].
The GUIDE project [4, 6] has been developed to provide city visitors with up-to-date and context-aware hypermedia information while they explore the city of Lancaster in England. Visitors view this information via a handheld GUIDE unit based on the Fujitsu TeamPad 7600 tablet PC, which measures 213x153x15mm, weighs 850g, and is powered by a Pentium 166MHz processor.
In GUIDE, the adaptive hypermedia presented to visitors is tailored to both environmental context (the major attractions in the city) and the visitor’s personal context. Examples of the personal context used to drive the adaptation process include the visitor’s current location, the visitor’s profile (that is, the visitor’s interests), and the set of attractions already visited. This latter piece of context enables pages of information to reflect those attractions the visitor has already seen. For example, if visitors make a return visit to Lancaster Castle, they are welcomed back. Oberlander [8] uses the term “coherence” to describe the tailoring of information in this way. A field trial-based evaluation of the GUIDE system [4] found the response of visitors to such anthropomorphic behavior [9] to be reasonably positive, with some visitors expressing that they felt “reassured” by such behavior when exploring an unknown city.
During the system’s field trial, we observed that users with previous web experience found the interface reasonably intuitive.
The requirement for presenting information tailored to both the visitor’s personal context and the environmental context was gained during a period of requirements capture involving experts in the field of tourism at the city’s Tourist Information Center. An additional requirement was to support dynamic information, such as changes to the advertised opening and closing times of attractions.
At an early design stage, we chose to support the GUIDE system using a cell-based wireless networking infrastructure. Furthermore, for reasons of scalability, we chose to adopt a broadcast-based approach to information dissemination [1]. Each mobile GUIDE unit is equipped with an 802.11 wireless networking card (see www.wavelan.com) and several 802.11 base stations have been deployed next to popular attractions around the city. These base stations are used to broadcast Web pages, dynamic updates, and coarse-grained positioning information (in the form of location beacons) to GUIDE units (see Figure 1).
In more detail, each base station acts as a server for a specific region of the city and has local storage and processing capabilities, enabling it to act as a proxy cache (mirror) to the central GUIDE Web server. This central server is responsible for ensuring that any updates to GUIDE pages are propagated to the base stations (cell servers). A visitor interacts with GUIDE through a local Web browser embedded within the GUIDE application. In effect, all HTTP requests are processed by a local Web proxy, which may, in turn, interact with other Java objects (such as a filtering component) to service the request [6].
The GUIDE system provides the city visitor with a range of functionality, including the ability to create tailored tours of the city and to access interactive services, for example, accommodation booking. In terms of information access, the system enables a visitor to request an overview of a particular attraction and to request a list of attractions that are close to his or her current location. A visitor who temporarily leaves cell coverage (and so loses the reception of location beacons) can inform the system of his or her current location via the GUIDE Locator service. This service presents the visitor with a series of street names and thumbnail pictures showing attractions in the vicinity of the visitor’s last known location. The GUIDE system can ascertain the visitor’s location within the city on the basis of the street name or picture the visitor selects. The visitor can also use the Locator service to explore locations within the city virtually.
The GUIDE user interface (see Figure 2) is based on a modified browser metaphor. During the system’s field trial, we observed that users with previous Web experience found the interface reasonably intuitive. For visitors without Web-browsing experience, a five-minute tutorial proved sufficient time to teach (the majority of) visitors to use all aspects of the system.
Hypermedia Adaptation in GUIDE
The clearest example of adaptive hypermedia in GUIDE is the Nearby Attractions page (see Figure 2). When generating this page, the system performs both a filtering task and an information visualization task. In more detail, the system uses the visitor’s current location and the location of attractions within the city to determine a subset of attractions for presentation. Next, the system uses additional context, such as the set of attractions already visited by the user, to sort the attractions such that those with less relevance appear further down the list. To support the generation of adaptive pages, the GUIDE system stores information in two different information models, a user model and an environment model (see the accompanying table).
The User Model. When visitors first receive their GUIDE unit, they may perform a short configuration task to specify their personal preferences (and initialize their visitor profile). This configuration task is achieved using a “wizard” type interface and the information is stored locally. In addition to enabling the explicit configuration of the visitor profile, the system also traces visitors’ page requests in order to (interactively) update their profile. For example, a visitor who makes several requests for pages that have been tagged as having a strong historic relevance may be asked if he or she wants their history interest rating to be increased. Our approach reflects that of other adaptive hypermedia systems (for example, the MetaDoc system [2]) by using both explicit and implicit (induction-based) techniques to form and modify a user model.
The vast majority of users want to invest as little effort as possible in navigating for, and then retrieving information about, attractions around the city.
The Environment Model. The environment model has been purposely built to store and represent information relating to attractions within the city [6]. Given the system’s requirements, it was necessary for the environment model to handle:
- Geographic information, which can be either expressed in geographic terms (“location a is at coordinates x, y“) or symbolic terms (“the Museum is in the Castle Hill area”).
- Hypermedia information, which can be either global (Internet-based) or stored locally.
- Active components, which are capable of storing and modifying their state (the opening time of the Castle).
To manage these distinct types of information, the environment model is based on the integration of an active object model with a hypermedia information model.
To support the authoring of adaptive pages, we enable authors to augment their pages with special GUIDE tags. These tags take the form of special instructions able to query both the environment and user models. In more detail, once the page containing a GUIDE tag has been retrieved from a server, or the GUIDE unit’s local cache, a local filter object is used to process the tag and replace it with the appropriate HTML code.
Figure 3 illustrates how the INSERT NEIGHBORS tag is expanded by the local filter object to dynamically generate the Nearby Attractions page (see Figure 2). The expansion involves two stages. In the first stage, the filter object queries the environment model in order to determine the set of attractions that should be considered nearby to the visitor’s current location, in this case the Tourist Information Center (abbreviated to “tic” in Figure 3). Next, the filter object queries each of the objects representing these attractions in order to retrieve the HTML code describing each nearby attraction.
In the second stage, the filter object uses information from the user model to determine the appropriate order for presenting the list of attractions to the visitor. It is important to note that our client-based approach for generating adaptive pages was strongly influenced by two separate requirements:
- Because GUIDE units must be capable of presenting tailored information despite occasional network disconnection, a significant portion of the environment model had to be cached locally.
- Because we use a broadcast-based approach for information dissemination, cell servers could not tailor and then transmit pages for individual clients.
Human Factors Issues. While evaluating the context-aware features of GUIDE, we encountered an interesting problem relating to the Nearby Attractions page. In more detail, an early version of this page filtered out all attractions that were closed because we wrongly assumed that visitors would only be interested in attractions that were currently open. When evaluating the system, we found this constraint frustrated some visitors who were interested in visiting an attraction regardless of whether it was open or closed; they simply wished to view the architecture of the building.
This anecdote highlights a potential problem with this kind of context-aware system and a problem generally discussed by Suchman [11], that is, the potential for a mismatch between the user’s goal and the “intelligent” behavior of the machine. In this example, the user’s actual goal was to explore the architecture of the building (be it open or closed), and the mismatch was that the GUIDE system assumed that to be worth visiting, the attraction would have to be open.
The anecdote also illustrates the potential dangers awaiting designers who are tempted to use environmental context to filter information as opposed to using the same context for performing some kind of information visualization task, for example, adapting the order in which items of information are presented.
Discussion and Future Work
Our experiences with developing, deploying, and evaluating the GUIDE system have provided us with some useful insights into the ways in which context (both user and environmental) can be used to trigger the adaptation of hypermedia information.
In our user studies, we have found the vast majority of users want to invest as little effort as possible in navigating for, and then retrieving information about, attractions around the city. By using context, such as the user’s location, we believe we have helped reduce this effort. One area of current work for the GUIDE system is to explore and compare the suitability of alternative user interfaces (for example, avatar-based) and interaction techniques (such as information push). As part of this work, we are experimenting with different end systems such as the Compaq iPAQ. Initial studies have revealed that, compared to the Fujitsu TeamPad, the iPAQ’s small form and light weight do indeed appeal to visitors, but the reduced screen size makes the design of an appropriate interaction model a real challenge.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment