HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
So an int-sel-circle event may occur either because the circle option is selected from the menu or because the user typed alt-C. The existing definition of Draw-menu expects to be activated by the user's mouse selections directly, so this must be modified to accept these new internal events:
Note that the events int-sel-circle and int-sel-line are used to communicate, sending messages from the Mouse and Keyboard processes to the Draw-menu process. However, although this direction of causality is obvious from the context, it is not immediately apparent from the notation. The only clue is that the events form the guards of the choice operator in the Draw-menu process, but that is not an infallible indication. The reason for this ambiguity is that CSP does not recognize causality; events are simply synchronization points. There are times when such an interpretation is useful, but in most dialog descriptions the causality is important. One way to avoid this problem is to match events in pairs, as is done in some other process algebras writing, for instance, int-sel-line! for the sending of an event and int-sel-line? for the receiving of it. This loses us the special decoration for direct user input, but these may be listed separately. Alternatively, if the notation is to be typeset rather than in straight ASCII, one can use other pairs, such as x and xØ for send and receive.
There are two aspects to the dialog semantics, inward towards the application, and outward towards the presentation. The semantic part of the dialog should serve as a link between the two, performing as little as possible itself. Look back through the examples in this chapter and ask yourself how one knows that, for example, the lines drawn by the drawing tool are at the points indicated by the user's mouse location.
Augmented transition networks (ATNs) are a form of state transition network (see Section 8.3.1). In the ATN, the system is assumed to hold a set of registers, storage locations which the transition network can set and test. Recall that the arcs in an STN may be labelled with the event that causes the transition and the system response. In an ATN this is extended. The arcs have a condition as well as the event; the condition can refer to the system's registers and the arc is only followed if the condition is true and the event occurs. The system response is augmented to include not only feedback and display, but also the setting of registers. These registers can be used simply to describe more complex dialogs, for example a cash dispenser which retains your card after three wrong numbers. They may also be used to communicate with the application and to hold values from the mouse.
Production rules come in many variants and the link to the semantics is equally varied. Often the system's memory contains variables which can be used by the system to store input values such as the mouse position, and can then be examined by the conditions and actions of the rules. These variables may also be used to communicate with the underlying application, or the functions of this may be invoked directly by special forms of action. For instance, the following is a production rule which, when the user clicks within a target region, puts a dot at the mouse location and invokes the application routine 'another_point':
Extracting the dialog structure is only possible with some notations. The reason why it is not always possible, and is not usually possible for general interactive programs, is itself an important issue. Usually it is possible to isolate the parts that are responsible for input and output (identifiable by print, read, etc.). However, how these fit together into a dialog is masked by the surrounding code. In particular, what would be syntactic in a dedicated dialog grammar description may be coded semantically. For instance, in eventCSP, one could write
Text-editor = mouse-press --> set-selection
[] key-press --> add-char-to-text
It is often claimed that dialog design should be independent of the detailed design of the presentation and lexical details of the interface. That is, one begins by deciding on the functionality of the system, and then, possibly making use of cognitive models or task analysis, one designs the dialog to perform those functions. Finally, one designs the visual presentation of the system and the lexical bindings between keypresses and mouse movement and the more abstract dialog actions.
In fact, the dialogs described in this chapter have often involved detailed key bindings on their labels. For example, the STN for the graphics system in Figure 8.1 has arcs with labels such as 'click on point' or 'double click'. It could be argued that this is a fault in these descriptions. They should instead say things like 'enter a point', 'enter last point'. These actions could then be achieved with mouse clicks, or by typing coordinates.
Different types of interfaces have very different dialog styles. The normal dialog form of a command-based interface is verb--object, for example 'print fred'. However, mouse-based systems often have an object--verb syntax, for example select a file icon and then select 'print' from a menu. Although it is possible to mingle these styles, it is inadvisable as users expect to find a certain interface style with a particular medium. So, detailed dialog design must be dependent on the type of interface.
8.1 Complete the drawing tool STN in Figures 8.1 and 8.3 by writing dialog descriptions for the text and paint submenus. For the text submenu assume that there are three options: centred, left and right justified. The text is entered by clicking at a location in the drawing surface and then typing. You may initially assume that typing a line of text can be regarded as a single user
processed in 0.008 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |