Exploring Context-aware Information Push. Keith Cheverst, Keith Mitchell and Nigel Davies. Distributed Multimedia Research Group, Department of Computing, ...
Exploring Context-aware Information Push Keith Cheverst, Keith Mitchell and Nigel Davies Distributed Multimedia Research Group, Department of Computing, Lancaster University, Lancaster, UK
Abstract: Despite much interest over recent years in the area of context-aware computing, there are still a number of significant gaps in our understanding of the HCI issues associated with such systems. One particular issue that remains relatively unexplored is how to design around the apparently conflicting goals of adapting to changes in context while at the same time adhering to the principle of predictability. In this paper, we describe our exploration into this issue through two alternative designs of an interactive context-aware tourist guide. One original design was based around information pull, i.e. the emphasis is on the user to decide when context-aware information is presented. Our second design incorporates the notion of information push whereby the actual presentation of context-aware information is triggered by contextual events, e.g. changes in the user’s location or changes to the opening times of attractions. Through the evaluation of these alternative designs we hope to gain a better understanding of the usability implications relating to push vs. pull in both this specific domain and in interactive context-aware systems in general. Keywords: Context aware; Evaluation; Information pull; Information push; Interaction design; Mobility
1. Introduction
276
One of the fundamental attributes of contextaware systems [1,2] is that they react not only to the user’s input but also contextual events from the user’s environment. For example, the classic location-aware system utilises location in order to tailor the information presented to the user. The inherent problem with any such system is that designers need to carefully balance the way in which the system reacts to environmental triggers (e.g. location) with a desire for the system to behave in a predictable manner and adhere to the principle of least astonishment [3]. Consider, for example, the location-aware visitor guide [4]. There are two key alternative approaches that could be adopted when the user changes location. The first approach would be to push [5] the location-aware content to the user in order to reflect his or her new location. This approach could surprise the user with the timing of the presentation or possibly overwrite the content that the user was currently engaged in reading. The second approach would be to wait for the user to pull the location-aware content. The implication with this approach is that the system would leave the currently displayed content unchanged, despite the fact that the content may have become inconsistent with the user’s current location. Furthermore, the designer needs to consider what kind of user notification
Ownership and Copyright # Springer-Verlag London Ltd 2002 Personal and Ubiquitous Computing (2002) 6:276–281
mechanism may be required in order to prompt the user to pull the new content. The problem of designing systems that react to context is compounded when one considers that location may not be the only dynamically changing contextual trigger to occur. For example, if the state of a tourist attraction (i.e. whether it is currently open or closed) is used as context then the designer needs to consider what action should be taken when this piece of context changes. In this paper, we use the GUIDE system [6,7] as a research vehicle to explore these pertinent issues. As part of this exploration, we utilised a field-trial evaluation in order to investigate and study the reaction of city visitors to the two fundamentally different approaches, i.e. information push and information pull. In particular, our aim was to investigate the potential benefits of information push, (e.g. a reduction in user effort when retrieving information) together with the likely negative aspects of this approach, e.g. the potential for unexpected behaviour and reduction in user control.
2. Background When designing any technology to support a tourist’s exploration of a city, one needs to recognise that the primary aim of the technology should be to assist the visitor in experiencing the
real city. Clearly, the technology should not consume too much of the user’s attention and effort. An initial evaluation of the pull-based version of the GUIDE system (documented in Cheverst et al. [7]) revealed that visitors generally enjoyed using the system to explore the city. However, one of the limitations of the initial system and its subsequent evaluation is that it did not consider how a push-based approach could be used to reduce the effort required by the user to access information using the system. 2.1. GUIDE’s pull-based approach The original GUIDE system only considered one approach for managing the presentation of context-aware information. More specifically, the approach was ostensibly based on information pull whereby the onus would be on the user to request the presentation of context-aware information by, for example, tapping on the information button. This pull-based approach was adopted for a number of reasons. First, the approach seemed the safest way to prevent visitors spending too much time focussed on the GUIDE display, i.e. poised waiting for new information to appear. Secondly, the approach seemed to match the kind of interaction that takes place when using a guidebook for the task of exploring and learning about a city. In this case the visitor retrieves (or pulls) information for a given attraction by turning to the appropriate page in the guide. In essence, our system used context to simplify the retrieval task by using the visitor’s current location in order to pre-empt the appropriate page of information. However, the guidebook approach has problems when one considers the handling of dynamic information because the user expects the information to remain constant. The pull-based approach also fitted well with a standard web-based browsing metaphor/interaction model. To adhere to this metaphor a refresh button was incorporated in the system’s GUI. When roaming into a new area, users were required to press this button to cause the system to display information pertaining to their new location. However, the field-trial revealed that many visitors were unsure of when the button should be pressed. In addition to using the system as a guidebook, a tour-guide mode was also supported [8]. In this mode of operation, the system would
Fig. 1. The visual notification window.
guide the visitor on a structured tour, by presenting the visitor with a series of instructions assisting him or her to navigate from their current attraction to the next attraction in the created tour. However, once the visitor arrived at the next attraction in the tour, the system did not demonstrate any proactive behaviour. Instead, the system would effectively fallback to guidebook mode and wait for the user to tap the information button in order to retrieve information pertaining to their current location. The only real exception to the original system’s pull-based approach was the incorporation of a visual notification window which would notify the user of their current location, as shown in Fig. 1. However, the cell-based approach for sensing location meant that the accuracy of the information presented was often approximate and therefore of limited utility to the visitor. 2.2. Analysis Analysing the role of information pull in the original system identified the following two key points: . The asynchronous nature of information pull meant that the information displayed to a user can become inconsistent with his or her current context. For example, if the information currently displayed on the GUIDE unit states that the user is standing next to the castle, but the visitor has since moved away from the castle to the priory, then, the presented information will have effectively become inconsistent with the current context, i.e. location. Furthermore, a change in context may relate to context other than location, e.g. a change to the opening time of an attraction. Communicating such context changes were not investigated in the original version of the system, but clearly raise many interesting issues that demand investigation. . The stimulus used to invoke the presentation of new information comes directly from the user and therefore the user is already focussed on the system when the new content is presented. Consequently, the user’s current
Exploring Context-aware Information Push
277
278
task, e.g. enjoying a view, is not interrupted or disturbed by the presentation of contextaware information. However, clearly some tourists do choose to follow tour guides who effectively push (albeit verbally) information to the user based on the current location. It is, therefore, a shortcoming of the original system that this push-based approach was not explored. In particular, it is important to explore the usability issues associated with information push vs. information pull and any additional infrastructure requirements for supporting information push. For example, to what extent is the cell-based location granularity supported by the original GUIDE infrastructure suitable for providing triggers that are sufficiently accurate to act as stimuli for information push. . During the field-trial of the pull-based GUIDE system, a number of users commented that occasionally they would forget the action required in order to retrieve information using their GUIDE unit. Clearly, this failing could be attributed to poor interface design and the fact that user’s were required to remember to press the information button to pull information about their current location. However, the fact remains that when certain visitors were in the midst of exploring the city, expecting them to remember the need to press a specific button on the GUI was not always realistic.
3. Exploring Information Push To investigate the usability issues associated with information push, we developed a push-based version of the GUIDE client application. This version was developed for the original GUIDE end-system and designed in such a way that it would listen for contextual triggers, namely location beacons representing the user’s vicinity to a particular attraction. Furthermore, on hearing a trigger the application would react by presenting the user with a hypermedia page describing the relevant attraction. 3.1. Design decisions One of the key implications of following a strict information push approach is that the act of pushing new content to the user could result in the overwriting of content currently being read.
K. Cheverst et al.
Fig. 2. Alerting the user to new information awaiting presentation.
We considered two basic solutions to help overcome this potential problem. The first solution simply involved the use of the back button (already present on the original GUIDE user interface) in order to allow the user to retrieve the previously displayed information. The second solution involved introducing an additional hold feature. This feature enables the user to force the currently displayed information to remain on the screen despite any changes in context that may occur. However, in order to alert the user to the fact that some context had changed, we incorporated a new awareness icon into the GUI in the form of a waving flag (see Fig. 2). This animated icon serves to inform the user that by pressing the update button new content will be displayed reflecting the changed context.
4. Evaluation The primary aim of our evaluation was to conduct an initial exploration of the acceptability of pushing information, (e.g. descriptions or announcements) to city visitors using both audio and visual modalities. The evaluation also had two secondary aims. First, to ascertain the reaction of visitors to a GUIDE system based around the relatively small and light Compaq iPAQ. Secondly, to gain a better understanding for the granularity of location accuracy required for triggering information push. 4.1. Approach To a large extent, our evaluation approach built on our experiences of the field-trial conducted on the pull-based version of the GUIDE system. In particular, in the original field trial we found that encouraging visitors to adopt a talk-aloud protocol while using the system had worked well and so we chose to continue with this techniques. Once again, imposing on the leisure time of
visitors by asking them to take part in our trial was an issue and so kept the length of sessions flexible and used semi-structured interviews to ascertain the opinions of volunteers. However, unlike the previous field-trial, on this occasion we were forced to utilise some ‘wizard of oz’ techniques in order to investigate certain issues because we did not have the location sensing infrastructure in place to support the deployment of a fully working version. In particular, we assumed that we had, in place, an infrastructure capable of providing the ideal location granularity and that from this information we could ascertain a good estimation of the visitor’s current direction of travel. Our approach was reasonably straightforward with the evaluation team comprising just two members. One person was responsible for shadowing the volunteer and listening to his or her comments. It was the duty of the other person to carry a laptop computer and cause the triggering of information push to occur on the tourist’s GUIDE unit (a Fujitsu teampad). This was simply achieved (but the mechanism not revealed to tourists) by establishing a wireless 802.11 connection between the tourist’s GUIDE unit and the laptop computer. Although we implemented a push-based client application on the teampad we did not construct such a system on the iPAQ. Instead, we constructed a number of mock-up interfaces which utilised different screen orientations and scrolling techniques and different notification sounds for signalling the push of information. Volunteers were asked to rate the different notification sounds and comment on the preferred interface design. During the semi-structured interview volunteers were also asked to comment on which of the two units they preferred. 4.2. Findings At the end of the two-week field trial (held in the summer of 2001), 20 visitors to Lancaster had acted as volunteers and evaluation sessions with volunteers had lasted an average of twentyfive minutes. 4.2.1. Visitor’s acceptance of information push Visitors’ general comments: from an early stage in the field-trial it became apparent that volunteers were showing significant enthusiasm for the push-based approach. Many of the
comments made by visitors, e.g. ‘‘We are lazy’’, ‘‘Don’t want hassle’’, speak for themselves and highlight the importance of questioning any design feature that increases the effort required on the part of the user. It was interesting to observe the reaction of visitors to certain features that we had put in place to increase usability. For example, we asked users for their comments regarding the hold feature which, as described earlier, could be used to prevent information from being overwritten while it was still required by the user. Although, all those asked could see the merits of such an approach, several expressed concern that even this relatively simple feature would add too much complexity to the interface. The majority felt that the use of the existing back button would be sufficient for the task of retrieving overwritten information as and when required. Another interesting comment made during the trial: ‘‘Only tell me if I take a wrong turn’’, encouraged us into thinking that the system could be designed to use location context as a trigger to push navigation information to visitors while following a tour. In more detail, one volunteer suggested that, the system could adopt a more guardian role by only prompting the user if they actually started to make a navigational error, e.g. started to take a wrong turn. In this way, the system might act to reassure the user in their current task, and this is a property that will hopefully be explored in the design of future context-aware systems. Another visitor made the comment: ‘‘I don’t want to appear as a tourist in a non-tourist location’’. This comment implies the need for the user to trust the system and highlights the migration of power away from the user when adopting a push-based approach. One implication of this is that the user must place extra trust in the system. For the visitor who made the comment, her concern was that the system might decide to push to her information while in a location where she did not wish to appear as a tourist, e.g. walking along the high street. Visitors’ reaction to pushed audio: we were surprised by the level of enthusiasm expressed by visitors when we demonstrated the pushing of audio descriptions using the iPAQ. However, at this point in the trial, we started to feel a little concerned that perhaps all the visitors really wanted was an outdoor version of the audio-only location-aware ‘guidebook’ currently available in
Exploring Context-aware Information Push
279
280
certain museums. With this in mind, we asked visitors whether they would swap the iPAQ for a much smaller unit offering only an audio capability. It was interesting (and perhaps a little relieving) to observe that out of the twenty visitors asked, not one was prepared to forgo the visual experience for a smaller, lighter, audioonly unit.
Castle . . .’’ or ‘‘Over here you can see Lancaster Castle . . .’’. Of course, this kind of interaction assumes knowledge of the visitor’s orientation and such context would certainly be of great utility when implementing a push-based system.
4.2.2. Comparison of end-systems During the initial field-trial of the GUIDE system, visitors appeared to be perfectly content with the GUIDE end-system, i.e. the Fujitsu teampad. In more detail, the majority of the sixty visitors questioned expressed the opinion that the dimensions of the unit were quite reasonable and that they did not wish for anything smaller (although a small number mentioned that a slightly thinner unit would be preferable). However, in this latest field-trial, when we asked visitors to compare the Compaq iPAQ with the Fujitsu teampad the reaction was quite remarkable. Visitors showed an overwhelming preference for the iPAQ as an end-system, stating that the teampad appeared ‘old’ and ‘clumsy’ in comparison.
One likely explanation for the high level of acceptability for information push is the fact that visitors are acting in an information gathering mode. Indeed, the motivation of the vast majority of visitors interviewed has been to learn as much about the city in the short period of time available. When this motivation is combined with the desire of visitors for a minimum of ‘hassle’ then it is perhaps not surprising that the pushing of information was treated with such enthusiasm compared to a purely pull-based approach. However, it is important to note that a significant number of visitors did appreciate the benefits of a pull-based approach. One clear area of future work is therefore to experiment with designs that combine the two approaches at the correct level. We intend to experiment with the development of such designs using end-systems based around the iPAQ form factor. It is likely that one of the major challenges will be finding ways of reducing the user’s demands on the restricted screen real estate by utilising other input and output modalities. In particular, we intend to investigate the extent to which a speech-based command interface can be utilised in addition to tactile input. Given the current processing power of PDAs one implication of this approach may be the necessity to perform some or all of the speech processing over the network.
4.2.3. Required granularity of location information When using location to trigger an information push, such as an audio description of a particular tourist attraction or object, the granularity of the location accuracy required to trigger the push is not the same across all possible attractions. More specifically, the location granularity required by the system to trigger an information push relating to a particular object corresponds directly to the nimbus [9] of the object in question. Hence, the smaller the size of the object’s nimbus the finer the location granularity required by the system to trigger the push. To push the description at an appropriate time, one approach would be to push the description of an object when the focus of the visitor first intersects with the nimbus of the object [10]. For example, the system could start describing Lancaster Castle when it first comes into the visitor’s visual focus (i.e. field of view). However, in order to accurately gauge the visitor’s visual focus the system would require some means of detecting the visitor’s visual focus. Traditionally, a tour guide will direct the focus of the visitor(s) with statements, such as, ‘‘If you look to your left you will see Lancaster
K. Cheverst et al.
5. Analysis and Future Work
6. Conclusion There is an interesting conflict that faces the designers of interactive (mobile) context-aware systems. Essentially, this conflict results from the aim to tailor or adapt the presentation of information based on the current context while at the same time designing systems that adhere to the principle of least astonishment. In this paper, we have described the results of our initial exploration of a push-based approach, in which the changes to the information
presented to visitors to the city of Lancaster are triggered by changes in their current location. More specifically, as a visitor approaches an attraction, his or her display adapts to reflect this fact by presenting information on the attraction. From the initial study, four key conclusions have arisen: . When developing a system for city visitors a key design goal should be to develop a system that offers ‘pick up and use’ usability and learnability. The findings of this study indicate that adopting a push-based approach towards information dissemination is one useful technique that may be employed in order to help achieve this goal. . The results of previous field-trials in this domain age rapidly especially where hardware is concerned. The ‘teampads’ that were considered perfectly acceptable two years ago are now considered clumsy and old fashioned. These will no doubt be the adjectives used in two years time to describe the current range of ‘shiny’ PDAs. If the move is towards smaller devices then different interaction paradigms will need to be developed in order to cope with further reductions in screen real estate; context-aware push may be one such paradigm. . Multimodal interaction with mobile information services, such as services to support tourists, is likely to become an extremely important interaction paradigm. Indeed in the experiment conducted as part of this field trial users were very positive about the pushing of audio descriptions. However, it is important to highlight the fact that users were adamant about the need to maintain a highly visual experience. . The granularity of location context required for supporting information push in the tourism domain varies depending upon the object being described. For example, the granularity afforded by 802.11 cells is fine for providing the trigger to push the description: ‘‘You are approaching Lancaster Castle. . . .’’. However, to trigger the description of an object with a much smaller nimbus, e.g. ‘‘This is one of the oldest signs in Lancaster . . .’’, requires a significantly finer granularity, such as that provided by a Bluetooth cell, or GPS (pro-
vided a sufficient number of satellites are in view). A system that uses location to trigger the pushing of information raises some interesting issues. If the user is unaware of the reason for the system behaving in the way it does then the system will appear unpredictable. However, with the push-based version of GUIDE users appeared to have formed a reasonably accurate mental model of the system’s behaviour, i.e. they soon learnt to expect information to be pushed to them as they approached an attraction. In this respect the system managed to afford the user with a very natural means of interaction and one in which the notions of push and pull clearly start to merge. References 1. Schilit B, Adams N, Want R. Context-aware computing applications. Proceedings Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, 1994, pp 85–90 2. Brown PJ, Bovey JD, Chen X. Context-aware applications: from the laboratory to the market place. IEEE Personal Comm 1997; 4(5): 58–64 3. Thimbleby H. User interface design. ACM Press, New York, 1990 4. Long S, Kooper R, Abowd GD, Atkeson CG. Rapid prototyping of mobile context-aware applications: the Cyberguide case study. Proceedings 2nd ACM International Conference on Mobile Computing, Rye, NY, ACM Press, 1996, pp 97–107 5. Franklin M, Zdonik S. Data in your face: push technology in perspective. Proceedings ACM SIGMOD Conference, 1998, pp 516–519 6. Davies N, Mitchell K, Cheverst K, Blair G. Developing a context sensitive tourist guide. Proceedings 1st Workshop on HCI and Mobile Devices, Glasgow, UK, 1998, pp 64–68 7. Cheverst K, Davies N, Mitchell K et al. Developing a context-aware electronic tourist guide: some issues and experiences. Proceedings CHI’00, Netherlands, ACM Press, 2000, pp 17–24 8. Davies N, Cheverst K, Mitchell K. Using and determining location in a context-sensitive tour guide. IEEE Computer 2001; 34(8): 35–41 9. Benford S, Fahlen L. A spatial model of interaction in large virtual environments. Proceedings ECSCW’93, Kluwer Academic, 1993, pp 109–124 10. Cheverst K, Smith. G. Exploring the notion of information push and pull with respect to the user intention and druption. Proceedings International Workshop on Distributed and Disappearing User Interfaces in Ubiquitous Computing, 2001, pp 67–72 Correspondence to: K. Cheverst, Distributed Multimedia Research Group, Department of Computing, Lancaster University, Lancaste, LA14YR, UK. Email: kc@comp. lancs.ac.uk
Exploring Context-aware Information Push
281
