Issue
Article
Vol.28 No.3, July 1996
Article
Issue
Issue |
Article |
Vol.28 No.3, July 1996 |
Article |
Issue |
Intelligent tools to support user interface building are being developed as a response to the difficulty of implementing interfaces of increasing complexity [1, 5, 6, 10, 7]. These tools provide expert assistance to insure that usable interfaces are developed correctly, by formalizing guidelines and criteria which are well known to experts. Less effort has been devoted so far to the objective of supporting the cooperative work of designers and final users in defining how the interface should look like and behave, in evaluating design alternatives and in assessing consequences of changes. This objective becomes relevant when the interface is built in strict cooperation with customers who are not familiar with computers, and by applying iterative design principles. At the same time, it is a common opinion that tools able to support formal evaluation of interfaces might be of help to avoid engaging into expensive empirical evaluations before trivial errors are eliminated from the prototype.
A particular specification problem occurs when several categories of users, with distinct backgrounds and needs, are expected to use the system which is being designed: in this case, the interaction style is customized to the context in which the system operates, and the tool should enable simulating and evaluating the different behaviours in a unified way.
This paper describes a tool which aims at responding to the mentioned objectives: XDM (Context-Sensitive Dialogue Modeling) extends Coloured Petri Nets to specify context-customized interfaces in a task-based way and to simulate their behaviour in defined contexts. By integrating this modeling approach with KLM theory [2], XDM also enables evaluating (in an automatic or semi-automatic way) whether the interface is correct and usable.
First we will show how a designer can employ the tool in the stepwise building of the interface by extending Coloured Petri Nets with functions associated to places and transitions: this extension provides a logical and physical description of tasks performed, actions that enable performing them, information displayed and their layout. Then we describe how interface behaviour can be simulated in several contexts. We go on to show how designers can verify whether the interface is correct and usable. State of the art and future developments are discussed in the final section.
In the formal modeling method implemented by XDM [3], an interface is described by a triple: <CPN, CLP, CPhP>, where: CPN is a Coloured Nested Petri Net [8, 14, 16], CLP is a coloured logical projection function and CPhP is a coloured physical projection function. CLP establishes a relationship between transitions and tasks and between places and information displayed, in a specific context which is described by a first-order logical formula. CPhP establishes a relationship between: (i) tasks, user actions needed to perform them and interface techniques employed, and between (ii) information displayed, its layout and corresponding interface objects employed, in a particular context. Single elements of the logical and physical projection functions then describe the task that is performed when a transition is fired (with the user action which activates it) and the information that is displayed when a place becomes marked (with its physical layout). Nesting on transitions supports a top-down description of the interface in a task-oriented way: this approach allows to scale up the complexity that arises when specifying interfaces for complex tasks.
Our tool assists interface designers in building XDM models; these models can then be employed to simulate the interface behaviour in various contexts and to make some usability measurements. To give examples of how the tool can be employed, we will take the case of a simple Netscape-like World Wide Web browser, and we will describe interaction during browsing through the pages of our Research Group. To illustrate context-adaptation issues, we will assume that these pages are tailored to the user characteristics. For example: the format of pages and their links may be different for students or computer scientists, for those who want to see images and those who do not, for those who speak Italian or English.
Specifying a context-customized interface with XDM is made through the following steps:
the definition of `context' and the features that describe it depend on the application domain. Examples of such features are the following: (i) categories of users whose needs of interaction with the system are `homogeous', (ii) site in which the system is installed, (iii) interaction language.
Each context is represented by a non quantified ground formula in a first order language.
In our example, the context `a student in computer science from Bari who doesn't want to see images' can be formalized as Job(STUDENT) and Language(ITALIAN) and NOT Show(IMAGE) and the context `an English-speaking researcher' as Job(RESEARCHER) and Language(ENGLISH).
Other context features are defined according to results of system's processes. For example, `positive result in locating the specified URL' is expressed as Correct(LOCATION).
Every elementary task corresponds to an elementary system function; every non-elementary task can be performed by an appropriate chaining of elementary tasks. In some phases of interaction, several tasks may be activated, and the user must decide which one to perform. Synchronization conditions can be established among tasks that must be terminated at the same time.
For example: the main task of our model is to `Browse through a Web'.
This task can be subdivided into the following subtasks:
Task 1) must precede all the others. Task 2) must precede tasks 3) and 5); task 3) can be performed only during loading; task 5) can be done only after loading has been completed successfully; tasks 7) and 8) can be done (respectively) only after at least a new page has been loaded or one has gone back to a previous page. Task 9) is active during the whole process.
Some of these tasks are complex; for example: `Browse through a page'. Others are elementary; for example: `Go to the next page': this task is performed by just clicking on the `Forward' button.
As the user view is the perspective which guides XDM modeling, conditions and effects of tasks are seen in terms of information displayed before and after each task is performed.
For example: to Open the Browser, the correspondent symbol command has first to be displayed. After this task has been performed, the display will show a group of commands (Stop Loading, Select Location and Quit) and the home page if the default location address was correct, or an Error Message if it was incorrect. The Feedback Message is also displayed on this screen.
Each PN describes a task; in a PN, transitions represent the tasks and places the information which is displayed after a task has been performed. The top-down description of tasks which was made in step b. is reflected into the PN structure by nesting PN names on some transitions: an elementary task will then correspond to a non-nested transition, whereas a complex task will be represented by a sub-PN, which is nested to the transition of a higher level PN. Alternative tasks are represented as sequences starting from the same place; concurrent visual display is represented by places being the postset of the same transition; synchronization in the ending of task sequences is represented by closing the corresponding paths with the same transition.
Figure 1 shows the main PN for the task Browse through a Web. In this figure, after T1 has fired, places P2 and P3 are both marked.
Three alternative sequences can be activated from place P2, by, respectively, firing transitions T2, T3 or T4.
In CPNs, a condition Cond (Pi) can be attached to a place Pi, to specify the cases (i.e., the contexts) in which that place can be marked. A transition guard Tg(Tj) can also be attached to a transition Tj, to restrict the cases in which that transition can `fire'.
In our PNs, places and transitions to which a condition is attached are `starred'.
In this example: Cond (P4) = NOT Correct (LOCATION); Cond (P5) = Correct(LOCATION);
Tg(T3) = Loading(PAGE).
A logical projection function is associated to transitions and places, describe (respectively) tasks that the user can perform in each context and information displayed as a result of performing that task.
Figure 1 shows the logical projection of the Browse WWW Net. Besides the aspects that we have already illustrated, the following ones are worth mentioning:
Figure 1: XDM in the `Model Description' mode: this figure represents the task of `Browsing through a Web' (Petri Net with its logical projection function)
No adaptation to user characteristics is shown in this PN, because this task is performed in the same way by all users: we will show an example of user-adaptation later on, when we will illustrate the `Browse through a page' subnet.
When the environment to be employed in developing the interface is selected, the following items are defined:
In the example that we are illustrating, the environment is the one employed by the browser and is dependent on the HTML tags. This is based on the following interaction objects:
Interaction objects can be assembled into macro interaction objects. For example: groups of buttons; groups of textfields (form=FR), windows (W) and pages (P). Macro interaction objects implement macro places, which are represented, in our PNs, with a star (for instance, P2 in Figure 1).
Interaction techniques are the following:
To complete the interface description, the designer has to generate all interaction objects that should appear in different contexts and phases of the dialogue. The database of these elements is linked to the Petri Net by means of the CPhP function.
Table 1 shows the physical projection of the Petri Net in Figure 1: as this Net is independent of the loaded page, interaction objects and techniques employed in this Table are those defined in the Netscape-like browser; for instance: icon buttons to Open Browser, Stop Loading and Go to the Previous or the Next Page; a text button to quit the Browser, .... and so on.
Table 1: Physical Projection of the PN in Figure 1
information layout task performed user action displayed
Browser symbol icon button Bi1 Open Browser click on Bi1 (SB)
Quit command text button Bt1 Quit Browser click on Bt1 (SB)
Location field textfield T1 Stop loading click on Bi2 (SB)
Feedback message text message Ct1 Specify location fill T1 (FT(n))
Stop command icon button Bi2 Acknowledge click on Bt2 (SB)
Error Message
Error message page P1 Browse a page see Subnet
Loaded HTML page page P2 Scroll Page click and drag the
scroll button (SC)
Back command icon button Bi3 Go to previous page click on Bi3 (SB)
Forward command icon button Bi4 Go to next page click on Bi4 (SB)
To see an example of adaptation to the context, let us look at Figure 2, which shows the `Browse through a page' subnet which was nested on transition T6 in Figure 1. The start place of this net reproduces P5 in Figure 1 and corresponds to one of the pages of our WWW. This page is adapted to the context, and Figure 2 shows two examples of such adaptation, by displaying how it looks like to students and to researchers.
Figure 2: XDM in the `Model Description'mode: this figure represents the physical projection of the petri Net in Figure 1
From this macroplace, several browsing possibilities are given to the user according to his/her characteristics: a list of items dealing with `teaching' activity, for students, or with `research' for researchers. These browsing possibilities are represented by a set of transitions starting from P5.1: a guard is associated to each transition, to specify the context in which the transition can fire, and the corresponding link can be navigated.
After a model has been built, the designer can examine the interface specification, simulate its behaviour in different contexts and evaluate (in an automatic or semiautomatic way) some interface properties.
A model can be selected, displayed and modified. In particular, when an element (place or transition) and a context are selected, a table look up enables displaying all labels attached to that element: conditions, logical and physical projections and name of the nested PN, if any.
The designer can simulate how the system will behave when performing a task in a particular context. This function is performed in two main steps:
After clicking on the `Context' icon and on the `Setting' menu item, one enters a context formula. For example: a foreign student who doesn't want to see images will be represented as:
Job(STUDENT) and Language(ENGLISH) and NOT Show(IMAGES);
XDM attaches to the start place of the selected PN an initial marking which corresponds to the specified context. It then propagates markings according to the following algorithm:
When, during simulation, a transition is enabled, a pop-up message indicates the action that the user can perform and the task that is achieved with this action. If simulation is in `AUTOMATIC', when the system comes to a situation in which several transitions are enabled, it asks to the user to select one of them. In the `STEPWISE' mode, the system stops at every transition, to require the user's intervention. When a place becomes marked, the physical projection of that place is displayed in a popup window. When the place becomes unmarked, that window is closed. Firing of a sequence of transitions then results in a sequence of popup windows' displays. Figure 3 shows an example of simulation of the `Browse through a page' subtask in the context defined sub a. In this figure, the start place (P5.1) is marked, and the rightside window shows how the page associated to P5.1 will look like. Only four transitions are enabled (those whose transition guards match with the settled context: T5.2, T5.3, T5.4, T5.5). The leftside window displays the tasks that are associated to these transitions: if the designer selects one of these transitions and clicks on the `FIRE' button, the simulation will go on through the selected path.
When the dialogue comes to a nested transition, the user can either `go down' to simulate the corresponding task (by clicking on the DOWN button) or go on with the simulation in the same (top level) Petri Net.
Figure 3: XDM in the `Simulation' mode: this figure represents part of the simulation of the task `Browse a Page' in the context `English-speaking students who do not want to see images'
Formal Evaluation
Two types of formal evaluation can be made with XDM: correctness and usability.
Given a context, a task and the description of access rights to that task in that context, one can verify:
Both properties are verified by applying the coloured marking propagation algorithm described in the previous Section. If the end place is not reachable when it should be so, the deadlock point is discovered and notified.
An example of evaluation of interface correctness in the task which was modeled in Figure 1 is the following: the end place P8 can be reached by following (alternative) paths:
Two types of properties which affect usability can be measured [15, 11, 13]: Complexity and consistency.
The complexity of the sequence of actions needed to perform a task in a specific context can be evaluated by computing the sequence of transitions that bring from the start place to the end place, in the PN which describes that task, in that context. The complexity of each elementary task can be estimated in terms of the expected execution time (in units of tenths of seconds) of the elementary interaction technique by which it is performed.
We measure the complexity of elementary interaction techniques by expressing them as a function of KLM standard primitive external operators [9]: press or release a mouse button (b), move cursor to point to a target coordinate (p), press a key (k), homing (h).
For example: Select a button: SB = SLK = pbb; Select a Setting item or a Menu item: SS = SM = pbpb.
Kieras estimates execution times (i) for b and p operators to be, respectively, of 0.1 and 1.1 seconds, (ii) for k, of 0.2 seconds -on the average- for a skilled typist and (iii) for h, of 0.4 seconds. The execution time of each interaction technique can therefore be estimated in units of tenths of seconds by summing up execution times of KLM operators in their expressions.
For example: Compl (SB) = Compl (SLK) = 13 units;
Compl (SM) = Compl (SS) = 24 units; Compl (FT(n)) = (17 + 2n) units.
By clicking on the button `COMPLEXITY' and selecting the pull down menu item `Action', the designer can compute (for example) the complexity of reaching a page from the start node, when the user makes an error in specifying the location. Figure 4 shows that the estimated time complexity for this task is equal to 2*Compl(SB) + Compl(FT(n)) + Compl(FT(m)), that is: (60+2(n+m)) units.
This measure is only a function of user actions, and does not take into account possible delays due to system's answer: in the previous example, time due to looking for the specified URL and loading a page;
The complexity of a display layout in a specific context is a function of the amount of information that is displayed at the same time. Display complexity in a specific context is a function of the number of places that are marked, in that context, in the CPN and of the complexity of each macroplace.
By clicking on the button `COMPLEXITY' and selecting the item `Display', the designer can compute the complexity of a page. Figure 4 shows an example of this evaluation: the display complexity associated to marked places in the figure includes three icon buttons, 2 text button and two text messages, one corresponding to the feedback and the other to the error message. By means of this function in XDM, the designer can compare the interface complexity in different contexts or evaluate alternative solutions for an interface.
Figure 4: XDM in the `Verification' mode: this figure represents how action and display complexity can be assessed automatically
XDM can assist the designer in assessing whether actions that a user has to make to achieve specific tasks in a specific context are consistent across the whole dialog: this is true if similar tasks that are attached to different transitions are performed, by that category of users, by similar actions (action consistency). Likewise, the display layout is consistent if similar information items are displayed, in different phases of the dialogue, by similar layouts and if, when displayed at the same time, they are assembled into the same window or are located in the same region of the screen.
To assist the designer in action and display consistency analysis, XDM exploits knowledge in logical and physical projection tables. Elements of these tables are sorted out so that, if the same task is performed in several phases of interaction, XDM checks automatically that it is always performed with the same action. As for similar tasks, the actions that enable activating them are shown to the designer, so that he (or she) can verify that they are consistent. The same type of checks is made for information items. A complete automation of this aspect would require representing the semantic structure of tasks and of information items, that at present is not supported by XDM.
We developed the interface of XDM with Devguide, under OpenWindows. Petri Nets are built with a non commercial tool (Cabernet: see [12]) and are saved in a file. They are then integrated with other components (conditions on places, transition guards and logical and physical projection functions) which complete description of the model. The XView user interface code is integrated with application code in C++, that implement the described functional modules.
We employed the XDM modeling approach for the first time, as a cooperative specification and design method, in the scope of a European Community Project which was aimed at prototyping a knowledge-based system for drug prescription [5]. In that context, XDM proved to be very suggestive in modeling static and dynamic aspects of interaction and in showing to industrial partners and to medical end-users how the system was going to behave in different contexts. We could also compare, in terms of usability, alternative solutions to some interaction problems and assess consequences of introducing changes in the interface. The Project ended up with an empirical evaluation of the prototype, where the interface correctness and usability was carefully evaluated: by means of XDM, we could avoid a lot of trivial errors in this prototype, by making these checks on the formal model, before the prototype was delivered.
In that experience, however, we could verify that our modeling approach was rather time-consuming, and that a tool to support the specification and the verification phases could help us in simplifying the work. We now employ the method in all research projects and teaching activities which involve prototyping an interface. It happens frequently that errors in the design are discovered by just `giving a look' at Petri Net structures, and that our students understand and discover usability pitfalls in their interface, after verifying its model with XDM.
The next step of this research will aim at including into our tool an `intelligent' component, to support designers in passing from the task specification phase to building XDM models. We could verify, in our experience, that translating the task structure of a user-customized system into a correct Coloured Petri Net is not always easy: errors can be made, in particular, in establishing which task sequences have to be performed in alternative, how they should be synchronized and which information should be displayed concurrently. We are convinced that, if this knowledge-based component will be added to XDM, it will contribute to promoting iterative interface design and evaluation experiences.
Fiorella de Rosis and Sebastiano Pizzutilo
Dipartimento di Informatica
Universita' di Bari
Via Orabona, 4 - 70126 -Bari - Italy
derosis@gauss.uniba.it
pizzutil@gauss.uniba.it
http://aos2.uniba.it:8080/IntInt.html
Berardina De Carolis
Dipartimento di Discipline Scientifiche
III Universita' di Roma
Via della Vasca Navale 60 -Roma - Italy
nadja@aos2.uniba.it
http://aos2.uniba.it:8080/nadja.html
Issue |
Article |
Vol.28 No.3, July 1996 |
Article |
Issue |