No earlier issue with same topic
Issue
Previous article
Article
SIGCHI Bulletin
Vol.28 No.3, July 1996
Next article
Article
No later issue with same topic
Issue

HCI in Italy: A Tool to Support Specification and Evaluation of Context-Customized Interfaces

Fiorella de Rosis, Sebastiano Pizzutilo and Berardina De Carolis

Introduction

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.

XDM Models

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.

Model Building

Specifying a context-customized interface with XDM is made through the following steps:

a. Defining the Contexts in which the System Should Operate

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).

b. Defining the Tasks in a Top-Down Way

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:

  1. Open Browser
  2. Specify location
  3. Stop loading
  4. Acknowledge an error in loading a page
  5. Browse through a page
  6. Scroll a page
  7. Go to the previous page
  8. Go to the next page
  9. Quit Browser.

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.

c. Describing each Task in Terms of Application Conditions and Effects

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.

d. Defining Dynamical Aspects of Interaction

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).

e. Completing the Definition of Logical Aspects of Interaction

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.

f. Selecting an Environment

When the environment to be employed in developing the interface is selected, the following items are defined:

  1. the user action by which each elementary task can be performed, and the interaction technique employed for each user action,
  2. the way in which each information item is displayed and the interaction object employed to display each item.

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:


    Setting=S;
    List=L;
    Button: Bt=text, Bi=icon, Br=radiobutton;
    Menu=M;
    Message: Gt=text, Gi=icon;
    Textfield=T;
    Checkbox=Cb;
    Link= LK.

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:


    Select a button=SB,
    Select a setting item=SS,
    Select a menu item=SM;
    Select a link=SLK;
    Scroll=SC;
    Select an item from a list of v items, w of which are displayed at the same time=SL(v.w);
    Fill a textfield of n characters by typing a string=FT(n).

g. Define Physical Aspects of the Interface

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.

Model Use

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.

Description

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.

Simulation

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:

  1. setting the context in which to simulate the interface behaviour.

    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);

  2. specifying the task, by giving the name of a Petri Net, and a simulation mode (automatic or stepwise), by clicking on the corresponding button.

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.

Correctness

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:

Usability

Two types of properties which affect usability can be measured [15, 11, 13]: Complexity and consistency.

Complexity

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


Consistency

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.

State of the Art and Future Developments

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.

References

1.
Byrne, M., D., Wood, S., D., Sukaviriya, P., N., Foley, J., D., Kieras, D., E., 1994. Automating interface evaluation. Proceedings of CHI 94, 232-237, 1994.
2.
Card, S. K., Moran, T. P., Newell, A., 1980. The keystroke-level model for user performance time with interactive systems. Communications of the ACM, 23, 7.
3.
De Carolis, B. and De Rosis, F. 1994. Modelling Adaptive Interaction of OPADE by Petri Nets In SIGCHI Bulletin, ACM, vol.26, 2.
4.
De Rosis, F., Pizzutilo, S. and De Carolis, B.,.Formal specification and evaluation of context-dependent interfaces. Submitted to ACM TOCHI, in revised version, in december 1995
5.
Foley, J., Kim, S., Kovacevic, S. and Murray, K., 1991. UIDE - An Intelligent User Interface Design Environment. In: Sullivan, J. and Tyler, S. (Eds). Architectures for Intelligent User Interfaces: elements and prototypes. Addison Wesley, Reading Ma, 339-384.
6.
Hartson, R., 1989. User-interface management and communication. IEEE Software, January, 62-70.
7.
Janssen, C., Weisbecker, A., Ziegler, J., 1993. Generating user interfaces from data models and dialogue net specifications. Proceedings of INTERCHI93, 418-423
8.
Jensen, K., 1983. Coloured Petri Nets and the invariant method. in: Proceedings of the Application and Theory of Petri Nets, Springer Verlag, 66, 166-180
9.
Kieras, D. and Polson, P. G., 1985. An approach to the formal analysis of user complexity. International Journal of Man-Machine Studies, 22, 365-394.
10.
Kim, W., C., and Foley, J., D., 1993. Providing high-level control and expert assistance in the user interface presentation design. Proceedings of INTERCHI 93, 430-437.
11.
Nielsen, J., 1993. Is usability engineering really worth it?. IEEE Software, november, 90-92.
12.
Pezze', M,. 1995. A customizable environment for the specification and analysis of real-time systems. Technical Report of the Dipartimento di Elettronica e Informazione, Politecnico di Milano, 1995.
13.
Reisner, P., 1993. APT: a description of user interface inconsistency. International Journal of Man-Machine Studies, +39, 215-236.
14.
Stotts, D. and Furuta, R., 1989. Petri-Net-based Hypertext: Document structure with browsing semantics. ACM Transactions on Information Systems, 7, 1, 3-29.
15.
Tullis, T. S., 1988. Screen design. In: Helander M (Ed), Handbook of Human-Computer Interaction. North Holland, 372-411.
16.
Van Biljon, W., R., 1988. Extending Petri nets for specifying man-machine interaction. International Journal of Man-Machine Studies, 28, 437-455.

Authors' Addresses

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

No earlier issue with same topic
Issue
Previous article
Article
SIGCHI Bulletin
Vol.28 No.3, July 1996
Next article
Article
No later issue with same topic
Issue