Human-Computer Interaction 3e Dix, Finlay, Abowd, Beale

exercises  -  8. implementation support

EXERCISE 8.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 8.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.

 

EXERCISE 8.2

Look ahead to the example of the state transition diagram for font characteristics presented in Chapter 16 (Section 16.3.3). Compare different interaction objects that could implement this kind of dialog. Use examples from existing toolkits (pull-down menus or dialog boxes) or create a novel interaction object.

answer

In 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 7 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.

 

EXERCISE 8.3

This exercise is based on the nuclear reactor scenario at: www.hcibook.com/e3/scenario/nuclear/

(a) In the Seeheim model: Treating the Application Interface model and Application together, there are three main layers:

(i) presentation/lexical
(ii) dialogue/syntactic
(iii) application/semantic

For each of these three layers list at least two different items of the description of the nuclear reactor control panel that is relevant to the level (that is at least six items in total, two for each level)

(b) There are no items in the description that relate to the switch (rapid feedback) part of the Seeheim model. Why do you think this is the case?

answer available for tutors only

(a) Lots of possible things in each category, for example:

(b) Switch is about rapid semantic feedback (under dialogue control), and is for things like line drawing, highlighting of icons based on detailed semantic differences. The buttons etc. on the control panel don’t really need this rate of feedback.

 

EXERCISE 8.4

A user has a word-processor and a drawing package open. The word-processor's window is uppermost. The user then clicks on the drawing window (see figure below). The drawing window then pops to the front.

Describe in detail the things that the window manager and applications perform during the processing of the mouse click in the above scenario. Explain any assumptions you make about the kind of window manager or application toolkits that are being used.

windows

answer available for tutors only

The details of this differ between different window systems; two typical examples are given here. The detail expected from students depends on what systems they have been using for practical work.

event-loop style window manager with 'retained bitmap' (keeps its own record of hidden window contents)

notifier style window manager with NO 'retained bitmap'

 

EXERCISE 8.5

A designer described the following interface for a save operation.
The users initially see a screen with a box where they can type the file name (see screen 1). The screen also has 'list' button that they can use to obtain a listing of all the files in the current directory (folder). This list appears in a different window. When the user clicks the 'save' button the system presents a dialogue box to ask the user to confirm the save (see screen 2).

dialog box
screen 1

dialog box
screen 2

Two programmers independently coded the interface using two different window managers. Programmer A used an event-loop style of program whereas programmer B used a notifier (callback) style.

(a) Sketch out the general structure of each program.
(b) Highlight any potential interface problems you expect from each programmer and how they could attempt to correct them.

answer available for tutors only

(a) code for Programmer A

MainLoop:
repeat forever
     read an event
     if it is a keypress
          insert it in the filename
     if it is a mouse click on the 'list' button
          show the current directory contents
     if it is a mouse click on the 'save' button
          display the dialog box
          repeat forever
               get the contents of the filename field and put it into a variable X
               read an event
               if it is a mouse press over the 'OK' button
                    save the file as X
                    goto MainLoop
               if it is a mouse press over the 'Cancel' button
                    goto MainLoop
          end repeat
end repeat 

code for Programmer B


Initialise:
     create main screen
     create hidden windows for directory contents and dialog box
     setup onKeypress callback
     setup onListClick callback
     setup onSaveClick callback
     setup onOKClick callback
     setup onCancelClick callback
     give control to window manager

onKeypress(key):
     insert key in the filename field on the main screen

onListClick:
     show the directory contents

onSaveClick :
     display the dialog box

onOKClick :
     get the contents of the filename field and put it into a variable save the file as X
     hide the dialog box

onCancelClick :
     hide the dialog box
 

(b)
Programmer A

The natural thing is to end up with a modal dialogue box. This is certainly the case in the sample solution where the inner loop inside the 'save' button case means that any attempted interaction with the file naming box is ignored.

Suppose that Alison has typed a name and hit "Save" - she then thinks "help, is this the same name as an existing file?". Pressing the list button, even though it is visible, will have no effect as this is only considered in the outer loop. One way to fix this would be for programmer A to think "what actions do I want to work when the confirmation box is visible" and then explicitly code these.

Programmer B

Here the natural thing is to end up with a non-modal dialogue box. In the sample solution this is the case. Even after the confirmation box is active a press on the "list" button or typing to edit in the file name field would still work.

Suppose Brian has just entered the file name "fred" and pressed the 'save' button. He sees the confirmation dialogue box, but, at this point, he wonders whether he might be overwriting an existing file so presses the 'list' button. He sees an existing file called "fred" and so changes the filename to "freda", but realises that the confirmation box is still there and wonders whether to press "OK" - will it be saved as "fred" or "freda"?

If the toolkit explicitly manages modal dialogue boxes, programmer B may simply be able to set some sort of parameter when the dialogue box is created. Note that, like programmer A's initial solution, this would forbid clicking the list box. A trade-off: clear dialogue or maximise the user's freedom to act?

Alternatively an explicit state variable could be added to record that the dialogue box is invisible. The event handlers for the main dialogue box would then test this and not allow certain actions:

    onKeypress(key):
if ( confirm box is visible ) make beep sound
otherwise insert key in the filename field on the main screen

 

EXERCISE 8.6 [extra - not in book]

(a) How do old character-based systems differ from graphical systems in terms of the low-level operations through which they can be programmed?

(b) In principle a programmer could build an interface using these low-level primitives. What do window managers and toolkits offer over and above this level of programming.

answer available for tutors only

(a) Some features are obvious:

character-based input: only characters, cursor and function keys
graphical input: the above + mouse clicks at particular coordinates, continuous mouse movement

character-based output: print string or put characters at specific locations; some also allow colours, flashing characters, special box characters, etc; characters are laid out in a fixed grid
graphical output: set any pixel colour, possibly primitives for line drawing, area filling, etc. Character printing may not be primitive, but where it is it allows proportionate (non-fixed-width) fonts.

(b) (see beginning of section 8.2 and 8.4 of Human-Computer Interaction)

Window managers and toolkits:

 

EXERCISE 8.7 [extra - not in book]

(continues the scenario from question 8.5)

The designer in question 8.5 is testing one of the programs. She types in the file name "fred", presses the 'save' button and gets the confirmation dialog box. At this point she wonders whether she might be overwriting an existing file so she presses the 'list' button. She sees an existing file called "fred" and so changes the filename to "freda", but then realises that the confirmation box is still there.

Based on this information alone:

(a) do you think the program is likely to be that of programmer A (event-loop style) or programmer B (notifier)?

(b) justify your reasoning

(c) suggest a way to correct the fault

answer available for tutors only

(a) Programmer B (notifier)

(b) Because the callbacks for the main screen are still active when the dialog box is showing.

(c) Various answers possible, especially as students may have used systems of different kinds. Alternatives:

 

EXERCISE 8.8 [extra - not in book]

(a) Explain the purpose of the three main boxes of the Seeheim model:

Presentation
Dialog control
Application interface model

(b)What is meant by 'semantic feedback'?

(c) Why is the switch often omitted?

(d) Which of the following would require rapid semantic feedback?

(i) displaying the results of a database query
(ii) showing a progress bar of a web page download
(iii) using a 'spray gun' in a paint package
(iv) moving a cursor in a text field
(v) moving an avatar in a 3D virtual reality world

answer available for tutors only

(a)
Presentation
- responsible for appearance
Dialog control - regulates communication between presentation and application
Application interface model - view of the application semantics (often now would be the application API or a view of it)

In addition there is an extra component, the bypass or switch, which is often omitted in descriptions of the Seeheim model.

(b) Where fast feedback is required, but where the information needed is not held in the dialog level abstractions

(c) Because there is not a clear distinction made between the logical/conceptual use of the Seeheim model and its use as an implementation model to structure actual code. The switch is unnecessary for the former, but essential for efficiency reasons in the latter.

(d)
(i) displaying the results of a database query
NO: this is semantic but not rapid!

(ii) showing a progress bar of a web page download
NO: application information is required, but it is not feedback to a user's ongoing actions.
(However, it would probably require the switch or something like it to achieve rapid update to the user's display)

(iii) using a 'spray gun' in a paint package
YES: needs to be really fast (otherwise you can't see where you are spraying), requires application knowledge (about the bitmap painting) and repsonds to user actions (moving the can).

(iv) moving a cursor in a text field
NO (but debatable): this is rapid, but a text-entry field would normally be regarded as part of the dialog level abstraction.

(v) moving an avatar in a 3D virtual reality world
DISCUSSION POINT: it is debatable whether the Seeheim model is useful at all in such a situation and if one thinks it is, it is not clear what are appropriate dialog level abstractions. One choice is to regard the movement in the world as dialog level and then require semantic feedback for collisions with objects. However, an alternative would be to have a much 'heavier' dialog component that knows about objects and avatars. Semantic feedback would then only be required if objects had complex behaviour (such as a door opening on a hinge), but not for solid walls, etc.

 

EXERCISE 8.9 [extra - not in book]

Consider screen 1 in question 8.5.

Imagine the system has been constructed using an MVC model. The model includes the filename being typed and the position of the text cursor in the filename.

The user is in the middle of typing a filename and has entered "Bens.jav". The cursor is currently at the end of the filename.
Consider the following user actions:

(a) user types 'a' which is added to the end of the filename
(b) the user clicks the mouse between the 'e' and the 'n' (in order to later add an 'a').

Describe what happens within the MVC components; think especially carefully about the communication between the components.
How does the system know the click was in the filename field and not over one of the buttons?

answer available for tutors only

The student has to think through the implications of the MVC model for this question. The textbook gives the interconnections, but doesn't do a scenario in this detail.

(a)
the user's keypress goes first to the controller (C)
the controller (C) then tells the model (M) to insert the character at the current cursor location and to move the cursor on accordingly
finally the model (M) tells the view (V) that the filename has changed, which displays the amended filename and cursor location

(b)
the user's mouse click goes first to the controller (C)
the controller (C) interacts with the view (V) to find out what is under the mouse location and discovers that it is the text field
the controller (C) then tells the model (M) to move the cursor
finally the model (M) tells the view (V) that the cursor location has changed, which displays the amended cursor location

The controller (C) knows that it is in the text field because it interacts with the view (V), which knows about the layout of objects on the screen


Individual exercises

ex.8.1 (ans), ex.8.2 (ans), ex.8.3 (tut), ex.8.4 (tut), ex.8.5 (tut), ex.8.6 (tut), ex.8.7 (tut), ex.8.8 (tut), ex.8.9 (tut)

Worked exercises in book

  

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 305]


home | about | chapters | resources | exercises | online | editions | interactive | community | search | plus +++
exercises: 1. human | 2. computer | 3. interaction | 4. paradigms | 5. design basics | 6. software process | 7. design rules | 8. implementation | 9. evaluation | 10. universal design | 11. user support | 12. cognitive models | 13. socio-organizational | 14. comm and collab | 15. task models | 16. dialogue | 17. system models | 18. rich interaction | 19. groupware | 20. ubicomp, VR, vis | 21. hypertext and WWW