Task-Action Consistency in Multi-Device Systems - Semantic Scholar

10 downloads 0 Views 92KB Size Report
Monk, A.: Noddy's guide to consistency. In Interfaces,. No. 45, 2000. 12. Penn, A.: The system-user paradox: Do we need models or should we grow ecologies?
Task-Action Consistency in Multi-Device Systems Anke Dittmar University of Rostock Albert-Einstein-Str. 21 [email protected] +49 381 498 7620

Peter Forbrig University of Rostock Albert-Einstein-Str. 21 [email protected] +49 381 498

ABSTRACT

action consistency (e.g. [11]).

This paper reconsiders task-action consistency with respect to multi-device systems. We show how this concept influences our understanding of an appropriate model-based design approach. In addition, we argue that concepts like consistency, their evaluation and their integration into formal methods cannot replace user-centered design approaches with an active user involvement.

Of course, the emergence of portable computing devices and (hopefully not;) ubiquitous applications makes the design of user-friendly systems even more difficult. In face of this development, criteria of usability such as consistency have to be reconsidered too. So, we have to find answers to questions like What aspects of consistency matter in cross-platform design? How can consistency be evaluated in the multi-device context and how can such measures be integrated into the design process? (see this workshop proposal)

Author Keywords

Model-Based Design of interactive systems, task models, abstract and concrete UI-specifications, usability ACM Classification Keywords

We think that it is necessary to ‘exploit’ both approaches mentioned above: the idea of a user-centered design process with an active user involvement, and the refinement of our understanding of formal concepts such as consistency in order to tackle the problem. This position paper concentrates on a redefinition of taskaction consistency with respect to multi-device systems. It is illustrated how this understanding can influence the design process at the example of a model-based approach in combination with task scenarios.

H.5.2 User Interfaces; User-centered design INTRODUCTION

In [7], Grudin referred to a workshop where 15 experts were not able to supply a ‘consistent’ definition of consistency with respect to user interfaces. We know versions like -

-

A similar (user) input in the same situation will have a similar effect on the (computer) system. The same input in similar situations will cause similar effects.

TASK-ACTION CONSISTENCY IN CROSS-PLATFORM DESIGN

However, when can we say that two inputs are similar? When two situations are the same or similar?...

In [11] a simple scheme of a goals/tasks-actions-effects cycle (to explain “what goes on when someone interacts with a computer”) is used to derive “the two most important definitions of consistency: action-effect consistency… and task-action consistency, that is consistency in the way actions relate to task goals”.1 “The idea is that similar goals should require similar sets of action to achieve them.” [11] However, people have different task structures. We encounter (again) the problem of what similar tasks are.

While Grudin suggested to follow a user-centered design approach instead of relying on formal concepts such as consistency for evaluating user interfaces the understanding of what consistency could mean is deepened in [16]. It is seen there as a concept which relates the dialogue language of the interactive system and the task language of a (competent) user. This idea is reflected, for example, in the distinction between action-effect consistency and task-

“For this reason, style guides encourage task-action consistency by suggesting multiple task-action methods… This accounts for the fact that there are many ways of achieving a given task in a large application… and that most people only ever use one of them.” [11] Style guides are one way to incorporate conceptual knowledge into the 1

As [11] we use the terms “task” and “goal” interchangeably here, for a more sophisticated view see e.g. [4].

1

design process. Of course, there are others too. In modelbased design approaches, for example, task models are used to describe the task knowledge of users. Dialogue models describe actions supported by user interfaces. These abstract descriptions of tasks and actions can be related to reason about properties like consistency. Or, having an abstract task description one can try to derive - at least semi-automatically - appropriate dialogue models. We come back to this approach in the next section. Although we started this paper with definitions of consistency relying on terms like ‘the same situation’ and ‘similar situations’ we assumed so far a (relatively) static computing environment (e.g. a human sitting in front of a desktop computer all the time). It is a little mean to say… but one could think that the development of mobile devices and appropriate applications made the discussion about the context of use much more socially acceptable than… Anyway, context-awareness is one of the today’s requirements on computing systems. The context is often described in terms of location, “being connected” or “being disconnected”, parameters of the physical devices in use like the size of the screen, the storage etc. However, Dey and Abowd define context as “any information that can be used to characterize the situation of entities…that are considered relevant to the interaction between a user and an application, including the user and the application themselves.” They also claim that “[t]here are technologyand human-centered challenges that stem from a poor understanding of what constitutes context and how it should be represented.” [1] In this paper, we concentrate on taskrelevant information. In [17] cross-platform consistency is characterized as follows. “A MUI can have a different look-and-feel while

task model Task model

maintaining the same behavior over different platforms. For example, all user preferences must be preserved across the interfaces. If the end-user has specified a particular access mechanism using one interface, it should be used on all interfaces.” We prefer to demand a similar behavior and come to that in the next section. It should be evident that we are still faced with ‘classical consistency problems’ (what are similar actions, similar effects or different look-andfeels with the same behavior?). In addition, consistency, and task-action consistency in particular, should also serve as a criterion to measure how smooth or seamless users can switch between devices in accomplishing their tasks. “Thus, a service cannot be considered on a given device separately from other devices. The usability of a multi-device system must be analyzed for each platform, taking into account each possible form of transition between the available devices.” [2]. We propose not to strive for seamless switches between devices at all. Often, people develop habits and use single devices for certain purposes. For example, Ann could use her MP3 player to listen to music or audio books but Peter also uses the audio recording feature of his player. While Ann usually connects her player to their common PC to upload new songs or the next chapters of the actual book, Peter also wants to edit and manage recordings. Hence, it seems to be more realistic to develop means for creating efficient task scenarios across devices. In Ann’s case context information could be used to automatically open her uploading program and possibly the next chapters. The following section illustrates how a model-based approach can support the design of consistent MUIs. It is shown at the example of task and dialogue models that they have to be adapted to cope with the new requirements.

dialog graph Dialogue graph

Dialogs dialogs

Figure 1. A single prototypical application derived via a task and a dialogue model. TASK AND DIALOGUE MODELS

In model-based approaches different perspectives on the system under design are described in different kinds of models on an abstract level. In particular, task models describe the task knowledge of users, dialogue models specify the behavior of user interfaces. In most approaches these models are not developed separately but task models are used to derive (mostly semi-automatically) dialogue models (e.g. [13],[9],[1],[5] for an overview). In Figure 1 a

task tree in CTTE-notation [13] is used to construct a dialogue graph, which allows the generation of an initial abstract UI prototype. This prototype can be refined (right side) by adding concrete user interface elements without destroying references to the underlying dialog graph and task model (for more details, see [15]). As for MUIs not every task should be supported by all devices as pointed out e.g. in [14]. This idea is applied in

[3] where a general task model can be restricted by filtering sub tasks and restricting temporal relations between sub tasks. These restricted models are the starting point for

deriving dialogue graphs for the different devices in use as illustrated in Figure 2.

Figure 2. A task-related specification process for MUIs.

underlying task model he has to execute sub-task C or D in the next step. Then, provided that Dev2 supports these sub-tasks, means for performing C or D should be presented. However, the prevailing monolithic hierarchical task structure (with explicit temporal constraints between sub-tasks) is too simple to manage context information in a fully satisfying way. For example, it is not possible to describe (and to control) the flow of task domain objects between applications. In [5], we proposed a formalization of task domain knowledge, which could be useful to tackle the problem. In addition, higher-order task models as introduced in [4] could be a convenient means for describing dynamic services.

DISCUSSION

In [11] abstract task-action mappings are proposed to reason about consistency across interfaces. Task and dialogue models supply this kind of mapping. They can help to specify platform independent features of a system in a systematic way. However, several points are worth mentioning. -

“Task-action consistency is intended to result in transfer of training when learning the set of actions needed to achieve similar goals.” [11] Monk points out that abstract task-action mappings can lead to different evaluation results of user interfaces.

-

Dialogue graphs as abstract behavioral user interface descriptions of single devices are derived from parts of a general underlying task model. UI prototypes are guaranteed to obey the behavioral constraints, which are specified in the underlying task model and the corresponding dialogue graph. Hence, we can assume a certain degree of task-action consistency. However, so far there is methodological and tool support for relating elements of dialogue graphs of different devices (see the encircled 1 in Figure 1) and for relating elements of UI prototypes (see the encircled 2). The integration of a pattern-based approach like [8] where patterns are used to redesign user interfaces could help here. Pattern can be implemented on different platforms in different ways but they provide some kind of consistency.

-

The discussion so far reflects a purely goal-oriented approach to design interactive systems. However, we know that human behavior cannot be explained by tasks and goals alone. What happens if you open the mailbox to proofread the paper your colleague has sent you and you find an email of your friend? We know concepts like ‘situated actions’ [18] or the idea of embodied interaction “as the creation, manipulation, and sharing of meaning through engaged interaction with artifacts” [6]. We know that stories and scenarios can evoke empathy, reflection, and discussion among the stakeholders. How can we integrate our knowledge? It could be interesting to compare this situation with that of functionalist architects in the postwar as described in [12]. “…buildings are there to fulfill a ‘programme’, and that a programme entails a series of tasks that will be engaged in by building users. On this view, the designer’s job is first to establish what these tasks are and the relations between them (the briefing problem), and then to define a building

The general task model can be used to supply some kind of context with respect to the actual task. Say, a user has accomplished sub-tasks A and B on device Dev1 and is using now device Dev2. According to the 3

plan that will support their efficient execution (the design problem). On the face of it this may seem like an entirely reasonable assumption, however a closer inspection shows that it is based on making a strong distinction between the ‘user’ and the ‘environment’.” … ”In a space of less than 25 years understanding of design processes in architecture had moved from a systematic, causal and more or less automatable …, to a fuzzy, iterative, context bound and cognitive activity.”

CONCLUSIONS AND FUTURE WORK

Although (or because) there are controversial discussions about consistency as a usability criterion the concept helps us to understand human-computer interaction more deeply. In this paper, task-action consistency across multiple user interfaces is considered. Some ideas for developing consistent interactive systems for different platforms or mobile devices within a model-based design process were presented. However, it was also shown that these approaches have their limitations. On the one hand, formal models like task and dialogue models have to be improved to support the creation of (task-action) consistent systems. On the other hand, different design approaches and philosophies have to be integrated into the design process. REFERENCES

1. Dey, A.K., Abowd, G.D.: Support for the Adapting Applications and Interfaces to Context. In [17]. 2. Denis, C., Karsenty, L.: Inter-Usability of Multi-Device Systems – A Conceptual Framework. In [17]. 3. Dittmar, A., Forbrig, P., Reichart, D.: Model-based Development of Nomadic Applications . In Proc. of the IMC 2003, Rostock, 2003. 4. Dittmar, A., Forbrig, P.: Higher-Order Task Models. In Jorge, Nunes, e Cunha, editors, DSV-IS 2003 LNCS 2844, Springer, 2003. 5. Dittmar, A., Forbrig, P.: The influence of Improved Task Models on Dialogues. In Proc. of CADUI 2004, Madeira, 2004.

6. Dourish, P.: Where the action is: the foundationsof embodied interaction. MIT Press, 2001. 7. Grudin, J.: The Case Against User Interface Consistency. In Communications of the ACM, Vol. 32(10), 1989. 8. Javahery, H., Seffah, A., Engelberg, D., Sinnig, D.: Migrating User Interfaces Across Platforms Using HCI Patterns. In [17]. 9. Limbourg, Q., Vanderdonckt, J., and Souchon, N.: The Task-Dialog and Task-Presentation Mapping Problem: Some Preliminary Results. In Palanque, Paterno, editors, DSV-IS 2000, LNCS 1946, Springer, 2000. 10. Luyten, K., Clerckx, T., Coninx, K., Vanderdonckt,J.: Derivation of a Dialog Model from a Task Model by Activity Chain Extraction. Jorge, Nunes, e Cunha, editors, DSV-IS 2003 LNCS 2844, Springer, 2003. 11. Monk, A.: Noddy’s guide to consistency. In Interfaces, No. 45, 2000. 12. Penn, A.: The system-user paradox: Do we need models or should we grow ecologies? In Proc. of TAMODIA 2005, Gdansk, 2005. 13. Paterno, F.: Model-Based Design and Evaluation of Interactive Applcations. Springer-Verlag, 2000. 14. Paterno, F., Santoro, C.: One Model, Many Interfaces. In Proc. of the Fourth International Conference on Computer-Aided Design of User Interfaces, p. 143-154. Kluwer Academics Publishers, 2002. 15. Reichart, D., Forbrig, P., Dittmar, A.: Task Models as Basis for Requirements Engineering and Software Execution. In Proc. of TAMODIA 2003, Prague, 2003. 16. Reisner, P.: What is Inconsistency? In Diaper et.al., editors, Human-Computer Interaction - INTERACT'90, Elsevier, 1990. 17. Seffah, A., Javahery, H., editors: Multiple user interfaces: cross-platform applications and contextaware interfaces. John Wiley, 2004. 18. Suchman, L.: Plans and Situated Actions. Cambridge U. Press, 1987.

Suggest Documents