Chapter 10

Implementation Support

10.1 In contrasting the read-evaluation loop and the notification-based paradigm for interactive programs, construction of a pre-emptive dialog was discussed. How would a programmer describe a pre-emptive dialog by purely graphical means? (Hint: Refer to the discussion in Section 10.5 concerning the shift from external and independent dialog management to presentation control of the dialog)

answer

Creating a pre-emptive dialog by graphical means is quite simple. In a graphics-based interaction, it is assumed that the user can only interact with parts of the system that are visible. In a windowing system, for example, the user can only direct input to a single, currently selected window, and the only means of changing the selected window would be by indicating with some gesture within that window. To create a pre-emptive dialog, the system can produce a window that covers the entire screen and make it the currently selected window. All user input would then be directed to that window and the user would have no means of selecting another window. The 'covering' window thus pre-empts any other user action except that which it is defined to support.

10.2 Recall the state transition diagram for font characteristics presented in Chapter 8 (Section 8.3.3). Compare different interaction objects which could implement this kind of dialog. Use examples from existing toolkits (pull-down menus or dialog boxes) or create a novel interaction object.

answer

To recall the example, we want to allow the user to toggle between three font characteristics - bold, italics and underline. Pull-down menus and dialog boxes are the most frequently used methods for implementing such a dialog. A pull-down menu would have the three choices listed with some way of indicating whether the characteristic was active or not. Upon each invocation of the menu, the user could change the active status of one font characteristic. For example, they could turn on the bold feature or turn off the underline feature. The important feature of this dialog is that more complex tasks (changing the active status of two or more font characteristics) can only be achieved by separate invocations of the menu. And often the only way the user can check the status would be by popping up the menu again (without invoking any action). This last point shows that the menu design alone does not support immediate display of relevant state changes as discussed in Chapter 4 under the synthesizability principle.

Within a dialog box, the user can effect several changes at one invocation. Technically, it is not the dialog box interaction device that allows for this, but the use of toggle buttons. Each font characteristic is represented by a box that acts as a simple on/off switch for that characteristic. As an aid to the user, the toggle button can change its appearance so that the user can know its status (on or off) by looking at it. A similar interaction widget is the checkbox, which would be labelled with the particular font characteristic. Clicking on the checkbox would put a mark in the box to indicate that the characteristic is on. Another click would remove the mark. In fact, a dialog box need not be used to portray the set of toggle buttons or checkboxes, as they could be presented continually so that the user can always view the current font characteristic settings. The reason a dialog box might be used is that there may be many font characteristics to choose from and the dialog box will keep them grouped together and preserve screen space by allowing them to be hidden and used on an as-needed basis.

Worked exercises

• Scrolling is an effective means of browsing through a document in a window that is too small to show the whole document. Compare the different interactive behaviour of the following two interaction objects to implement scrolling:
  • A scrollbar is attached to the side of the window with arrows at the top and bottom. When the mouse is positioned over the arrow at the top of the screen (which points up), the window frame is moved upwards to reveal a part of the document above/before what is currently viewed. When the bottom arrow is selected, the frame moves down to reveal the document below/after the current view.

  • The document is contained in a textual interaction object. Pressing the mouse button in the text object allows you to drag the document within the window boundaries. You drag up to browse down in the document and you drag down to browse up.

  The difference between the two situations can be characterized by noticing that, in the first case, the user is actually manipulating the window (moving it up or down to reveal the contents of the document), whereas in the second case the user is manipulating the document (pushing it up or down to reveal its contents through the windows. What usability principles would you use to justify one method over the other (also consider the case when you want to scroll from side to side as well as up and down)? What implementation considerations are important? [page 393]

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