A Context Taxonomy Supporting Public System Design

Abstract

Context awareness is the basis for a system's ability to adapt to changing conditions of its environment. This ability is especially important in the public domain where a variety of systems is used, so-called public systems. Public systems perform in public spaces and are available to all people, instead of focusing on specific user groups. They also often integrate many different devices. Thus, they need to be highly context-adaptive in many ways. However, it is very difficult to determine what context is. None of the existing definitions can serve as a guideline throughout the whole process of system development. Context relevant features need to be determined from scratch for each new system, making system design error-prone, costly and time-consuming. To support easy development of context-aware systems and applications, we propose a reusable taxonomy of context features for the public domain.

-

INTRODUCTION Ubiquitous technologies are highly applicable in spaces, where many people need to access certain services. The first vision of ubiquitous systems by Mark Weiser introduced the idea of an pervasive work environment, where many people can work together, supported by invisible and intelligent systems that surround them [ 23 ]. But the “smart office” is not the only application of ubiquitous technologies. Recent research efforts explore the usage of ubiquitous systems in the public, like hospitals, public transport systems or other public spaces [ 9, 5, 7 ]. In public spaces, many people have to access many different services, different data and use different devices to do so, like personal mobile device or public displays. Ubiquitous technologies can be used to integrate those different devices and the different services that are provided in public space. Such ubiquitous public systems have to be context-aware and to adapt to the requirements of many different kinds of users or environments.

To do so, the context of usage must be captured and then correctly classified. Based on the captured context, the system then must be able to adapt the interaction with the user. Depending on his location, a user for example needs different data and based on his abilities, he needs to interact using speech based interfaces, for example if he is blind. Based on this context classification, the system’s behaviour can be modeled. In our previous work, we have developed a method to model interactive systems on the basis of the technique of Use Cases. Our method allows to model interactive components and to modify the provided interactions according to context. In this paper, we want to describe a context taxonomy that models contexts and context criteria of ubiquitous public systems. We also describe how these context criteria can be substantiated for different kinds of public systems. Related Work Most of the existing information systems that perfom in public systems are concerned with public transportation, often specialized for example, for the blind people [ 5, 2 ]. Another kind of public system is focusing on tourists [ 11, 13 ]. As ubiquitous technologies became popular, they were also applied in the public domain, for example integrating public displays and mobile devices or stationary information terminals [ 17, 21 ].

The idea of modeling context for ubiquitous systems is not a brand new topic [ 8 ]. Early context-aware systems are mostly location based or consider location and additionally physical conditions as a system’s possible context [ 22, 4 ]. In recent years, the view on “context” has changed from a mainly physical to a broader view. Some choose to consider tasks or activities of a user as the system’s context to take into account, too [ 18, 16 ]. In public systems, all of these variations of context have to be considered, but there are additional views on context that can become relevant. There is, for example, also a social context that may be important for the usage of public systems. We developed a reusable taxonomy of context criteria that are typically found in the public domain and we therefore consider essential for public systems. This paper is organised as follows. In the next chapter, we want to present the aforementioned method for modeling interactive public systems we developed in our previous work. We will describe how this method allows to easily model such systems in a context-adaptive way. The following chapter then describes, how we modeled our context taxonomy. First, we want to describe our perception of context and the terms we use to derive specific context types from relatively abstract context criteria. We then present the user-centered context taxonomy we developed. We also present exemplarily modeled Interaction-Cases that builds on our context taxonomy. We conclude the paper discussing our approach and describing work that is planned for further research efforts. MODELING INTERACTIVE UBIQUITOUS PUBLIC SYSTEMS In order to support the seamless integration of various devices and services in ubiquitous public systems, these systems must be properly designed and modeled. Persona and scenarios can serve as a basis to define the user’s requirements and the system’s behaviour [ 12, 1 ]. Based on informally described scenarios, Use Cases can be derived that describe the system’s behaviour from a user’s perspective. Use Cases describe the system’s requirements in a more formal way.

In our previous work, we proposed the method of InteractionCases for modeling interactive systems [ 20 ]. InteractionCases can be used to describe the interaction between user and system in a semi-formal way. Types of Interaction-Cases can be predefined, they are therefore reusable. InteractionCases can already be defined when requirements are determined in early phases and then be substantiated up to a very specific level, that can be linked directly to Use Case diagrams and code fragments.

In order to develop context-aware ubiquitous systems, the contexts must be modeled in advance and depending on these contexts, the context-adaptive behaviour of the system needs to be modeled, too. We therefore refined our InteractionCase method, allowing these Interaction-Cases to be contextadaptive [ 19 ]. In early design stages, an Interaction-Case can be marked as context-adaptive to a certain context. The Interaction-Case and the context definition may be very coarsegrained at first. In those early phases, the specific context features that lead to system’s adaptations may not be known, but the general context criteria that influence the interaction process between system and user can already be anticipated. Therefore, it should be possible to refine the context criteria as the specification of the system proceeds.

Using context-adaptive Interaction-Cases, it is possible to define the interaction process between system and user in a different way for different situations. If the system observes, for example, that the ambient noise level is very high, it can adapt its audio volume. Another example is, that if the user is blind, it is necessary to switch to audio interaction instead of visual.

The development and modeling of interactive ubiquitous public systems becomes easy and less time-consuming using Interaction-Cases. The method depends, however, on a properly modeled context hierarchy, that serves as a basis for development of context-adaptive scenarios and interactions. We therefore propose a context taxonomy for contexts in ubiquitous systems. It models contexts that can occur in the public domain and are of possible interest for public systems. The structure of the taxonomy reflects the usage of the context criterions in the iterative development of InteractionCases and allows step-by-step refinement of contexts from coarse-grained contexts to fine-grained context types. We will describe this structure and the context taxonomy for ubiquitous public systems in the following.

A CONTEXT TAXONOMY FOR THE PUBLIC DOMAIN The public domain has special requirements towards information systems and a variety of contexts are possible. There are different users with a different background, different culture, knowledge etc. and a wide range of devices such as mobile devices, public displays, but also stationary information terminals. In order to capture the possible contexts that influence the interaction between a user and the ubiquitous public system, we focused on the user and the situations that can arise in ubiquitous public systems. We do not claim that our context taxonomy is complete, but it can serve as a starting point for further refinement. Which contexts are relevant and which are not depends on the system’s characteristics, its structure and its purpose. The structure of our context taxonomy supports easy refinement of the contexts that are relevant for the task at hand.

Structure of the Taxonomy We based our perception of context on the definition given by Dey and Abowd [ 8 ]:

Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.

For the usage of context with Interaction-Cases and for iterative refinement of relevant contexts, we describe context as different context criteria that are organized in a hierarchical taxonomy. These can be used as a first overview on possible context dimensions for public systems. We then describe different context types, that can be specified and derived from a certain context criterion [ 14 ]. Context specifications can then be substantiated from context types by allowing a system’s architect to subsequently define values or value ranges for which certain context types are laid out in his system’s context design. A possible structure of such a hierarchy is shown in figure 1.

Context is information that characterizes situations or circumstances of an entity like a person, a place or an object [ 8 ]. The complete context a system is able to capture in a specific situation, is most likely combined of different types of context features and different values of these features. A complete system’s context can, for example, be combined from a temperature of 20 degrees celcius, the availablility of visual and audio output and a certain time and location.

Context criteria are different categories in which context can be defined. The context criteria are criteria that may influence a system’s context and are defined on a relatively abstract level. Context criteria can be hierarchically organized. Examples of context criteria are “Climate” and “Temperature” but also “Perceptive Context” and “visual”.

A context type is a sub-category of a context criterion. From context criteria on an abstract level, several context types can be derived that describe features of this context criterion on a specific level. As an example, from the context criterion “visual”, a system designer can define the context types called “blind” and “visually impaired”. Context types can be specified directly by defining values or value ranges. These are called context specifications. A context specification for the context type “visually impaired” may be a value range capturing vision from 20% - 70% or from 71% - 99% as shown in figure 1.

Context Level

Interaction Context Context Criterion

Level Context Type

Level

Context specification

Level

Perceptive Context Criterion

visual blind

visually impaired 20 % - 70 % vision 71 % - 99 % vision CONTEXT IN UBIQUITOUS PUBLIC SYSTEMS Central to the description of context in ubiquitous public systems is the user, as shown in figure 2. These systems adapt to the context they perceive in order to provide an optimized interface for the many different users that use them. We therefore started to collect the requirements of users in public systems. Based on these requirements, we differentiated several contexts that can be useful in modeling context-aware ubiquitous public systems. These context served as starting points for further refinement. In the following sections we will therefore explore these categories and the possible use in modeling interactions in ubiquitous public systems. Interaction context By modeling context-adaptive Interaction-Cases, it is possible to model the interaction processes a ubiquitous public system provides. Our first step is therefore to capture context criterions that directly affect the interactive process between users and systems. Ubiquitous public systems consist of different devices that provide different interaction modalities. The user may have different abilities to interact with the system, too. We modeled the different context criteria that are involved in interaction context by mapping the interaction process on part of the system and on part of the user as shown in figure 3. The system possesses input options and output options. In between these steps, the system processes the given input. According to this, our context criteria for the system’s interaction context are the following: Input: For the context criterion of input, context types can be defined that describe the abilities of the system to get input at all. Some devices used in public systems, for example like tourist information terminals in cities, are equipped with keyboards and sometimes even a mouselike device. Many public information systems nowadays use touch screens, sometimes in addition to keyboards [ 15 ]. From the input context criterion, it is possible to derive context types that can be used to classify the possible inputs of a system.

Processing: The main task of an information system is to process data. The processing context criterion can capture the circumstances of processing in ubiquitous public systems that may influence the system’s interaction towards the user. Small devices, like mobile phones, have less processing power than devices connected to a processing server, for example. The processing capabilities affect the possible interactions with the user and can therefore be modeled using the processing context criterion.

Output: The output context criterion captures the abilities of the system to pass information to the user. In public systems, all kinds of public displays are known [ 10, 6 ]. Thus, most ubiquitous public systems have visual output abilities. But additional output modalities are also possible, for example speech output or haptic output interfaces. Interaction on part of the user begins with perception. The perception abilities of the user may require the ubiquitous public system to adapt and, for example, provide different output modes. After perceiving information, a user processes the information, just like the system itself does. The user also acts in order to input information to the system or to request information from the system. We therefore captured the interaction context on the part of the user using the following context criteria: Perception: This context criterion captures how a user can perceive input. A person can perceive using his senses. Regarding the interaction with computer systems, sight, hearing and touch are the main perception channels. Context types derived from this context criterion can grasp the perceptive abilities of a user.

Cognitive: The cognitive abilities of a user can be grasped using the cognitive context criterion. Children, for example, have other cognitive abilities than adults. A system can then adapt to these cognitive abilities, if they are known, and present information, for example, in simpler form.

Action: The abilities of the user to act towards the system can be modeled using the action context criterion. A user can act using gestures, voice, facial expression or movement. The cognitive context criterion can be used to capture the acting abilities of a user, analogous to his perceptive abilities.

Output Context Criterion Processing Context Criterion

Input Context Criterion Perceptive Context Criterion Cognitive Context Criterion Acting Context Criterion

Interaction Context The different sides of interaction context are comparable. From a certain point of view, the input context criterion and the acting context criterion capture the same type of context, for example, speech input. The same is true comparing output and perception context, capturing, for example, visual input. We distinguished a system’s interaction context from the user’s interaction context. Using two different “sides” of interaction context means, that it is possible to perceive that the user is blind, which is a context type deriving from the perception context criterion. At the same time, it is possible that the system is only able to give visual output (output context criterion). This situation can only be observed using a perceptive context that is distinguished from an output context.

Socio-technical context Another interesting aspect of context is the socio-technical context in figure 4. We identified four socio-technical context criteria [ 19 ] which we divided, depending on their focus, in user and system modelling context criteria. The following social-technical context criteria are user-centered.

Sociological context criterion: With the sociological context criterion we describe the rules which people in public systems are following. These rules allow us to model possible scenarios for different sociological contexts and so affect the usage of ubiquitous computing in public systems. For example, it is a common rule not to disturb other people in surroundings like churches with mobile phones or other devices or to request people’s personal data where others can see it.

Organizational context criterion: The organizational context criterion describes a third party like organizations which are somehow involved in public systems. This context criterion can model the different conditions and possibilities of, for example, public transport organizations, supplier or other organizations that are associated with public systems.

Besides the user-centered context criteria there are two system’s socio-technical context criteria which are described as follows:

Operational context criterion: In public systems there is a multitude of processes, procedures and activities which are not directly visible to a user. These operations can be summarized in the operational context criterion. For example, activities or procedures like to operate the turnout in a control center can affect this criterion.

Technical context criterion: Another system centered criterion is the technical context criterion. It includes all technical abilities of a system, for example, the ability to show real-time data or just data which can not be updated automatically.

Organizational Context Criterion Sociological Context Criterion Operational Context Criterion Technical Context Criterion

Socio-technical Context Further contexts Beside the contexts we described above, there are some further contexts that affect the usage of ubiquitous systems in the public domain. We briefly characterize these in the following paragraphs. Physical context Physical context of ubiquitous public systems captures, for example, temperature, humidity, ambient noise level or brightness. The context criterion “ambient noise level” can be relevant, for example, for adapting the output volume of speech output as the ambient noise level raises.

Task context There are several approaches to capture task or activity based context [ 18 ]. The task the user wants to complete, does influence the interactions he pursues. We therefore plan to capture different task-based contexts for public systems in our future work.

Spatial context The spatial, or location-based, context is described in other projects and papers e.g. by Bauer et al. or Bellavista et al.[ 3, 4 ]. Spatial context can, for example, capture the location of a user but also the user’s movements, which means whether the users walks or stands.

Temporal context As already described in our previous work, the temporal context contains absolute and relative time [ 19 ]. Time aspects can, for example, affect the presentation of data both on a mobile device and public displays. Further contexts related to time are conceivable. We will explore these aspects and their possible use in ubiquitous public systems in future work.

USAGE OF CONTEXT FOR MODELING INTERACTION In this section, we want to give a short example of the usage of context-adaptive Interaction-Cases. Given the context hierarchy in figure 1, the input of data in a public system can be modeled in different ways. Our example of a public system is a public transport system. In such a setting, people want to retrieve information on timetables of buses or trains. We therefore modeled the Use Case retrieveTimetableInformation, as displayed in figure 5. In order to request information on a timetable, the user needs to specify the location and time of departure. The Use Case thus contains an Interaction-Case enter departure information. The system we modeled as an example should adapt to the perceptive abilities of its users. The Interaction-Case enter departure information is therefore modeled contextsensitive. It can be adapted regarding the context criterion “visual”. We modeled two Interaction-Cases that implement the given Interaction-Case for two different context criterions. The first is the “normal” Interaction-Case that uses keyboard input to acquire the departure information. It is shown in figure 6 on the right. However, if the user of the system is blind, he is not able to use a normal keyboard to provide the departure information. In this case, the system should switch to audio interaction. The Interaction-Case in figure 6 is therefore modeled for the context-type “blind” and the system adapts the input modalitiy to audio. Using this modeling technique and our context taxonomy for public systems, it becomes possible to model context-adaptive interactive ubiquitous public systems easily, already beginning in early design phases using pen and paper.

CONCLUSION AND FUTURE WORK In this paper we presented a structure for a context taxonomy that supports modeling and development of context-aware ubiquitous public systems. Using a context taxonomy for the public domain as a basis and implementing the method of modeling Interaction-Cases, it becomes possible to define interactions between system and user in an iterative way. The structure of context we proposed also supports the stepby-step refinement not only of Interaction-Cases, but also of the involved contexts, as shown exemplary in the previous section. We also presented a context taxonomy for the public domain that can be used as a starting point to model contexts for ubiquitous public systems.

Our goal is to enlarge the taxonomy we described above and to refine the context criteria in the future. It is, for example, possible, to refine the input context criterion within the interaction context with respect to the data type that can be entered via the different input channels. Some input channels may, for example, only be relevant or active for input of special data types. We also want to explore the possibilities of deriving context-adapted Interaction-Cases automatically using rule-based substitution of certain InteractionSteps. We hope to further improve the modeling method and the underlying context taxonomy and therefore to improve and facilitate the development of ubiquitous public systems. ACKNOWLEDGEMENTS Part of this work has been executed under the project IPKOM-O¨ V funded by the German Federal Ministry of Economics and Technology (BMWi) under the grant number 19P10003O.

References

1. Aoyama , M. Persona-scenario-goal methodology for user-centered requirements engineering . Requirements Engineering, IEEE International Conference on 0 ( 2007 ), 185 - 194 .

2. Banaˆıtre , M. , Couderc , P. , Pauty , J. , and Becus , M. Ubibus: Ubiquitous computing to help blind people in public transport . In Mobile Human-Computer Interaction - MobileHCI 2004 , S. Brewster and M. Dunlop , Eds., vol. 3160 of Lecture Notes in Computer Science. Springer, Berlin / Heidelberg, 2004 , 535 - 537 .

3. Bauer , M. , Becker , C. , and Rothermel , K. Location models from the perspective of context-aware applications and mobile ad hoc networks . Personal and Ubiquitous Computing 6 ( 2002 ), 322 - 328 . 10 .1007/s007790200036.

4. Bellavista , P. , Corradi , A. , Montanari , R. , and Stefanelli , C. A mobile computing middleware for location- and context-aware internet data services .

5. Bertolotto , M. , O 'Hare , G. M. P. , Strahan , R. , Brophy , A. , Martin , A. N. , and McLoughlin , E. Bus catcher: a context sensitive prototype system for public transportation users . In WISE Workshops, B. Huang , T. W. Ling , M. K. Mohania , W. K. Ng , J.-R. Wen , and S. K. Gupta , Eds., IEEE Computer Society ( 2002 ), 64 - 72 .

6. Brignull , H., and Rogers , Y. Enticing people to interact with large public displays in public spaces . In In Proceedings of the IFIP International Conference on Human-Computer Interaction (INTERACT 2003 ) ( 2003 ).

7. Cheverst , K. , Davies , N., Mitchell, K. , and Friday , A. Experiences of developing and deploying a context-aware tourist guide: the guide project . In Proceedings of the 6th annual international conference on Mobile computing and networking , MobiCom '00 , ACM (New York, NY, USA, 2000 ), 20 - 31 .

8. Dey , A. K. , and Abowd , G. D. Towards a better understanding of context and context-awareness . In Computer Human Intraction 2000 Workshop on the What , Who, Where, When, Why and How of Context-Awareness ( 2000 ).

9. Favela , J. , Rodr´ıguez, M. , Preciado , A. , and Gonza´lez, V. M. Integrating context-aware public displays into a mobile hospital information system . IEEE Transactions on Information Technology in Biomedicine 8 , 3 ( September 2004 ), 279 - 286 .

10. Greenberg , S. , Boyle , M. , and Laberge , J. Pdas and shared public displays: Making personal information public, and public information personal . Personal and Ubiquitous Computing 3 ( 1999 ), 54 - 64 .

11. Hristova , N. Ad-me: A contextsensitive advertising system . In University of Maynooth ( 2001 ), 10 - 12 .

12. Kazman , R. , Abowd , G. , Bass , L. , and Clements , P. Scenario-based analysis of software architecture . IEEE Software 13 , 6 ( 1996 ), 47 - 55 .

13. Klante , P. , Kro¨sche, J., and Boll , S. Accessights - a multimodal location-aware mobile tourist information system . In Computers Helping People with Special Needs, K. Miesenberger , J. Klaus , W. Zagler , and D. Burger, Eds., vol. 3118 of Lecture Notes in Computer Science. Springer, Berlin / Heidelberg, 2004 , 627 - 627 .

14. Korpipa¨a¨, P. , and Ma¨ntya¨rvi, J. An ontology for mobile device sensor-based context awareness . In Modeling and Using Context , P. Blackburn , C. Ghidini , R. Turner , and F. Giunchiglia , Eds., vol. 2680 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg, 2003 , 451 - 458 .

15. Maguire , M. A review of user-interface design guidelines for public information kiosk systems . International journal of human-computer studies 50 , 3 ( 1999 ), 263 - 286 .

16. Ni , H. , Zhou , X. , Zhang , D. , and Heng , N. Context-dependent task computing in pervasive environment . In Ubiquitous Computing Systems , H. Youn, M. Kim , and H. Morikawa, Eds., vol. 4239 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg, 2006 , 119 - 128 .

17. Peterson , M. P. Pervasive and ubiquitous public map displays . In ICA UPIMap2004 (Tokyo , 2004 ).

18. Prekop , P. , and Burnett , M. Activities, context and ubiquitous computing . Computer Communications 26 , 11 ( 2003 ), 1168 - 1176 .

19. Schlegel , T. , and Keller, C. Model-based ubiquitous interaction concepts and contexts in public systems ( 2011 ).

20. Schlegel , T. , and Raschke , M. Interaction-cases: Model-based description of complex interactions in use cases . In Proceedings of IADIS International Conference Interfaces and Human Computer Interaction (Freiburg, Germany, 2010 ).

21. Storz , O. , Friday , A. , Davies , N. , Finney , J. , Sas , C. , and Sheridan , J. Public ubiquitous computing systems: Lessons from the e-campus display deployments . IEEE Pervasive Computing 5 , 3 ( 2006 ), 40 - 47 .

22. Want , R. , Hopper , A. , Falcao , V. , and Gibbons , J. The active badge location system . ACM Transactions on Information Systems 10 , 1 ( 1992 ), 91 - 102 .

23. Weiser , M. The computer for the 21st century. Human-computer interaction: toward the year 2000 ( 1995 ), 933 - 940 .