HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
Escapes and help systems pose problems that are similar to the combinatorial explosion from concurrent dialogs. Imagine that we have been observing the use of the drawing tool. We have noticed that users often find they have wrongly selected some option and want to get back to the menu. As the dialog is currently specified, once they select, say, the circle option, they must select two points before they are allowed to continue. As the current system does not have any deletion at present, this was found to be particularly irksome.
The case of a help system is very similar to concurrent dialogs (in fact it is an embedded dialog), and the total number of states in the full diagram is again the product of the number of states in the help system times the number in the original system.
One of the oldest formalisms in computing science is the Petri net. It is a graphical formalism designed for reasoning about concurrent activities. In recent years it has been used by several researchers to specify aspects of single-user [187] and multi-user systems [188]. In an STN the system is always at exactly one state. Indeed, you can simulate the behaviour of the system by moving a counter around the STN following arcs. A Petri net is similar except that the system has several 'states' at once. These are depicted as several black counters in Figure 8.11.
Harel's state charts can be seen as a form of STN. They were developed as a way of visually specifying complex reactive systems and address many of the problems described above, for example concurrency and escapes, while still retaining a diagrammatic representation. They are characterized by a hierarchical structure, but not used as we have seen before to split a diagram up. The hierarchy in state charts is used within a single diagram to add structure, and to show which parts represent alternative states (like simple STNs) and which represent concurrent activity.
The definitions of named non-terminals gave a natural structure to the interface description. In addition, recursive definitions of non-terminals allowed the dialog to represent iteration. However, BNF has no way of representing concurrent dialogs, nor can it easily deal with pervasive commands like escapes or help systems. Note, however, that both BNF and regular expressions (described below) are focused upon the user's actions, as opposed to the concentration upon the state in STNs.
No regular expression using Kleene star can express that the brackets must match. The best that you can do is say that the sentence is any number of words, open brackets or close brackets. In fact, regular expressions are as powerful in what they can express as STNs, it is just that BNF is more expressive. Whether that matters or not depends on whether the dialogs you want to represent include complex recursive elements such as bracket matching. Like STNs, neither BNF nor regular expressions can handle concurrent dialogs or escapes.
Concurrent dialog elements may be represented easily using production systems as many rules may be active at the same time. For example, we can describe the bold/italic/underline dialog box of Figure 8.5, using mixed event/state production rules. We have three attributes:
We have seen notations such as STNs which are very good at handling sequential dialog, but weak on concurrency, and production rules which are good at the opposite. The problem of dealing with both sequential and concurrent behaviour is common to many other areas of computing, such as telecommunications protocols and concurrent programming. We have already seen how one notation, Harel's state charts, which was designed with such complex systems in mind, has been used in interface design. Process algebras are a class of formal notations which have been developed to handle similar situations. One of these, CSP (Communicating Sequential Processes), has been adopted for dialog specification as part of several formalisms, including Alexander's SPI [7] and Abowd's Agents [1].
Concurrent processes can also be used as a way of organizing the internal structure of the interface. For example, returning to the drawing tool, we may decide that we would like to allow keyboard short cuts activated by the alt key. As the line and circle options can be operated by the mouse or by the keyboard, we have a process for each. The mouse process simply waits for the user to select one or other menu option, and then performs an internal event depending on the choice. The keyboard process monitors the alt key, and performs the same internal events depending on whether the user enters alt-C or alt-L:
Mouse = ( select-circle? Æ int-sel-circle Æ Mouse
[] select-line? Æ int-sel-line Æ Mouse )
Keyboard = alt-key-down? Æ ( Alt ; Keyboard )
Alt = ( alt-key-up? Æ skip
[] c-key? Æ int-sel-circle Æ Alt
[] l-key? Æ int-sel-line Æ Alt ) -->
One important difference in expressive power is whether or not the formalism can handle concurrent dialogs. We found that some notations favour sequential dialogs (for example, STNs) and some concurrent (for example, production rules), but few could handle both (the exceptions being Harel state charts and CSP). However, increased expressive power is not always desirable as it may mean a more complex and less easily understood description. The important point is to match the notation to the form of the desired dialog. Another important distinction was between state-oriented and event-oriented descriptions. This will be picked up in the next chapter.
processed in 0.007 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |