Issue

Article

Vol.28 No.2, April 1996

Article

Issue

Temporal Aspects of Usability
Delays and Temporal Incoherence Due to Mediated Status-Status Mappings

The paper describes how the identification of `status-status mappings' early in the specification and design of an interactive system can highlight potential temporal problems in the interface. These problems arise because without infinitely fast computation and communication, any constraints between status in the interface are bound to be violated some of the time. This violation will at best be a slight lag between the source of a change and its display and at worst may lead to inconsistency between parts of the interface. We identify the ways in which status-status mappings are violated and the way in which they are mediated by events in the implementation of a system. This enables the designer to control the eventual behaviour of the system and avoid the worst pitfalls.

Status/Event Analysis and Event-event Mediation

The authors have previously established the importance of understanding and specifying both the event and status behaviour of user interfaces (Dix 1991; Dix 1992; Dix et al. 1993; Abowd and Dix 1994). The distinction is simply between those things in an interface, such as bells and keystrokes, which happen at a particular moment -- events; and those, such as the screen contents or the mouse position, which have a constantly available value -- status. The resulting formal and semi-formal techniques, called status/event analysis, have proved useful in analysing situations ranging from multi-user email usage to the behaviour of on-screen buttons (Dix and Brewster 1994).

The strength of the techniques rests on the fact that similar status/event behaviour can be observed in a wide range phenomena. In particular, when one agent wants to communicate an event to another, it often does so by changing a status. Only when the second agent notices the change in status does it experience an event for itself. Depending on the computational and interface mechanisms involved the delay between a status being changed (the status change event) and when it is noticed (the perceived event) may be considerable. So, the mediation of events between agents using status (event-event mediation) can lead to various temporal problems and needs to be considered carefully in designing the interface elements used to portray status and event phenomena.

Figure 1. Events mediated by status

An example of event-event mediation can be seen in many email systems (see fig 1). When mail arrives it is often appended to the recipient's mailbox (a change in status of the file system), the user's mail agent will at some stage notice this change (perceived event for mail agent), probably when it periodically examines the mailbox (polling). The mail agent then may use various means to alert the user, one common method being to add or change the appearance of an on-screen icon (change in status of the screen), but only when the user notices this (perceived event) does the user know that mail has arrived. Understanding this subtle process has lead to suggested improvements to email notification mechanisms (Dix 1992; Dix et al. 1993).

Status-Status Mappings

Status-status mappings are constraints or functional dependencies between different status within a system. Some examples are:

• The relationship between a document and the screen image of it within a word-processor.
• The way in which an icon being dragged across a screen follows the mouse movement.
• The fact that users of a shared editor must see views of the same shared document.

In a specification these appear as equations about state variables which must always hold. For example, the shared editor may have an equation:

for all users i: screen[i] = display(doc, loc[i])

The importance of status-status mappings is evidenced by the popularity of constraints in both single-user and groupware interface toolkits. These make it possible for the programmer to easily describe status-status mappings and then let the toolkit handle the propagation of information needed to maintain those constraints. However, as we shall see, it is not necessarily desirable to pass over this responsibility entirely to the toolkit designer.

Status-Status Mediation

In computer systems one cannot usually maintain status-status mappings perfectly and continuously. So, for example, on a slow machine there may be a noticeable lag between mouse movement and a window being dragged. Similar lags also occur in the physical world, for example, when you pull one end of a rope there is a slight delay before the far end moves due to the elasticity of the rope.

Whereas many physical status-status mappings are continuous, computer maintained status-status mappings are usually discrete. A typical process is as follows. A user event changes one status value. This breaks a status-status mapping. At some later stage, the system changes one of the other status in the mapping in order to restore the invariant. So, we see that status-status mappings are frequently mediated by events. If there is any gap between the event which breaks the mapping and the one which re-established it, then there will be a lag between the changes to the different status, which in turn can cause temporal problems. for the user

For a single user program running on a single, fast (enough) machine, it is possible to hide these lags completely -- even if there is some temporary breaking of the status-status mapping, the user need never be aware of it. However, if the machine is slower, if there is extensive computation involved, or if the different status are stored on different machines, then it may become impossible to hide the discrepancy.

The multi-user case is particularly interesting. If the users have a real-time audio-visual link then they can tell if, for example, they are seeing slightly different versions of document. To remove such effects entirely, one must upgrade the computers and networks. However, if the users cannot communicate except through their respective machines, then it may be possible to hide the fact that the lag exists (assuming that the users don't keep time-stamped logs of every screen they see!). These two solutions are in fact general solutions: technology oriented -- make everything faster, or design oriented -- make the delays not matter.

A Taxonomy of Status-Status Mediation

Temporal problems are caused by the lag between the event which breaks a status-status mapping and the event which re-establishes it. To make this concrete, we consider a functional status-status mapping is of the form:

y = f(x)

(i)

the agent which changed `x'. This is what happens in most single user applications. When the user issues a command, the program changes both the document and the screen image of it.

(ii)

an agent responsible for `x'. That is `x' is an active value and when it is changed it explicitly updates its dependents. This is very much the object oriented approach where the object `x' is responsible for performing any actions involving it.

(iii)

an agent responsible for `y'. In this case, we imagine that `y' is active itself and tries to keep itself up to date. This occurs in many email interfaces. The mail program changes some aspect of its user interface, when it notices that the mailbox file has a message appended to it.

(iv)

an agent responsible for the mapping. That is an agent which monitors the constraint. This is at least the logical view presented by most constraint-based user interface toolkits such as Garnet (Myers et al. 1990) or Rendezvous (Hill 1993).

Both (i) and (ii) happen at essentially the same time, they are triggered by:

(a)

the event which changed `x'. Notice that (iii) and (iv) fudge the issue. How do the respective agents know when to update `y'. They must themselves be triggered by some event. This might be caused by (a), or some other event not directly related to the original status change:

(b)

a timed event. For example, when a mail agent periodically looks at the file-system to see if the mailbox has anything new in it.

(c)

an event triggered by the use of `y'. A form of lazy or demand driven re-establishment of the mapping. The simplest case is when `y' is never stored at all, but simply recalculated when needed. Alternatively, `y' may be stored, but when actually required a check may be made to see if it needs recalculating. For example, a fonts menu may be calculated by examining the `Fonts' folder only when the user pulls the menu down, rather than when new items are added to the folder.

(d)

some other (hopefully relevant) event. For example, on the Macintosh the file sizes shown in a folder's window are only updated when the window is opened. Possibly this is a case of the designers confusing this event with (c) which occurs when the user looks at an already open window.

In each of these cases, there are additional possibilities for delay. In cases (i), (ii) and (iv) the relevant agent wants to change `y', but this may itself be mediated (especially if remote from where `y' is stored). Also in cases (iii) and (iv), the respective agents have to find out the value of `x'. This may require communication and potential further lags.

Weakening Status-Status Mappings

Because lags inevitably occur, part of the refinement of a system description must involve weakening status-status mappings. Note that this is not refinement in the sense usually employed in the formal methods community as it is non-conservative. That is a property which holds when one assumes that the status-status mapping is always true, may cease to hold when the mapping is weakened.

To understand the way status-status mappings are weakened, we make the temporal nature of the mapping explicit. The original specification is effectively:

for all t: y(t) = f(x(t))

That is, at all times `y' is equal to f(x) for the current value of `x'. Of course, this is precisely the sort of constraint that it is impossible to maintain in reality. However, if we can bound the delay between the modification of `x' and the update of `y', then we may be able to satisfy a weaker constraint such as:

for all t: there exists t' s.t. y(t) = f(x(t')) and t < t'+ d

Unfortunately, even if sensible properties hold of simple status-status mappings it may not be true for more complex ones. Cascaded mappings are no trouble. If y=f(x) and z=g(y) and the respective mappings are subject to delays of d and d' respectively, then the mapping as whole is simply subject to a delay of d+d'. However, imagine we have the following status-mappings:

(i) y = 2 x
(ii) w = 3 x
(iii) z = w - y

Assume that x is always positive. Then, if the mappings were always true then z would also always be positive. However, if (i) is subject to a delay of 1 second and (ii) to 2 seconds, then there may be a time when w and y correspond to different values of x. In this case z may temporarily be negative. That is there is no value of x for which z is a consistent value.

The observant real-time programmer may notice this problem if `z' is calculated by the machine. However, what happens if `y' and `w' correspond to displays for the user who is basing decisions on the combined data?

Summary

In previous work we have shown how the use of status to mediate event transfer leads to delays in interactive and cooperative systems. In this paper we have looked at status-status mappings which occur frequently in formal and informal system descriptions. However, it is normally the case that such constraints cannot be maintained continually and are in practice weakened as the system is `refined' into a working systems. This weakening occurs because the change of status is mediated by different kinds of agent and event. The effect of this is that lags or even inconsistency can occur between parts of an interface. Although this is a problem it is also an opportunity. Status-status mappings can be identified in early system descriptions and thus indicate where potential temporal problems can occur. We may not at present be able to offer simple packaged solutions, but are at least able to locate and track potential trouble spots.

References

G. Abowd and A. Dix (1994).

Integrating status and event phenomena in formal specifications of interactive systems. SIGSOFT'94, New Orleans, ACM Press.

A. Dix and S. A. Brewster (1994).

Causing Trouble with Buttons. Ancillary Proceedings of HCI'94, Glasgow,

A. Dix, J. Finlay, G. Abowd and R. Beale (1993).

Human-Computer Interaction. Prentice Hall.

A. J. Dix (1991).

Formal Methods for Interactive Systems. Academic Press.

A. J. Dix (1992).

Beyond the interface. Engineering for Human-Computer Interaction: Proceedings of IFIP TC2/WG2.7 Working Conference, Ellivuori, Finland, North-Holland.

R. D. Hill (1993).

The Rendezvous constraint management system. UIST'93: Proceedings of the ACM Symposium on User Interface Software and Technology, ACM.

B. A. Myers, D. A. Guise, R. B. Dannenberg, B. Vander Zanden, D. S. Kosbie, E. Pervin, A. Mickish and P. Marchal (1990).

Garnet: comprehensive support for graphical, highly interactive user interfaces. IEEE Computer, 28(11): 71-85.

Authors' Addresses

Gregory Abowd
GVU, College of Computing
Georgia Institute of Technology
Atlanta, GA 30332-0280 USA.
Gregory.Abowd@cc.gatech.edu

Issue

Article

Vol.28 No.2, April 1996

Article

Issue