dology not only consists of the definition of these steps, but also shows how computer- ... 1. to extend classical application development methodology [2] and ...
6
A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype François Bodart Anne-Marie Hennebert Jean-Marie Leheureux Jean Vanderdonckt ABSTRACT This paper presents a complete model-based approach to the building of presentation for a business oriented highly interactive application. This approach is considered complete in the sense that it supports a continuum from task analysis to a first prototype without disruption. The main steps involved in the proposed methodology include a task analysis performed as a hierarchical decomposition of the interactive task into sub-tasks, a specification of the functional requirements and its integration with task analysis results, a writing of an activity chaining graph which graphically depicts the information and function flow within the task, the selection of an interaction style, the definition of presentation units, the selection of abstract interaction objects, their transformation into concrete objects to be placed before generating a first prototype. The described methodology not only consists of the definition of these steps, but also shows how computeraided tools can automatically generate the presentation of such an interface.
6.1 Introduction TRIDENT (Tools foR an Interactive Development EnvironmeNT) is a methodology and a support environment for developing highly interactive business oriented applications [3,4,23]. This methodology consists of a set of : - processes that define a complete and continuous approach for developing such applications; - related products that result from these processes; - basic models on which the processes are grounded; - interactive tools that support the processes and that help the designer to build the user interface in an automated or computer-aided way. These four facets have proved to be necessary since merely having tools to produce the user interface (e.g. by automatic generation, by demonstration) is not believed to be enough. A methodology in which these facets are gracefully integrated is needed [10,11]. To obtain this goal, the TRIDENT methodology should meet at least five requirements : 1. to extend classical application development methodology [2] and environment to the development of user interface; 2. to provide autonomy (separation) between the application domain functions and the user interface [9]; 3. to provide a separation between the conversation and presentation components of the dialogue in the user interface [3];
78
F. Bodart et al.
4. to use explicitly a set of ergonomical rules to drive and to generate the definition of the presentation [3]; 5. to directly derive conversation and presentation from task analysis [3,21]. The user interface, or dialogue, is consequently divided into presentation and conversation. The presentation forms the static visual layout of the dialogue, made up of interaction objects. The conversation is responsible for the dynamic behaviour of these interaction objects that can be manipulated by the final user (e.g. input responses). This paper is devoted to a modelbased approach to presentation in TRIDENT. This approach consists of a complete methodology which runs continuously from a task analysis of the future application to a visible and working prototype of the presentation. It relies mostly on an extended entity-relationship attribute model and a task model, which can be graphically depicted by an activity chaining graph. Different processes (some manual, some computer-aided, some automated) are performed to produce the presentation model of the dialogue. This presentation model, from which the final user interface will be generated, is graphically represented as a hierarchy of presentation units containing interaction objects. Both data and interface models can be specified with a specification language called DSL (Dynamic Specification Language). To illustrate this model-based approach, a relatively simple example is detailed trough the different processes. %
-
)
)
+
*
/
1
!
!
)
+
.
,
&
2
3
0
'
(
#
$
#
"
#
"
&
"
#
"
!
!
%
&
FIGURE 6.1. Overview of the model-based approach to the presentation in TRIDENT.
A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype
6.2
79
Overview of TRIDENT Methodology
The methodology includes two model-based approaches for the dialogue : one for the conversation and one for the presentation. Model-based approach is examplified in [19,20]. The model-based approach to the conversation is introduced in [3]. It basically starts from a task model (which is shared with the presentation) in order to build a hierarchical objectoriented architecture of dialogue objects [4]. A similar approach can be found in [7]. Each dialogue object is responsible for one piece of the global conversation. The behaviour script of each dialogue object is formally specified by a rule-language expressed in the first order predicate logic (see [16]) that can be partially depicted graphically by state-transition diagrams [18]. These diagrams allow an asynchronous representation of the task model in the conversation [12]. The model-based approach to the presentation will be discussed in this paper (Figure 6.1). Each process, denoted by a rectangle in Figure 6.1, is described in the following numbered sections : the products of each process, the underlying model if any, and the existing tool if any. This description is sometimes summarized for the benefit of a broader demonstration of how these processes are connected.
6.3
Task Analysis
The task analysis should build the foundations of every complete methodology as recommended in [21,22]. In TRIDENT, the task analysis starts from field studies and interviews with potential or existing users in order to understand their tasks. Let us consider a company selling clothes by phone. Let us examine for example the task "Phone order" extracted from the Product Management domain. The text of this task, resulting from interviews, is reported here with the left border [13]. When a customer makes a phone order to the company, three steps are performed : Identification of the customer When a customer calls, the operator asks the customer whether s/he is already a registered customer of the company. If the customer is a new one, s/he provides firstname, lastname and complete address. If the customer is an old one and still knows his/her identification number, s/he tells the operator what this number is. The operator then searchs this id. through the company's database. Registration of identification numbers over the phone is often fraught with human error. Therefore, searching such numbers can be unsuccessfull. Three cases may occur : 1. the provided id. exists in the database and is the right one. The operator reads the customer's complete address to be further acknowledged by the customer : if the customer moved, s/he is now able to provide the new address; 2. the provided id. exists in the database and is a wrong one. In order not to get on the customer's nerves and not to worry him/her, the operator then asks the first- and lastname, trying to locate the customer with this more precise information. The operator may either succeed (in this case, the customer's address is read and could be modified if necessary) or fail (in this case, the operator adds a new record to the database); 3. the provided id. does not exist in the database : similarly, the operator assumes the caller to be a new customer and thus creates a new entry.
80
F. Bodart et al.
If the customer is an old one and does not know his/her identification number, the operator asks the first- and lastname trying to locate the customer. By analogy, the search may either succeed or fail. In all cases, the identification number of the customer is available as soon as the customer is identified. The definition of the order For each product requested, the customer provides the product number and the quantity to the operator. For each product, the operator dictates the label of the article until each product number and label match. The record of the order Once the customer has been identified and the order has been defined, no matter what the order, the operator asks the customer the mode of payment (which can be cash, by credit card or by bank transfer) and the delivery date. The operator finally records the order. The task analysis then proceeds with a precise definition of : 1. a hierarchical decomposition of the interactive application into interactive tasks. These tasks are recursively decomposed into sub-tasks according to decomposition criteria which preserve consistency, completeness, and human cognitive work load. The last level of decomposition of this hierarchy highlights the actions needed to perform the task (e.g. automatic, manual or interactive actions). Once finished, the task analysis allows the specification of related goals (e.g. identification), actions (e.g. database search), and objects (e.g; customer) for each task and sub-task. Figure 6.2 shows a possible decomposition of the task described above. Application Product Management Application Interactive task : Phone order Sub-task 1 : Identification of a customer Action 1 : modify the address of a customer Action 2 : search a customer by identification number Action 3 : search a customer by firstname and lastname. Sub-task 2 : Definition of the order Sub-task 3 : Record of the order FIGURE 6.2. Hierarchical decomposition of an interactive task
2. the relations existing between the user and the interactive system, for each sub-task; 3. the following attributes for each interactive task : •
pre-requisite (minimal/moderate/maximal) : whether the user needs special pre-requisite to accomplish the task;
•
productivity (low/medium/high) : whether the task is accomplished a couple, some or many times;
•
objective environment (existent/non existent) : whether physical task objects (e.g. source document) exist;
A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype
81
•
environment reproducibility (practicable/unpracticable) : whether the objective environment could be metaphorized;
•
task structure (low/medium/high) : whether the task is poorly, somewhat or highly structured in the sub-tasks;
•
task importance (low/medium/high) : whether this particular task is critical for the whole interactive application;
•
task complexity (low/medium/high) : whether the task requires little, some or a great deal of human skill (e.g. motor, cerebral, cognitive, verbal).
In the example, the interactive task "Phone order" might be characterized by pre-requisite=moderate, productivity=high, objective environment=non existent, environment reproducibility=unpracticable, task structure=high, task importance=medium, task complexity=low. 4. the user stereotypes. A stereotype abstracts a particular category of users in the population. The main reason for introducing different stereotypes is that the same task can be accomplished in very different ways by very different users according to their habits and skills. A similar assumption is done in ADEPT [13] and in the model of User Characteristics described in [6], p. 47. For each stereotype considered, the following attributes are given : •
task experience (elementary/medium/complex) : whether the user already possesses previous experience for the task;
•
system experience (elementary/medium/complex) : whether the user already uses other similar systems;
•
motivation (low/medium/high) : whether the subjective satisfaction factor of the user is low, medium, or high;
•
experience of a complex interaction media (elementary/medium/complex) : whether the user already masters some interaction media whose behaviour is not necessarily familiar (e.g. keyboard, function keys, rotators).
In the example, a possible stereotype of the company operator might be characterized by task experience=medium, system experience=elementary, motivation=medium, experience of interaction media=complex. 5. the description of the workplace in terms of the following attributes : •
process type (mono-processing/multi-processing) : whether the interactive task could be interrupted;
•
process capacity (low / medium / high) : whether concurrent tasks are allowed.
6.4
Functional Requirements
Classical development methodologies traditionally include the definition of functional requirements. If the task analysis and the user stereotypes, especially, specify the operational requirements, this process is responsible for writing the functional requirements. TRIDENT provides different models for different purposes [2]. An entity-relationship-attribute (ERA)
82
F. Bodart et al.
model, extended and built on database theory and software engineering practive, describes the object structure and relations to be manipulated by the user. Each ERA model can be input either graphically (Figure 6.3) with a direct-manipulation editor or with a suited specification language (Dynamic Specification Language) (Figure 6.4). ERA model is appropriate for the information modeling part of the functional requirements. For the function modeling part, the hierarchical decomposition of the interactive task is considered : a function is required for each action. A function refers to an internal function belonging to the Semantic Core Component of the application. CUSTOMER
makes
made by
MAKING Cust-id Cust_firstname Cust_lastname 1-n Cust_address
1-1
ORDER
contains is contained in ORDER_LINE
Order-id Delivery-date Payment-mode 1-n
0-n
PRODUCT Product-id Product_price Product_label
FIGURE 6.3. An Entity-Relationship-Attribute model for the interactive task "Phone order" DEFINE ENTITY Customer; CONSISTS OF Cust_id, Cust_firstname, Cust_lastname, Cust_address; IDENTIFIED BY Cust_id; DEFINE ENTITY Order; CONSISTS OF Order_id, Delivery_date, Payment_mode; IDENTIFIED BY Order_id; DEFINE ENTITY Product; CONSISTS OF Product_id, Product_price, Product_label; DEFINE GROUP Cust_address; CONSISTS OF Street, Number, Zip_code, City; DEFINE RELATION Making; RELATES Customer AS Makes WITH CONNECTIVITY 1-N; RELATES Order AS Made_by WITH CONNECTIVITY 1-1; DEFINE RELATION Order_line; CONSISTS OF Quantity; RELATES Order AS Contains WITH CONNECTIVITY 1-N; RELATES Product AS Is_contained_in WITH CONNECTIVITY 0-N; DEFINE ELEMENT Quantity; DOMAIN OF VALUE ARE N(2); DEFINE ELEMENT Cust_id; DOMAIN OF VALUE ARE N(6); DEFINE ELEMENT Cust_firstname; DOMAIN OF VALUE ARE A(30); DEFINE ELEMENT Cust_lastname; DOMAIN OF VALUE ARE A(20); DEFINE ELEMENT Street; DOMAIN OF VALUE ARE X(30); DEFINE ELEMENT Number; DOMAIN OF VALUE ARE N(4); DEFINE ELEMENT Zip_code; DOMAIN OF VALUE ARE 1000 THRU 9999; DEFINE ELEMENT City; DOMAIN OF VALUE ARE A(32); DEFINE ELEMENT Order_id; DOMAIN OF VALUE ARE N(6); DEFINE ELEMENT Delivery_date; DOMAIN OF VALUE ARE X(8); FORMAT IS "##-##-##"; DEFINE ELEMENT Payment_mode; DOMAIN OF VALUE ARE "Cash","Credit card","Bank transfert" WITH CARDINALITY 3; DEFINE ELEMENT Product_id; DOMAIN OF VALUE ARE N(6); DEFINE ELEMENT Product_price; DOMAIN OF VALUE ARE N(5); DEFINE ELEMENT Product_label; DOMAIN OF VALUE ARE X(30);
FIGURE 6.4. The specification of the ERA model for the interactive task "Phone order"
A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype
6.5
83
Updating or Realization of Functional Requirements
Since the functional requirements are inherited from classical methodologies and from software engineering, they should be smoothly integrated within the methodology. In the past, designing an interactive application started from these requirements in order to derive the operational requirements (as in task analysis). Today, there is a shift of focus : the task analysis should be the starting point for deriving the functional requirements and not vice versa. If both task analysis and functional requirements have been done separately, they are merged during this process. If the functional requirements have already been done, they should be updated according to the task analysis in order to avoid incompleteness and inconsistencies. If the functional requirements have not yet been done before, they could be derived here from the task analysis.
6.6
Activity Chaining Graph Writing
Task analysis and functional requirements help to draw an activity chaining graph (ACG), which is a graph describing the information flow between the application domain functions which are necessary to perform the task goal highlighted in the task analysis. The ACG provides several benefits, the most important of which is to define clearly a functional invariant for the interactive task, independently of user stereotypes. Should the task be performed, this functional and business logic should be followed, no matter the user.
