Chapter 8
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 action. But later try regarding each character typed as an action. The paint submenu has two options: a pencil for freehand drawing and a paint pot for flood filling. The former is performed by holding the mouse button down whilst moving the mouse about to draw the line. The paint pot is activated by simply clicking the mouse over the area to he filled.
The STNs for the main menu and graphics subsystem are in the text. We only need to do the text submenu and the paint submenu. For each the overall structure is similar to the graphics submenu, that is the user selects an option, the STN 'branches' and then there is a description of each option's dialog.
First do the text submenu considering typing a line of text as a single user action. This is shown in Figure Ex8.1.1.
To consider individual letters being typed, we simply add a loop terminated by the user typing the enter key (Figure Ex8.1.2).
Finally, we do the paint submenu in Figure Ex8.1.3).
Note that the fundamental actions for the pencil drawing are pressing and releasing the mouse button, rather than clicking it. Remember the more complex behaviour of the watch when we considered button press and release separately. It is also worth thinking about the expected behaviour of the package on other options while the mouse is depressed. For example, when drawing lines, which position is registered, the one when the button goes down, or the one when it is released? Try it out on different drawing packages. There is a similar issue with menu selection and screen buttons. The scenario described in Section 9.4.5 is an example where the important location is where the mouse button is released. Look at different GUIs and their detailed interaction properties. You may be surprised at the differences!
8.2 Repeat the above exercise using different notations, grammars, production rules, JSD or CSP. You will need to specify the whole system from the main menu to the individual submenu selections such as circle drawing. Note the problems you have with each notation.
Below are partial descriptions in BNF and production rules. As a class exercise, different notations could be allocated to different groups of students and the answers compared.
drawing-tool ::= main-menu + drawing-tool main-menu ::= graphics-submenu | text-submenu | paint-submenu graphics-submenu ::= draw-circle | draw-line draw-circle ::= select-circle + choose-centre + choose-edge select-circle ::= position-mouse + CLICK-MOUSE choose-centre ::= position-mouse + CLICK-MOUSE choose-edge ::= position-mouse + CLICK-MOUSE text-submenu ::= select-left + choose-location + type-text | select-centre + choose-location + type-text | select-right + choose-location + type-text select-left ::= position-mouse + CLICK-MOUSE select-centre ::= position-mouse + CLICK-MOUSE select-right ::= position-mouse + CLICK-MOUSE choose-location ::= position-mouse + CLICK-MOUSE type-text ::= ENTER-KEY | PRINTABLE-CHAR + type-text
Notice the different styles possible. In the graphics submenu, the option selection and the action selections are each packaged up into a named subdialog (draw-line and draw-circle). However, in the text submenu the top-level description of each option is included within the definition of text-submenu. With all notations, there is a similarly wide degree of stylistic choice. Suitably named subdialogs can make the entire dialog far easier to read, but, on the other hand, too many levels of abstraction can be confusing.
Also notice that the BNF description does not distinguish between selecting a menu option or choosing a point on the drawing surface. Both are described as position-mouse followed by CLICK-MOUSE. At the level of user movements and keystrokes, this is perfectly accurate, but loses the clearly perceived difference. This might be a good time to look at the UAN notation [107], which does distinguish these.
Sel-graphics --> <pop-up graphics menu> Sel-text --> <pop-up text menu> Sel-paint --> <pop-up paint menu>
This could exhibit strange behaviour. Imagine that the user is in the middle of drawing a line (using the first description in Section 6.8.1). Then after selecting the first point (at which point the system event 'rest-line' is active), the user goes back to the top-level menu and selects 'text'. At this point the text pop-up menu appears, and the user is able to start putting text annotations on the drawing area:
Sel-left-just --> left-start C-point left-start --> left-type <typing cursor on> Type-line left-type --> <put text left justified> <typing cursor off>
The user selects left justified and goes to the drawing surface and clicks at a point. However, at this point there are two rules that can fire.
Whereas it is certainly the first of these that the user expects, the second is possible because the 'rest-line}' event is still active. Also looking back to the definitions in Section 8.4.2, we see that rubber banding would still be on during the entire text menu selection process.
There are various fixes for this. One way is to use 'clean up' rules as used in CCT in Section 6.7.2. For example, we would modify the top-level description so that it is not always active:
Sel-graphics main-active --> graphics-active <pop-up graphics menu> Sel-text main-active --> text-active <pop-up text menu> Sel-paint main-active --> paint-active <pop-up paint menu>
The submenu options are then altered to update these activity events (the semantic actions have been omitted for clarity):
Sel-line graphics-active --> start-line C-point start-line --> rest-line C-point rest-line --> rest-line D-point rest-line --> main-active
This now ensures that the user finished low-level dialogs before selecting new options at the top level.
8.3 Develop the JSD diagram in Figure 8.14, expanding the various nodes until you get to basic operations such as 'prompt "login"' or 'user types in password'. Expand the 'delete employee' node using the dialog style as described in Figure 8.13, and use your imagination for the rest.
This is a fairly simple exercise, and some of the nodes are expanded here. In Figure Ex8.3.1, the login subdialog is expanded, but it assumes that the user types the correct password during the login process. To change it to accommodate incorrect passwords would be inordinately complex for two reasons. Firstly, the JSD diagram does not distinguish between user choice (whether to add or delete a record) and system choice.
This is evident in both the change and delete subdialogs (Figures Ex8.3.2 and Ex8.3.3).
In each of these the actual updating of the file is put in an 'optional' box as the user may have answered 'N' (no) when asked to confirm the update. Secondly, making the dialog dependent on the password would mean that the rest of the dialog would sit under an 'option' box with another box to abort. This was acceptable in the delete and change subdialogs, but if this were applied to the login sequence, the resulting dialog would become degenerate and hide the normal hierarchical structure. This problem of whether or not to include exceptional cases and error behaviour is extremely complex. In the early stages of design it is the normal cases that one wants to consider. Later on one might refine the dialog descriptions, or alternatively annotate the normal description.
8.4 In the example of the digital watch (Design Focus, p311), what would be the dangerous states? Relate the lexical issues of the buttons for a digital watch to these dangerous states and provide some design advice. Does your own digital watch satisfy these criteria?
The time and alarm setting modes are dangerous states, in that we do not want to change either accidentally. Design advice would be to include some sort of guard that makes it difficult to get accidentally into the time-setting modes, or, alternatively, once within the modes, to make the buttons that advance the time difficult to press.
The watch in the Design Focus guards these states by requiring button 'A' to be pressed for two seconds before the mode changes. It might be easy to press a watch button accidentally, but it is quite hard to hold it down. This solution would not of course work for a keyboard, where it is quite easy to hold a key down accidentally. Other watches guard these modes by insetting the mode change button or the buttons required to actually change the time. One has to press these buttons with a sharp instrument, such as a pencil -- not an easy slip to make. Some digital clocks guard the mode by making you hold a button down continuously while you are changing the time. Guarding the mode is far preferable to guarding the change buttons, as the latter makes it very hard to change the time when you want to do it.
In fact, changing the time is often a problem for the reversibility of watch and clock dialogs. Typically there is a button to advance the time by one hour or one minute, but not one to put the time back. So, if you press the minute advance button once too often, you have to press it 59 more times to reverse the mistake!
HCI 2e home page || changes and additions || resources || search || contents || authors || ordering | |
feedback to feedback@hcibook.com
http://www.hcibook.com/hcibook/ |
designed and hosted by
hiraeth mixed media
webmaster@hiraeth.com |
|