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

exercises  -  8. implementation support

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

Other exercises in this chapter

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)

all exercises for this chapter


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