HUMAN-COMPUTER INTERACTION
SECOND EDITION
Another obvious stopping point is where the task contains complex motor responses (like mouse movement) or where it involves internal decision making. In the first case, decomposition would not be productive; explaining how such actions are performed is unlikely to be either accurate or useful. In the second case, we would expand if the decision making were related to external actions, such as looking up documentation or reading instruments, but not where the activity is purely cognitive. A possible exception to this would be if we were planning to build a decision support system, in which case we may want to understand the way someone thought about a problem in order to build tools to help. However, it is debatable whether HTA is the appropriate technique in this case.
Alternatively you may be asked to change the interface style or fit the program with a mouse- and window-based interface -- is this difficult? Remember, this is a short program which is almost all interaction with the user and should be relatively easy. Imagine a program of 10,000 or 100,000 lines. Various commercial applications began their life on traditional text-based terminals, but are now available on Windows or Macintosh platforms. The ancestry of such programs is often all too obvious -- not really surprising.
Consider a simple mouse-based drawing tool. It has a menu with two options, 'circle' and 'line', and a drawing surface. If you select circle you are allowed to click on two further points on the drawing surface. The first of these is the circle's centre and the second any point on the circumference. After the first point is selected the system draws a 'rubber band' line between the centre and the current mouse position. After the second point is chosen the circle is drawn.
The 'line' option in the menu is to draw a polyline. That is, the user can select any number of points on the drawing surface which the system connects with straight lines. The last point is denoted by a double-click on the mouse. Again the system 'rubber bands' between successive mouse positions.
Between the states are arrows, the transitions. These are labelled with the user actions that triggered the particular transition and the response the system makes. For instance, state Circle 1 is where the system is waiting for the user to select the circle's centre. If the user clicks on a point, the system moves into state Circle 2 and responds by drawing the rubber band between the point and the current mouse position. From this state, the user can click on another point, upon which the system draws the circle and then moves into the special Finish state. We can see from this that the STN is able to represent a sequence of user actions and system responses.
The use of hierarchical elements does not change the power of the basic notation as one can simply imagine gluing the subdiagrams into the main diagram. However, it makes it far simpler to specify large systems; it would not be unreasonable to specify a whole system dialog in this fashion, from the highest level down to individual keystrokes and mouse clicks.
This says that you must select the line option from the menu, click somewhere with the mouse, then click as many times as you like on intermediate points, and finally double click. It is assumed that the low-level terms select-line, click and double-click either are primitives, or have been defined elsewhere. The only other two notational forms that are used are sequencing, denoted by juxtaposition, and iteration, denoted by the Kleene star operator '*'. The former is similar to sequencing in BNF; it is the Kleene star operator which is characteristic of regular expressions.
The dialog manager which executes this form of production rule has a memory consisting of a set of events. A rule fires if the events named in its condition are all present in the memory. All interaction with the user is mediated by this event memory: user events, such as a mouse click, are added to the memory, and system responses, such as <draw line>, are removed and acted upon by the display controller.
Mouse: { mouse-off, select-line, click-point, double-click }
The first attribute, Mouse, is set automatically whenever the user performs the relevant action; the second attribute is used by the dialog to keep track of its state, and the last three are for controlling system responses. Again, we assume a display controller which acts appropriately upon these.
processed in 0.004 seconds
| |
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|