HCI International 93 Conference, August 8-13, 1993, Orlando, Florida, USA 5 th International Conference on Human-Computer Interaction joinly with 9th Symposium on Human Interface (Japan)
Contextual help for free with formal dialogue design Ph. A. Palanquea, R. Bastidea and L. Dourteb a
L.I.S., Université Toulouse I, Place Anatole France, 31042 Toulouse Cedex, France. Email:
[email protected],
[email protected] b
D.I.R.O., Université de Montréal, C.P. 6128 succursale A, Montréal (Québec), H3C 3J7, Canada. Email:
[email protected]
Abstract This paper presents how the contextual help system for a user-driven application may be generated automatically from the formal specifications of the application. In our case the formal specifications are based on Petri nets and the help system is built by transforming the Petri nets in an augmented transition network. This network is then used by the contextual help system in order to answer users' questions. 1. INTRODUCTION The use of formal methods in the design process of user interfaces has been advocated by numerous research works [1, 2]. They allow for the making of concise, unambiguous and complete specifications of the dialogue part of humancomputer interaction. One formalism, Petri nets, have been used for a long time in the design of human-computer interfaces [3, 4]. In previous papers we have presented such a formal method based on Petri nets and integrated in an object-oriented framework [5, 6, 7]. Building on the huge amount of research work done in Petri net theory, this method allows to analyse and validate the dialogue specification in order to statically verify properties of the behaviour of the interface [8, 9]. This paper's aim is to demonstrate another benefit of this method, the ability to automatically generate an important part of the contextual help system in a way which is not usually achieved. Contextual help is specifically concerned with the current state of humancomputer interaction and should ideally answer three basic questions that the user may be interested in: "what?", "why not?" and "how?". The question "what?" corresponds to the interrogation "What can I do from now on?". In user-driven interfaces, the screen presented to the user must reflect the
internal state of the application. It is therefore possible to determine visually which actions are currently enabled. This feature is commonly achieved in most present software by greying out or otherwise inactivating the widgets which allow to trigger the actions that are not available. The question "why not?" naturally comes to the user's mind as soon as he wishes to trigger an action whose triggering widget is currently greyed out. In current software, usually not only is the question unanswered but it cannot even be asked. Actually a user's action on a greyed out widget is simply ignored. The question "How?" stands for "How can I make that action available again?". The answer to this question should naturally complement that of the question "why not?" by providing the sequence of commands to trigger in order to enable the desired command. 2. USER ACCESS TO CONTEXTUAL HELP We model in this paper the Select-Cut-Copy-Paste functions of a word processing application to demonstrate how users may access the contextual help. Novice users may be puzzled if they find several inactivated menu items when they open the Edit menu. For example, when there is no selection on the screen, the Cut and Copy functions are not available.
Ph. A. Palanque , R. Bastide
a
a
b
Abstract
Figure 1. An example of a contextual help window within a word processing application.
In our proposed help system, the tentative triggering of an inactivated widget is interpreted as a request for contextual help on that item. This request results in the opening of a help window, presenting the answers to the questions "Why?" and "How?". An example of such an help window is shown in Figure 1: in the situation depicted, the user wished to copy while there was no selection. Figure 1 shows the open Edit menu of a word processing application from which the help has been triggered, as well as the help window with the answers generated automatically. ButtonDn T1
T2 ButtonDn
Selection Started
ButtonUp T3
Drag
T4
Selection Confirmed
T5
ButtonUp Selection
No Selection
T6
Paste
T7
Paste
T8
Copy
Cut
T9
Clipboard
Figure 2. A high-level Petri net modelling the Select-Cut-Copy-Paste functions. 3. FORMAL DESCRIPTION OF THE DIALOGUE The formal description of the Select-Cut-Copy-Paste functions is modelled by the high-level Petri net (HLPN) depicted in Figure 2. In the framework of our method we use a dialect of HLPNs, called Petri Nets with Objects (PNOs) [5], which is particularly well suited for the design of user-driven interfaces because of its ability to handle objects (in the object-oriented sense) instead of simple tokens (as in regular Petri nets) in the reachability of places. Such a simple example does not require the most advanced features PNOs, so the net modelling it can therefore be read and interpreted as a conventional predicate/transition net [10].
A net models the potential evolution of the dialogue in the following way: any user action is associated with one or several transitions in the net (the name of the action is inscribed inside each transition). An action may be triggered if at least one of its associated transitions is enabled in the net (i.e. each of the transition's input places holds at least one token). If the action may not be triggered (none of its associated transitions is enabled), the widget or menu item triggering this action must be greyed out. With this semantics, the question "What?" is automatically answered by the set of all enabled transitions in the net. A marking m is an assignment of tokens to the places of a Petri net. The number and position of tokens may change during the execution of the Petri net [11]. The initial marking (i.e. before the start of the execution) shown on Figure 2 models the state of the interaction when the application is launched. In that state, only places Clipboard and No Selection hold a token: the clipboard is supposed to contain the results of previous interactions, and the selection is initially empty. From that state, the user may (for instance) try to select something by pushing the mouse button (transition ButtonDn), then dragging the mouse (transition Drag) and finally releasing the button (transition ButtonUp). When a selection is done (i.e. there is a token in place Selection, and no token in place No Selection), the functions Copy and Cut are activated. 4. AUTOMATIC HELP GENERATION The question "Why not?" may be answered by examining the net's marking (as may be done for the question "What?"): an action is unavailable only if none of its associated transitions is enabled by the current net marking. The question may be answered by listing all the places that lack a token in order for one of its associated transition to be enabled. For example, from the initial marking stated on Figure 2, the function Copy is not available because the place Selection holds no token. The answer to the question "Why not Copy?" is therefore "Because Selection is empty". The answer to the question "How?" requires the use of formal techniques from Petri net theory, namely the construction of the net's reachability graph [11], which may be done automatically. In a reachability graph, each node represents a reachable marking of the net, and an arc flowing from node n1 to node n2 corresponds to the transition whose occurrence transforms marking n1 into marking n2. A reachability graph is, in finite cases, a finite state automaton, or an augmented transition network [12] if there is an infinite set of nodes [6]. The reachability graph corresponding to the net in Figure 2 is depicted in Figure 3. The markings must be read in the order (Selection Started, Selection Confirmed, No Selection, Selection, Clipboard). This graph is a finite state automaton whose initial state is the marking (0,0,1,0,1). From this initial state, for example, there is no arc labelled with Copy, which means that the action Copy is not available. To answer the question "How?", the reachability graph must be used in the following way: starting from the current state, we must proceed in a breadth first search in the graph, looking for a state featuring an output arc labelled with the desired action. When the path is found, the answer consists in listing the sequence of commands labelling the arcs on the path. The breadth first search ensures that this sequence is the shortest one.
For example, starting from the initial state outlined, the Copy command is not available. The search on the reachability graph provides the following path to activate it: ButtonDn, Drag, ButtonUp; the answer to question "How to Copy?" would therefore be: First do Button Down Then do Drag Finally do Button Up. T6 / Paste
T3 / ButtonUp
(0,0,1,0,1)
T1 / ButtonDn (1,0,0,0,1)
T9 / Cut
T7 / Paste
T2 / ButtonDn
T4 / Drag
(0,0,0,1,1)
T8 / Copy
T5 / ButtonUp (0,1,0,0,1)
Figure 3. Reachability graph of the Petri net modelling the Select-Cut-Copy-Paste functions. The answers to both questions "Why not?" and "How?" are shown in Figure 1, as computed by the help system. Obviously, a little more work would be necessary to generate more correct English output. This could be achieved by associating a natural language help message with each transition of the Petri net. 5. CONCLUSION This paper only presents the automatic generation of contextual help which is part of a more general interface design method integrating Petri net modelling into the object-oriented approach. The method, called Petri Nets with Objects, addresses the well-known drawbacks of classical Petri nets by allowing the structuring of models in an object-oriented way (encapsulation, inheritance, clientserver relationship, etc.). A design process for building user-driven interfaces is supported by the method by providing a set of methodological rules helping the designer to build his models [13]. Actually our efforts are on the building of a development environment supporting this method. This environment will integrate a graphical presentation editor, a syntactic editor allowing the edition of PNOs, several analysis modules allowing to prove design properties of the models and a PNO interpreter acting as a run-time kernel.
6. REFERENCES 1 2 3 4
5 6 7 8 9
10
11 12 13
U.H. Chi, Formal specification of user interfaces: a comparison and evaluation of four axiomatic approaches. IEEE Transactions on Software Engineering 11, 8 (August 1985), 671-685. W.R. Van Biljon, Extending Petri nets for specifying man-machine dialogues. International Journal of Man-Machine Studies 28, (1988), 437-455. M. Zizman, A System for Computerisation of Office Procedures, Ph.D. thesis, Warton School of Management, 1977. H. Oberquelle, Human-machine interaction and role/function/action-nets. In W. Brauer, W. Reisig and G. Rosenberg, eds., Petri nets: applications and relationships to other models of concurrency, Lecture Notes in Computer Science 254 & 255, Springer-Verlag, Berlin, 171-190. C. Sibertin-Blanc, High level Petri nets with data structure. In 6th European Workshop on Petri Nets and Applications (June 1985, Espoo, Finland). R. Bastide and P. Palanque, Petri nets with objects for the design, validation and prototyping of user-driven interfaces. In D. Diaper et al., eds., HumanComputer Interaction - INTERACT'90, North-Holland, 1990, pp. 625-631. R. Bastide and C. Sibertin-Blanc, Modelling a flexible manufacturing system by means of Cooperative Objects. In Computer Applications in Production and Engineering: Integration Aspects (CAPE'91), North-Holland. P. Palanque, Modélisation par Objets Coopératifs Interactifs d'interfaces homme-machine dirigées par l'utilisateur. Thèse de doctorat de l'Université Toulouse I (France), 1992. P. Palanque, C. Sibertin-Blanc and R. Bastide, Validation du dialogue par analyse d'une spécification fondée sur les réseaux de Petri. In Actes IHM'92 Quatrièmes journées sur l'ingénierie des interfaces homme-machine (30 nov., 1 et 2 déc. 1992, Paris), Telecom Paris, 1992, pp. 121-127. H.J. Genrich, Predicate/transition nets, in W. Brauer, W. Reisig and G. Rosenberg, eds., Petri nets: applications and relationships to other models of concurrency, Lecture Notes in Computer Science 254 & 255, SpringerVerlag, Berlin, 207-247. J.L. Peterson, Petri Net Theory and the Modeling of Systems. Prentice-Hall, Englewood Cliffs, N.J., 1981. W.A. Wood, Transition network grammars for natural language analysis. Communications of the ACM 13, 10 (October 1970), 591-606. P. Palanque, R. Bastide, L. Dourte and C. Sibertin-Blanc, Design of userdriven interfaces using Petri nets and objects. In Fifth Conference on Advanced Information Systems Engineering (CAISE'93) (8-11 June 1993, Paris).
