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. Additionally, we argue that concepts like consistency, their evaluation and their integration into formal methods cannot replace user-centered design approaches but must be combined in a reasonable way.
• • • •
However, when can we say that two inputs are similar? When can we consider two situations as being the same or similar? 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 discussed in [14]. It is seen 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-action consistency (see next section).
centered design process with an active user involvement, and the deepening of our understanding of formal concepts such as consistency in order to tackle the problem. This paper explores consistency, and particularly task-action consistency with respect to multi-device systems, within a model-based design and evaluation approach in combination with task scenarios.
Dix et al. emphasize that consistency “is not a single property of an interactive system that is either satisfied or not satisfied. Instead, consistency must be applied relative to something” [[5]]. In [[7]], three types of consistency are distinguished: internal and external consistency (within and between applications), and consistency with respect to past real-world experiences. Consistency can be applied to different interface levels. It can support ease of learning, it can support ease of use, and this can be related to conflicting aims. Grudin argues that existing forms of consistency focus on general interface properties and that a shift to the consideration of users’ work and work context is needed. He further argues that a formally expressible consistency often lead designers to © 2006 for the individual papers by the papers' authors. Copying permitted for private and scientific purposes. Re-publication of material on this page requires permission by the copyright owners. concentrate on the description of the software architecture. In [[10]], two types of consistency are proposed on the basis of a simple model of human-computer interaction called goal-action-effect cycle. If users want to complete a task by using an interactive system they have to “translate” the task goals into appropriate actions. By executing them they change the state of the system. These effects are presented and influence the further behavior of the user. Action-effect consistency guarantees that the same (low level) action has the same effect whatever the context is. For example, hitting control C should copy a marked object (e.g. text) into a buffer. Task-action consistency says that tasks which are considered as similar by users have to be completed by similar sets of actions. Task Action Grammars [[6]] can be seen as a formal approach to describe task-action consistency. However, only simple tasks are mapped to actions. Furthermore, it depends on the users and their specific situations what they would consider as similar tasks. So, this kind of consistency is even in the case of single applications problematic. One way to cope with it is to build systems which supply multiple task-action methods so that users have a choice [[10]]. However, to make task-action consistency a more useful concept for designing and evaluating interactive systems more elaborated task-action relations are needed which take into consideration complex user tasks and the context of use.
evaluation are described in different models on an abstract level. In this paper, we concentrate on task and dialog models. Task models are used to describe users’ task knowledge which is never independent of artifacts and means. A dialog model specifies possible orders of interactions, which are offered by an interactive system in order to support users in completing their tasks. We use
of tasks, task domain objects, dialogs, dialog objects, and actions along identical modeling principles. Models are described through elements (objects) and their mutual relations. A dedicated relation is the instance-pattern relation explaining abstractions. Objects are characterized by finite sets of attributes (name-value pairs). Furthermore, partial equations facilitate the description of subsets of instances of a pattern object. They can be used to define sub-tasks and sub-dialogs as well as certain states of domain and dialog objects. Figure 2 shows a fragment of a task model for writing an official letter. The task tree illustrates the hierarchical decomposition into sub-tasks. In addition, partial equations (as indicated below the tree) describe in which order sub-tasks can be performed. For example, in order to complete sub-task write_letter (T2), the iterative sub-task use_relevant_info is performed concurrently to create_letter and the iterative subtask write which have to be executed in sequence (* denotes the iterative operator, | the concurrent, and; the sequential one). A task tree is refined down to the level of basic tasks, which encapsulate actions. An action can create, manipulate, use, and destroy domain objects, which play the role of an artifact or of means with respect to this action. In Figure 2, letter is the artifact in copy_text and refers to the letter which has to be written. Object of (describing a list of open files with relevant information) is a means. A task model can be considered as a pattern object and its instance objects are descriptions of possible sequences of basic tasks/actions. To make a distinction between actions which are performed with or without the interactive system of interest we refer to the former kind of actions as interactions.
As mentioned in the previous section, we need to be able to determine similar tasks to make task(inter)action consistency a useful concept. Task models might help here. They allow to compare sets of sequences of basic tasks/interactions. They also allow to compare descriptions of domain objects and the way how they are manipulated or used. Let us assume a conceptual understanding of how to copy a file and a text as described by the following refinement of the task model in Figure 2. [PRECOND bf IN FileBuf] copy_file(tf,bf) = goto_source_folder() ; select_file(sf) ; copy_to_buf(bf,sf) ; goto_target_folder() ; paste(tf,bf) ; [ rename_file(tf) ] copy_text(f,bt) =
goto_source_place() ; select_text(st) ; copy_to_buf(bt,st) ; goto_target_place() ; paste(f,bt) % […] denotes an option
ATTRIBUTES
content: string, ADDITIONAL ATTRIBUTE
file_name: string PARTIAL_EQU
FileBuf = file_name!=nil ...
ATTRIBUTES name: string, location: string, content: string
manipulated in a similar way (the only difference is that tf has to be created while f already exists). In addition, the text of reused letters remains unchanged in both cases. Although copy_file describes two possible sequences of basic tasks (one ending with rename_file and one not), and copy_text specifies one these sets can be seen as similar.
dialog =
open_file ; *edit ; close_file, open_file = % + denotes the alternative operator create_file + open_existing_file, edit = type + move_cursor + select_text + copy + cut + paste + safe + safe_as, close_file =
[ safe ] ; close, open_existing_file = select_menu_entry_Open ; goto_folder ; select_file ; open, safe_as = select_menu_entry_SafeAs ; goto_folder ; determine_file_name, ...
dialogs and preconditions on the involved dialog objects serve to specify possible sequences of interactions. For simplicity, dialog objects and preconditions are omitted in the example. Take note that, in general, a dialog model has to ‘serve’ several task models. As one consequence, temporal constraints are often weaker.
sets of sequences of interactions. Task and dialog models allow the description of similarity on an abstract level. For example, sub-task copy_text could be performed by sequence SD1 of basic dialogs: 〈move_cursor,select_text,copy,move_cursor,paste〉. The basic dialog copy could be realized by the interaction ‘press control C’ or by selecting an appropriate menu entry and so on. Sequence SD2=〈select_menu_entry_Open, goto_folder, select_file, open, select_menu_entry_SafeAs, goto_folder, determine_file_name〉 might reflect a possible mapping from basic tasks of copy_file. Do
discussion about context of use. In [[1]], context is defined 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.” Here, we concentrate on taskrelevant information.
Cross-platform consistency is characterized in [[15]] as follows. “A MUI [multiple user interface] can have a different look-and-feel while 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.” In [[10]], “the same abstract task-action mappings across interfaces” are proposed. Task and dialog models allow such a mapping. They can help to specify platform independent features of a system in a systematic way. However, we propose to demand a similar behavior with respect to tasks.
(for example, on parameters of the physical devices such as screen size and storage, or on the location which also implies a certain social situation) which sub-task should be supported by a device (e.g. [[12]], [[3]]). Figure 3 illustrates an appropriate design approach. A general task model has to be restricted e.g. by filtering sub-tasks and restricting temporal relations between sub-tasks. These restricted task models are the starting point for deriving dialog models for different devices in use.
underlying models. Hence, we can assume a certain degree of task-action consistency. However, we also need support for relating elements of dialogs of different devices (circle1, Figure 2) and for relating elements of UI prototypes (circle2). The integration of a pattern-based approach like [[8]] where patterns are used to redesign user interfaces could help. Pattern can be implemented on different platforms in different ways but they provide some kind of consistency.
In the context of cross-platform design, consistency should also serve as a criterion to measure how smooth users can switch between devices in accomplishing their tasks. It is stated in [[2]] that “usability of a multi-device system must be analyzed for each platform, taking into account each possible form of transition between the available devices”. In contrast, we propose not to strive for seamless switches between devices in general. However, people often 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 automatic as well as interactive tool for supporting 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.
actual task. Say, for example, a user has accomplished sub-tasks A and B on device Dev1 and is using now device Dev2. According to the underlying task model he has to execute sub-task C or D in the next step. Then, provided that Dev2 supports these sub-tasks, the artifacts and means necessary for performing C or D could be presented. One could also imagine that a user applies (a perhaps simplified form of) task models to plan the execution of his work across different devices interactively.
Although (or because) there are controversial discussions about consistency as a usability criterion the concept might help us to understand human-computer interaction more deeply. The focus here was on task-action consistency across MUIs. Task and dialog models specifying tasks and (inter)actions on an abstract level were used to support a more thorough discussion about similar tasks and similar actions. Some ideas for developing consistent interactive systems for different platforms or mobile devices within a model-based design process were presented. It was suggested to relate the concept of seamless moves between devices to task scenarios.