8. implementation support


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


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.



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.


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.



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:

  • Presentation/lexical - colours of buttons, labels on buttons, words in audio warnings, layout of control panel, ...
  • Dialogue/syntactic - need to confirm alarm-red state and emergency shutdown, STNs, enabling of manual override in red state, ...
  • Application/semantic - change of actual target values, contacting of emergency services, control of exploding bolts, ...

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



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.


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)

  • the mouse click goes first to a low-level part of the window manager
  • the window manager works out which window is under the mouse and sees that it is not the current top-window
  • it creates a 'you are hidden' event and adds it to the word-processor's event queue
  • it creates a 'you are on top' (expose) event and adds it to the drawing package's event queue
  • it creates an appropriate 'mouse clicked' data structure for the application adding the mouse coordinates, shift key info, time, etc.
  • it records the overlapping bit of the window-manager's window in an 'off-screen buffer'
  • it draws the hidden bit of the drawing package window
  • it makes a note to pass future drawing from the word-processor to the off-screen buffer
  • when the drawing package next reads its events it gets the expose event and the mouse-click event in that order
  • it makes a note that future keystrokes go to the drawing package
    (assuming a click-to-type interface)

notifier style window manager with NO 'retained bitmap'

  • the mouse click goes first to a low-level part of the window manager
  • the window manager works out which window is under the mouse and sees that it is not the current top-window
  • it records the fact that future drawing from the word-processor to the overlapping area of the screen should be prevented and that the drawing package (which was previously prevented) be allowed to draw to it.
  • it creates a 'you are hidden' event and invokes the appropriate word-processor callback for this event
  • it calls the drawing package redraw routine telling it which part of the screen to redraw
  • it creates a 'you are on top' (expose) event and invokes the appropriate drawing package callback for this event
  • it creates a 'mouse clicked' data structure for the application including the mouse coordinates, shift key info, time, etc. and passes this to the appropriate drawing package callback for this event
  • it passes this event to the appropriate drawing package callback
  • it makes a note that future keystrokes go to the drawing package
    (assuming a click-to-type interface)



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

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

     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

     insert key in the filename field on the main screen

     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

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:

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.

  • N.B. windowing operations such as 'show/hide window', 'redraw', etc. are not correct answers to this part, which is about the low-level primitives.
  • In addition, the programming style differs in that older character-based applications are more likely to offer a fixed dialog - input-print-input-print etc - whereas graphical ones tend to be more user driven. However, this is as much an issue of the toolkits and window managers used. Some character-based systems are very user driven and it is possible to have question-answer style windowed dialogs (as in many install programs).

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

Window managers and toolkits:

  • manage the sharing of the screen by multiple applications
  • often include more sophisticated graphics and text operations
  • isolate the application from the device-specific primitives of different hardware
  • supply common widgets such as buttons, textfields, scrollbars, etc.
  • help to obtain a consistent look and feel across different applications


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:

  • add a flag variable to the program that is set when in the dialog box. If the user trys to interact with the main screen the callbacks check the flag and refuse to process the event (perhaps beep)
  • as above, but when the user interacts with the main screen the dialog box is automatically hidden. But beware - potential usability problem - does this mean cancel or confirm? Given it is often hard to immediately see the effects of file-system operations this is especially dangerous.
  • the program temporarily cancels the main window callbacks while the dialog box is showing
  • the program asks the notifier to filter out and ignore events regarding the main window.
  • (cop out) some window managers offer a modal dialog box as a primitive!


EXERCISE 8.8 [extra - not in book]

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

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

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

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

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

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]