Patterns for Task- and Dialog-Modeling - CiteSeerX

Patterns for Task- and Dialog-Modeling Maik Wurdel1, Peter Forbrig1, T. Radhakrishnan2, Daniel Sinnig2 1

Software Engineering Group, Department of Computer Science, University of Rostock Albert-Einstein-Str. 21, 18051 Rostock, Germany {maik.wurdel, pforbrig}@informatik.uni-rostock.de

2 Department of Computer Science, Concordia University, 1455 De Maisonneuve Blvd. West, H3G 1M8, Montreal, Canada {krishnan, seffah, d_sinnig}@cs.concordia.ca

Abstract. The term Context of Use has been treated with much attention in HCI in recent years. In this paper, the integration of context information into task models will be described. The notion of context is formulated and used to annotate the task model. The reuse of such context-sensitive task models in light of task patterns is also examined. Keywords: task modeling, context-sensitivity, task patterns, context of use

1 Introduction The development of UIs is complex and requires the integration of different disciplines. Model-based UI development has gained much attention by various researchers [5, 6, 8, 9], due to its ability to foster the integration of different viewpoints into the development process in the early stages of the development process. In general it tackles the problem of UI development by using different declarative models and the relationships between these models. The task model as a description of the tasks and goals is a commonly accepted starting point for modelbased UI development processes. Other models that have to be taken into account describe the environmental circumstances of the execution of tasks. The Context of Use (CoU) as an abstraction of these circumstances influences the tasks a user has to fulfill. Note that some tasks might not be useful or possible in a certain context. The adaptation of the UI according to the context can improve the human computer interaction by providing an adapted UI for the specific CoU. In this paper, we will demonstrate how context models are integrated into a modelbased UI development process, with particular emphasis on the task model. A definition of the term context and a formalization is given, which is later used to enrich task models. Finally we illustrate how context sensitive task patterns can be used as building blocks for the creation of context sensitive task models. The idea of reuse of generic model fragments by means of the use of patterns will be illustrated.

2 Model-Based Development and Task Models Modeling is understood as abstraction of a real system by removing the irrelevant details in the current level of abstraction [3]. Modeling helps software designers to manage complexity by abstracting from low-level implementation details. In HCI, there are different kinds of UI models that can be taken into account to describe the various facets of the UI. Among those models, the task model has gained special attention, as it often forms the starting point from which the UI development should be initiated. Task models describe the tasks (and sub-tasks) a user has to execute to achieve a certain goal. A task is a hierarchical structure, which expresses the activities a user has to accomplish to fulfill this task. A goal is understood as a result a user wants to obtain after the task execution. Task modeling is a user-centered approach and thus task model designers concentrate on users and capture their activities. Considerations about how a user can reach a goal using a certain software system can foster usability. Even without using task models for UI generating processes they help capturing usability requirements, since the understanding of the task world of the user can lead to a better UI design. Model-based UI development describes the process of (semi-) automated UI generation by using a set of declarative models, which cover all aspects of importance of the envisioned UI. Most model-based UI approaches specify the user, task, domain (application), platform, dialog, layout and/or presentation model [7, 8]. Model-based UI development can be seen as a series of model transformations, where abstract models (e.g. task, user, domain model) gradually evolve into more concrete models (e.g. dialog, layout, presentation model) which finally result in the implementation of the UI. Since the design of UI models is complex and error prone, tool support is needed to carry out model-based UI development efficiently. Especially tedious tasks can be supported or automated. Furthermore tool support is able to hide technical details of the used technologies and the design is made at a conceptual level. A model based UI development environment can consequently be understood as a software system, which helps software designers to execute a certain model-based UI development process. Typical functions of such an environment are the design, validation, and animation of the model instances. Furthermore, the environment should provide decision-making assistance and involve the end-user in all stages of the development. The generation of prototypes based on the designed models to evaluate the made decisions helps to integrate the stakeholders’ needs in early stages of development. Design decision can be reconsidered based on the given feedback.

Fig. 1 Model-based UI development process and its steps

Fig. 1 shows the general rational of a model-based UI development process. It starts with an analysis of the goals and tasks, which results in overall task model. This step will be further detailed in a subsequent section. Next, the resulting task model has to be adapted to the current context by taking into consideration aspects about the user, the end-device and the environment. This refined task model is less complex, since unnecessary tasks for this context are already filtered. Based on the information of the task model the dialog is constructed. It specifies groupings of tasks into dialog views and defines transitions between the various dialog views. In this stage of the process an abstract prototype can already be generated (more details on this generation process can be found in [4]), which exemplifies the general application flow of the later UI. This prototype is based on the designed dialog structure and the temporal relationships of the involved tasks. Followed by the creation of the dialog structure is the definition of the presentation and layout model. The former associates interaction elements (e.g. buttons, text fields, labels) with the various tasks, whereas the latter describes the arrangement and the look & feel of these elements. After describing our model-based UI development methodology we will now discuss different types of task models, which may be involved in the various development steps. In general we distinguish between three different types of task models: 1. Task model of the problem domain (Analysis task model) 2. Context-sensitive task model of the envisioned software system 3. Task model of the software system for a particular CoU (context-insensitive) The analysis of the domain of interest results in the analysis task model (1.). It reflects the knowledge of the domain how a problem can be tackled in a general way independent of a software system [4]. The analysis is performed in close cooperation with the domain expert. After considering, which problems should be solved by the envisioned software system, a corresponding envisioned task model is designed (2.). It is a boiled down version of the previous task model and omits tasks, which will either not be tackled by the envisioned software system or do not relate to the software system itself. This model has to reflect the behavior of the envisioned interactions between the user and software [4] and describes the task world for all platforms, users and environments. The context-insensitive task model, on the other hand, is considered as the task model, which has to be fulfilled by a certain user using certain device in a particular environment (3.). It is a filtered version of the previous

task model. During the transformation only the applicable tasks for a particular context are considered. Note that a context-sensitive task model describes a set of context-insensitive task models. Thus, a context-insensitive task model can be seen as instance of the corresponding context-sensitive task model. The next section will clarify the term CoU and proposes a model, which is used to annotate task models. Later on we will come back to the different types of task models to reflect context dependencies.

3 Context of Use With the advent of mobile and ubiquitous computing the development of interactive systems has become increasingly complex. The interactive behavior of the system needs to be accustomed to a wide range of people having different skills hand and using different end-devices. In addition the usage of mobile devices is not bound to a predefined location of use and hence versatile environmental factors need to be taken into account as well. In this paper we summarize the entirety of influential factors under the term Context of Use (CoU). The context of use is any information that can be used to characterize the situation of the environment, the user and the device of a software system, which is regarded as relevant for the interaction of the system and the user.

Fig. 2 Decomposition of the CoU into sub-models

From our point of view a holistic approach has to cover the device, the user of the system and the environment of the system and the user. There is consent that these models interrelate to each other[1]. According to our previous definition we propose the categorization illustrated in Fig. 2. 3.1 Meta-Model In this section we propose a generic meta-model for the CoU model. It consists of variables and expressions. More precisely the CoU model is defined by a set of variables where each variable has a unique name and a domain of discrete values.

Furthermore, an order is defined on the values of the domain. Based on these variables expressions are defined by comparisons of variables and Boolean logic. Brief Example Based on the proposed meta-model of the CoU we will exemplify its application for the sub-model “Device”. As depicted below, it consists of a set of representative variable with pre-defined domains. Variables: CPU (low, medium, high) Memory (1024Mb) Bandwidth (low, medium, high) Input capabilities (pen, cell phone keyboard, keyboard) Monitor resolution (