Chapter 9 EXPLORING DESIGN HEURISTICS FOR USER INTERFACE DERIVATION FROM TASK AND DOMAIN MODELS Costin Pribeanu and Jean Vanderdonckt National Institute for Research and Development in Informatics, Bd.Maresal Averescu Nr.8-10, R-71316 Bucharest (Romania) E-mail:
[email protected] – URL: http://www.ici.ro/chi-romania/pribeanu/ Tel: +40-1-224 0736 / ext. 294, 163 – Fax: +40-1-2240539 BCHI - Université catholique de Louvain, Louvain-la-Neuve, Place des Doyens, 1, B-1348 Louvain-la-Neuve (Belgium) E-mail:
[email protected] – URL: http://www.isys.ucl.ac.be/bchi/members/jva Tel: +32-10-47 85 25 – Fax: +32-10- 47 83 24
Abstract
Task modelling and user interface design are iterative development processes. In this paper we will take a closer look to the relationship between three models: task, application domain and presentation. The objective is to explore heuristics aiming at progressively derive the presentation model from applicationdomain and task model.
Keywords:
Basic tasks, Design heuristics, Task-based design, Task modelling, Unit tasks.
1.
INTRODUCTION
Many limitations of existing model-based approaches are a consequence of putting too much emphasis on only one model. For example, although selection of interaction objects from the application domain model is currently a computer supported work, like in MECANO [4] or TRIDENT [7], existing tools failed to deal with more complex constructs like interaction objects groups and dialog units. This situation could be explained by the lack of integration between the models that are used in the computer-aided design of user interfaces. The objective of this paper is to present an approach aiming to relate task 103
104
Pribeanu and Vanderdonckt
modelling and user interface design. First we will take a closer look at task modelling in order to distinguish between two categories of goals: functional goals, related to what the user wants to do and operational goals related to how he is actually performing the task. The second layer makes possible to relate domain and task models to the presentation model. Then, in order to exploit both domain and task model a set of design heuristics is proposed. The rest of this document is structured as follows. A conceptual framework for task modelling is presented in section 2. Heuristics used for grouping of interaction objects and further structuring of the presentation in dialog units are presented in section 3. The document ends up with conclusion in section 4.
2.
TASK MODELLING
As pointed out by activity theory [2], tasks are goal driven, being performed consciously while actions are depending on operational conditions of the task and become automatic by practice. This distinction is important since it reveals two levels in the task structure: a functional (planning) level that does not depend on a given interface and an operational level. In a more general sense, the planning level does not depend on the context of use (or the dependence is insignificant) while the operational level does. By variable context of use we understand variations in user knowledge, task specifics, user interface, hardware-software platform and work environment. The operational conditions is a concept which could be analysed from two points of view: · ·
variations in using an interface: there may be different actions required to manipulate the same interaction object; variations in the tools used to perform a task: the same goal could be achieved using different user interfaces.
The first situation clearly corresponds to actions that are performed upon interaction objects. In this case, the activity is not driven by goals but rather by requirements to adjust the work. The most frequent operational conditions are related to accommodate variations in data input, information display and user preferences. For example, reading the information displayed by an interaction object may need articulator actions like scrolling a list. The second situation corresponds to tasks that are driven by operational goals. Depending on the technology used and the design decisions, there are several ways to operationalize a functional goal. Therefore we will consider goals at both levels of task decomposition, but with different relevance. Goal hierarchies are more relevant at functional level, since they are stable across
Exploring Design Heuristics for User Interface Derivation From Task and Domain Models
105
different platforms and user interface designs. On contrary, task structures are more important at operational level since they are describing how the user can accomplish his goals with a given interface.
2.1
Goal Hierarchies
Analysing the relevance of the task from the user’s point of view is important because it helps to identify the knowledge he needs. The first level in task decomposition shows how users are planning task performance by decomposing a task in sub-tasks and giving an ordering preference for each of them. In the initial task model goal hierarchy results from early task analysis and shows what the user really wants to do. In order to show how application data could be used, an example will be chosen. The task is to record orders submitted by clients via phone call. First, the client is asked if he is an old client. If so, he provides his id number. If the search operation fails, he is asked to tell his name. If search also fails or if he is a new client, then he is asked to tell his full address: street, number, city name and zip code. Second, the client is ordering the products only by specifying the product id (if he knows it) or the product name and the quantity ordered. The operator informs him on the total amount of the order after each product line. Finally, the client is asked to tell the delivery date and the payment mode (cheque, cash or bank transfer). The leaves in the task tree are unit tasks, defined by Card, Moran and Newell [1] as the lower level tasks which the user really wants to perform. In this modelling context, unit tasks are defined as the lowest level tasks which is device independent. This definition focuses on well-defined and stable user goals. Under this level, the task structure is depending on the technology by which the goal is operationalized.
2.2
Operational Task Structures
Operational level is obtained by decomposing unit tasks. Fig. 1 illustrates the decomposition for the unit task “Identify by id”. According to van Welie, van der Veer and Eliens [6] the relationship between unit tasks and basic tasks is important because it shows problems a user may have when he tries to accomplish his goals with a given interface. Tauber defined the basic task as a task for which the system provides with one single command or unit of delegation [5]. In order to design the user interface he starts from the specification of the so-called User’s Virtual Machine (UVM) which is the conceptual model of a “competent user”, i.e. a
106
Pribeanu and Vanderdonckt
user that knows how to delegate his task to the computer. This definition relates basic tasks to user interface objects but it leaves outside the specification of user tasks that are not related to user interface objects. Basic tasks as defined by Tauber roughly correspond to interaction tasks in CTT [3]. However, the definition proposed by Paternò – tasks that are not further decomposed - is ambiguous and gives no indication on the stopping criterion. The definition of Tauber is highlighting the underlying concept for basic tasks, which is task delegation. Basic tasks are closely related to the interaction process and they are resulting from a task design activity, which is concurrently performed with user interface design activity.
Figure 1. Task decomposition for “Identify client by id”.
Therefore basic task is defined as the lowest level task that is using a single interaction object or a single external object or serves a communicational goal. In this respect, the stopping criteria for task decomposition are an interaction object (for interaction tasks, application tasks and cognitive user tasks), an external object (for manual user tasks), and a distinct step in communication (for communication user tasks).
2.3
Checking the Compatibility between Task Model and Application Domain Model
Interactive tasks are manipulating information. The user is interacting with a part of the data model that is made visible in the interface. In Fig. 2 is presented the ERA (entity-relationship-association) diagram for our example. Following the relationships between domain objects several tasks could be developed: to record an order for a client (the example under consideration), to analyse orders of a particular client and to manage orders. For each case, cardinality of roles is important for the task structure. In the given example, recording orders and filling in the product line are iterative tasks.
Exploring Design Heuristics for User Interface Derivation From Task and Domain Models
107
Ø Cardinality of roles played by domain objects reveals iterative tasks and helps in performing task decomposition All the attributes for the given example (except for stock quantity) are displayed in the interface by means of interaction objects. A first grouping of interaction objects is suggested by the semantics of data.
Figure 2. ERA diagram for application “Record order”.
Usually, attributes of entities are grouped together. For entities that include internal groups, like address of the client, grouping is done according to task requirements. In our example, ClientId, ClientName, and ClientAddress all belong to the same entity but are processed in a different way. Ø Interaction objects that represent attributes of entities and relations are grouped according to semantic criteria and task requirements
3.
DERIVING THE PRESENTATION
3.1
Specification of Interaction Objects
Abstract interaction objects (AIO) are supporting a generic interaction task like selecting an item from a list, choosing an option from a menu or pressing a button that triggers a transaction. Interaction objects are dynamic if they accept input from or display information to the user and static if they are only used to present or to organise the information on the screen. However both categories could be termed as interaction objects since the user is actually interacting with them either perceptually or physically. The first step is to select appropriate interaction objects that support the required interaction techniques and to apply data properties (extracted from the application-domain model) to them. Although information control IOs could be automatically generated by exploiting the domain model based on ergonomic criteria, function control IOs (like command buttons or menus) could only be added to these groups according to task requirements.
108
Pribeanu and Vanderdonckt
Ø First level of interaction object groups are mirroring the unit task structure. In this respect, information control IOs are grouped around a function control IO. A static interaction object having as label the name of the data item could also be generated. Function control interaction objects will use as initial label the name of the basic task (for example, “Search” in Fig. 1).
3.2
Providing with User Guidance at Interaction Object Level
This step is a refinement of the interaction object specification. Usually, names of the data items in the application domain are rarely satisfying the requirements of the user guidance. Therefore, static interaction objects that were automatically generated should be changed. Additional static interaction objects could be added in order to increase the usability of the interface. If interaction object groups are generated from the task model then static interaction objects denoting the unit task goal are also examined and additional static objects could be created to emphasise the grouping. Ø Assign a static interaction object to each goal at unit task level. At this stage, consistency of interaction object placing is checked and the results of applying generation rules are evaluated. It is recommended that first level interaction object groups should be finalised in order to get a bigger building block for working with in subsequent design stages. Ideally, an additional specification of interaction object groups should be elaborated. This specification should record the unit task goal and the area occupied by each group. Then only the goal hierarchy at planning level and temporal relations are needed, thus reducing the cognitive workload for the designer. Even for computer aided generation, this approach reduces the solution space for dialog unit allocation. Further grouping of interaction object groups (unit tasks) is done by exploiting the task model. The same algorithm used for the generation of first level groups could be used. Ø Higher grouping of interaction objects should mirror the goal hierarchy.
3.3
Structuring the Presentation
The initial user interface model is structured only up to the level of unit tasks. As we saw in the previous section, this is a bottom-up process that aims at a computer aided generation of the operational level of the user interface. Further structuring of the presentation requires a top-down approach.
Exploring Design Heuristics for User Interface Derivation From Task and Domain Models
109
First, dialog units are identified starting from the task model. The task model is examined layer by layer in order to identify the possible allocations. Second, interaction groups are grouped to form higher level groups within a dialog unit. There are several criteria and/or constraints to apply for the structuring of presentation in dialog units: strategy of allocation (platform oriented, task oriented, content oriented), built-in capabilities, available screen space. Regarding the strategies of allocation it is important that they are applied in a uniform manner to ensure the consistency of the user interface. No matter which strategy is applied, the user will perceive the underlying structure of the presentation and any inconsistency will impact negatively on his attempt to build a correct metal model of the interface. Temporal relations provide with important information making possible to derive constraints for the allocation of dialog units [3]. In order to effectively exploit temporal relations for the identification of dialog units we need to examine the task model in a top-down direction. This way, it is possible to reduce the solution space by eliminating the solutions that are not acceptable. An example of task-based allocation is given in Fig. 3.
Figure 3. A task-based allocation.
We consider that an allocation solution is not acceptable when tasks that are part of different branches (sub-tasks of the same task) are brought together while tasks belonging to a branch are left outside, except for the case navigational enabling task (usually, the first sub-task). A problem is to apply this method when a strategy of allocation is considered. There are several possible situations, depending on the strategy. Platform dependent strategies lead to minimal vs. maximal allocations when the variation is mainly in the available screen space. This case fits the general one.
110
Pribeanu and Vanderdonckt
Task oriented strategies require to reconsider the task model. In this case, the virtual space is first transformed into a structured space in order to satisfy the allocation strategy. Then temporal relations could be analysed in order to fit the available screen space. Normally, this type of allocation is based on a clear separation between (sub-)tasks and leads to derive independent task trees. Regarding the content oriented strategy, the most typical case is the web site which is divided in web pages. In this case, the structure of the interface takes precedence over the task model. The problem is not to identify the dialog units from the task model bur rather to build a task model in a constraint presentation.
4.
CONCLUSION
In this paper we presented design heuristics aiming to progressively derive the presentation from task model and application domain model. The task-based approach undertaken in this work is intended to provide with a better understanding of the relation between task modelling and user interface design. The key activity in this design approach is task modelling at operational level when unit tasks are decomposed up to the level of basic tasks. Unit tasks decomposition shows how the user will actually accomplish his goals by delegating (a part of) his work to the computer. The operational level in the task model is the foundation of the presentation model and enables a mapping between unit tasks and the basic layer of the user interface i.e. the interaction object groups.
REFERENCES [1] [2] [3] [4] [5] [6] [7]
Card, S.K., Moran, T.P., and Newell, A., The Psychology of Human-Computer Interaction, Lawrence Erlbaum Associates, Hillsdale, 1983. Leontiev, A.N., Activity, consciousness and personality, Englewood Cliffs, Prentice Hall, 1978. Paternò, F., Model based evaluation of interactive applications. Springer Verlag, 1999. Puerta, A., The MECANO project: Comprehensive and Integrated Support for Modelbased Interface Development, in J. Vanderdonckt (ed.), Computer-Aided Design of User Interfaces, Presses Universitaires de Namur. Namur, 1996, pp. 19-36. Tauber, M.J., ETAG: Extended Task Action Grammar - a language for the description of the user’s task language, in D. Diaper et al. (eds.), Proc. of Interact’90, Elsevier, Amsterdam, 1990. van Welie, M., van der Veer, G.C., and Eliens A., An Ontology for Task World Models, in Proc. of DSV-IS’98 (Abingdon, 3-5 June 1998), Springer-Verlag, Vienna, 1998. Vanderdonckt, J. and Bodart, F., Encapsulating Knowledge for Intelligent Automatic Interaction Objects Selections, in Proc. of InterCHI’93, ACM Press, 1993, pp. 424-429.
