Time Affordances

The Time Factor in Diagnostic Usability Heuristics

Alex Paul Conn

Digital Equipment Corporation
110 Spit Brook Road
Nashua, New Hampshire 03062-2698
(603) 881-0459
alex.conn@zko.mts.dec.com

© ACM

Abstract

A significant body of usability work has addressed the issue of response time in interactive systems. The sharp increase in desktop and networked systems changes the user's focus to a more active diagnostic viewpoint. Today's more experienced networked user is now engaged in complicated activities for which the issue is whether the system is carrying out the appropriate task and how well it is proceeding with tasks that may vary in response time from instantaneous to tens of minutes. We introduce the concept of a time affordance and a set of principles for determining whether the diagnostic information available to the user is rich enough to prevent unproductive and even destructive actions due to an unclear understanding of progress.

Keywords

Usability engineering, heuristics, time delay, affordances, taxonomy, principles, design rationale, practical guidelines.

1. Introduction

One of the fundamental problems with systems (computer-based and otherwise), is that users do not always understand what is happening. Even relatively experienced users may be stymied by integrated systems in which the progress of a given task is difficult to assess. When delays are not understood, they can cause dysfunctional behavior even in organizations that are not necessarily computer based, as illustrated by Senge's beer game [11].

For the typical desktop computer system, such as a stand-alone PC, the consequences of not understanding the reason for a given delay may be minimal. However, with the rapid growth in network use and highly integrated systems, the delays can be important indicators of the status of an enterprise information system. With critical applications, such as the control and coordination needed in the transportation and power industries, a wrong conclusion about a delay based on insufficient information can have serious consequences. For example, an improper termination of a computer application could cause a medical operation to be suspended. A computer delay could cause a commuter rail slowdown because the lack of updates could mean that conditions were unsafe. In manufacturing, inappropriate interruptions could result in loss of materials that cool or harden and cannot be manipulated after a delay.

A large body of research exists on various aspects of computer response time [4 , 5 , 10 ], providing a good foundation for understanding how rapidly a user's desktop system should respond to requests, or for determining whether a local server can realistically support a potential set of client applications on users' desktops. However, with the world wide web browsers, gophers, combined with increasingly modem-based access, response time is no longer the only focus. The user knows a search may take a while. The question facing practical designers is "what constitutes a full set of delay information that users must have in order to understand and respond appropriately to these delays?" In other words, how do designers know, in practice, when their design contains the necessary components of time delay information, so that they can then concentrate on format, style, etc.?

This paper pulls together various existing components of good practice and synthesizes a taxonomy of eight properties in task execution that, if observable, indicate usability along the time dimension. These eight properties together characterize a time affordance, an extension of the concept discussed by Don Norman and others [9] [3]. We believe the term affordance appropriately captures the gestalt impact of the time-delay components, from which users understand what to expect and how to proceed.

Our focus is on the information, rather than the presentation format. The precise format of the information should be determined using guidelines such as those described in [7, 8, 12, and 5] and tools and laboratories for developing and evaluating alternatives.

We first introduce four scenarios involving problems with time delays, three of which are roughly based on actual events. We then introduce a taxonomy of time affordance concepts. Next we analyze the scenarios based on the taxonomy, and finally we present a set of principles on which to base a time-affordance interface.

2. Scenarios

2.1 Scenario 1: PC with Network Access to an Office Management Information System (MIS).

An office worker uses a well-known GUI-style program to access a database stored on another system in the office. The user attempts to update a field. The action is apparently acceptable because there are no error messages. The only message is the status bar message stating what was going to happen if the user pressed OK. The hour glass appears and stays there for five minutes. Although the mouse will move the hourglass, the PC is otherwise unresponsive (e.g., Alt-Tab will not move between applications).

The user presses Ctrl-Alt-Delete. After several seconds, the computer returns with a message saying "Although you can use Ctrl+Alt+Delete to quit an application that has stopped responding to the system, there is no application in this state..." The user should press any key to return to the application or hit Ctrl-Alt-Delete again to reboot system. The user presses a key and Windows returns but still appears to be frozen, and the screen is not properly repainted. In frustration, the user hits Ctrl-Alt-Delete twice to reboot.

The status of the update is unclear. Later attempts to do the same update result in the same problems, until the user finds out from a colleague that these kinds of updates always take about 10 minutes. The problem has resulted in a loss of productivity for the better part of a morning.

2.2 Scenario 2: Client Installations

An experienced PC user is trying to install an important update to a package that will allow an existing tool to incorporate a library designed with a new object-oriented approach. Installation is familiar; the graphical progress indicator (which we will call a "thermometer") appears and proceeds slowly but evenly until it reaches 18%. At this point, a message flashes saying "installation complete" but is almost immediately obscured by a message saying "unable to process XYZ because driver not found."

The user repeats the installation several times (in part to try to read the flashing messages but mostly because it said it only had completed 18% of the job). The user then calls a number for help and only after an hour of comparison (file-by-file) do they determine that the installation was indeed complete. In addition, the error message was apparently not important, since the software worked.

2.3 Scenario 3: Networked Manufacturing Floor

A manufacturing floor has recently been integrated by tying together a number of legacy programs over a local area network. The integration required special code to wrap the existing applications and to serve as workflow drivers. Acceptance tests were easily passed, and the system has been working well for over a year. The number and complexity of jobs has been steadily increasing, but monitors have shown that network traffic is still well below saturation.

One day, without warning, a certain piece of computer driven fabrication equipment starts losing communication with data servers. The problem takes days to diagnose, since the network activity (as seen both from the server and the fabrication machine) appears to be normal.

It turns out that to reduce network traffic, a program on the server was designed to compute complex functions output from the legacy application and to send shorthand specifications to the fabrication machine as the results of the computation became available. Recent specifications required so much computation that there was a significant delay between transmission of certain parts of the specification data. The fabrication machine program interpreted the delay as a problem with the server, and went into reset mode, no longer capable of processing the data even when it was ready. On site programmers temporarily fixed the problem by increasing the programmed fabrication machine reset delay value.

However, the delay was originally instituted because the legacy programs occasionally crashed. By timing out, the fabrication machine could become available for fabrication instructions from another server, thus reducing shop floor down time. The dilemma was how to institute a "smart" time-out that distinguished between long computations and malfunctioning legacy programs.

2.4 Scenario 4: A World-Wide Web Browser.

A user employs a world-wide web browser to determine the availability of certain products and request further information from manufacturers. The user has spent considerable time "surfing the web" and can find the necessary information relatively rapidly. The browser is well-designed, presenting many of the reasons for time delay and status information as it happens. There is even an easy way to stop a request if the network traffic is too heavy to allow an acceptable response time.

The hypertext format provides a separate window indicating the network address of a potential request (actually the universal resource locator, or URL, is shown, which contains the network address). However, once a request is made, the URL disappears until the request is completed. Even experienced users often stop perfectly good requests, unable to remember what hypertext items they selected, or afraid that they had accidentally moved the pointer when pushing a mouse button.

Once the user arrives at the menu for ordering information, there is an additional problem. It is easy to read about the desired products and gather together a set of requests, fill out fields to enter a name, address, etc. However, when the user pushes the submit button, there is no way to tell whether anything happened. The user pushes the button multiple times, actually causing multiple requests to be mailed to the manufacturers. Later that day, duplicate automated responses arrive at the user's mailbox.

3. A Taxonomy Of Time Affordance Concepts.

3.1 Time Affordances

A time affordance is a presentation of the properties of a delay in a task or anticipated event that may be used by an actor (e.g. user) to determine the need for an interrupting or facilitating action. These properties are often visual but may also have other (e.g., audible) components. As discussed by Graver [3] , affordances exist whether the perceiver cares about them or not. "Making affordances perceptible is one approach to designing easily-used systems."

A good example of a time affordance is the "thermometer" on many PC operations, telling visually and with a percent indication how the task is proceeding and how much more needs to be done. Other approaches have been described in [6] , [2]. With a good time affordance, a user knows when things are okay and when there are problems, and can generally predict when a task will be completed. A complete time affordance may combine information from more than one area or level of the system in order to provide a visual or other indication of the following eight task properties:

1. Acceptance: What the task is and whether it has been accepted with the input parameters or settings.
2. Scope: The overall size of the task and the corresponding time the task is expected to take barring difficulties. (Once acceptance and scope are indicated, the task may pause for the user to decide whether to initiate.)
3. Initiation: How to initiate the task and, once initiated, clear indication that the task has successfully started.
4. Progress: After initiation, clear indication of the overall task being carried out, what additional steps (or substeps) have been completed within the scope of the overall task, and the rate at which the overall task is approaching completion.
5. Heartbeat: Quick visual indication that the task is still "alive" (other indications may be changing too slowly for a short visual check).
6. Exception: A task that is alive has encountered errors or circumstances that may require outside (i.e., user) intervention.
7. Remainder: Indication of how much of the task remains and/or how much time is left before completion.
8. Completion: Clear indication of termination of the task and the status at termination. How to terminate the task before completion (whether or not errors have occurred).

Thus, a familiar office elevator may accomplish this goal by (1) illuminating the button that the user pushes to indicate acceptance of the request to go up or down, (2) providing a display showing where the elevator(s) currently are and showing movement of elevator(s), and (3) turning off the local up or down button illumination and/or ringing a bell when a given elevator is close and about to stop at the requester's floor.

On a PC, modem file transfer implementations frequently provide such information. Figure 1 shows the information provided by a ZMODEM implementation. In addition to the dialog box shown, when the task is complete, the application frequently provides a separate dialog box and/or beep to signal that the transfer is complete.

FIGURE 1. Analysis of a familiar dialog box for ZMODEM.

3.2 Delays

Delays are simply the time period between a request and the completion of the request. E.g., I want an elevator to stop at my floor (going in the direction I want to go); the delay is the time before the elevator actually arrives.

Static delays are periods during which nothing appears to happen even though a task may be proceeding normally. User or machine action during a static delay (and after how long) depends on the time tolerance window, described below. The change of the mouse pointer from an arrow to an hourglass or clock (with no other time affordance) is a classic example of a static delay. If the pointer is animated (e.g., the clock hands move, or the world in the Mosaic interface turns), the result may be a dynamic delay if the animation is a true monitor (heartbeat) for the task in question and is recognized as such by the user.

A dynamic delay indicates that although there is a wait, the task has the appearance of proceeding normally and there is no reason for concern. In the early days of computing, console lights indicated something was happening (dynamic delay) and if the lights froze and nothing happened, we knew something was wrong. The flashing "working" message was in general not a dynamic delay because (as described in Section 5.2) most users quickly learned that "working" did not actually monitor progress and did not in reality provide a true "heartbeat" indicator. Note that a dynamic delay may have static components, which can become significant if they result in a delayed heartbeat indication.

3.3 The Time Tolerance Window

The time tolerance window (or tolerance window for short) is the length of time an actor (user or system) allows before deciding that a task is not making progress or that something must have gone wrong. The time tolerance window is both individual and context sensitive, affected by:

• Sensitivity or urgency. A particularly sensitive mission with a chance that things could go seriously wrong may shrink the tolerance window considerably.
• Estimations.With properly set expectations, the tolerance window can be increased. (For example, ZMODEM warns that the transfer will take half an hour.)
• Individual differences. Different actors (humans or machines) have different initial tolerance windows, indicating a need for tailoring (a machine actor may have a different time-out setting stored; users have different levels of patience).
• Familiarity. Once a user knows the level of dynamic or static delay in a given interface, he or she will have expectations of what kinds of feedback indicate problems. A machine actor may be programmed using similar experiences.

A time tolerance window will be static if the delay is entirely static (there is no additional information, so the level of tolerance remains unchanged). However, if the delay is dynamic or contains dynamic components, the tolerance window can shrink or grow based on the information available during the dynamic delay. There are actually two kinds of tolerance windows, each of which can be affected by the nature of the dynamic delay:

1. Progress tolerance window. Each time the dynamic delay provides new progress information, the actor resets the starting point from which the tolerance window is measured. If the dynamic delay contains static components, the heartbeat must be received within the progress tolerance window in order for the reset to occur (see Figure 2 ).

FIGURE 2. Relationship of progress and scope tolerance window to dynamic delays having heartbeats. The progress tolerance window is elastic and could have been extended with other indications of progress.

2. Scope tolerance window: Even if the actor is receiving dynamic information and resetting the progress tolerance window, the overall (dynamic) delay may eventually grow to a point that it exceeds the actor's expectations of the scope of the task (e.g., due to heavy traffic, errors and retransmissions, etc.). Thus even with a dynamic delay, if the rate of progress is not high enough and/or the remainder shows that the task will exceed the expected overall scope, the actor will terminate the task.

3.4 The Task Hierarchy

We believe that any task can be viewed as a hierarchy of task steps, each with a corresponding delay. At the highest level is the complete task, which (during the delay after initiation and before completion) is presumably some given percent completed. Below the top level, a task can usually be decomposed into task steps or sub tasks, and these can be further decomposed. Each lower level of decomposition will reveal a set of smaller, and therefore more rapidly completed steps. In theory, by recursing sufficiently deep into the hierarchy, it should be possible to observe task steps that complete well within any progress tolerance window.

A tracking program, which we will call a hierarchical reporting engine, could be designed to navigate the task hierarchy. The reporting engine would descend into the task-step hierarchy searching for a granularity of task steps in which change occurs within the progress tolerance window. That is, the reporting engine would move up and down the hierarchy in order to present information for a dynamic delay. If the current level did not provide results within the tolerance window, the engine would descend to a lower hierarchical level for more rapidly changing status information. The engine would need to descend only to a deep enough level where progress could be observed within the tolerance window. The output of a hierarchical reporting engine would thus provide the necessary information so that the updates would occur within the progress tolerance window (see Figure 2).

Computers are now fast enough that whole tasks and/or modules may be completed within an actor's progress tolerance window. Thus in many cases, it is possible to provide dynamic delay information simply by tracking the completion of modules (e.g., a compressed file is unpacked and copied). If even that information is delayed, the monitoring "engine" often can predict length of task and percent completion at the lower level (e.g., size of file to unpack). Thus a fully-featured engine may not be needed if a dynamic delay can be accomplished by carefully choosing to monitor at a hierarchical level in which feedback occurs within the progress tolerance window.

4. Analysis of Scenarios

In this section, we use the above concepts to characterize and explain the problems encountered in the scenarios.

4.1 Scenario 1

In the update to MIS database scenario, two problems occurred: (1) the user relied on time expectations derived from other experiences, therefore the time tolerance window did not coincide with the actual time needed for the task to complete, and (2) the task required a static window because there was no feedback other than the hour glass to indicate that the computer accepted the input and was proceeding normally.

Two approaches would have reduced the likelihood that a user would give up in this scenario. First, the application might have extended the static window by clearly acknowledging the request [accept], indicating that processing has started [initiate] and setting the expectation for a longer (e.g., ten-minute) period [scope].

Second, the application could have created a dynamic window by providing some kind of feedback indicating progress. Such feedback would answer questions such as: Is something happening [heartbeat], is the right task being accomplished [progress], are there errors requiring intervention [exception]? If it is impossible to predict the percent of the task left to complete [remainder], an alternative approach, such as listing the processing steps and indicating where the system has progressed within the list, might be preferable (as shown in Figure 3 ).

FIGURE 3. Possible dialog box for processing files where the size of each file is not known prior to the start of processing.

4.2 Scenario 2

The installation scenario involved both a dynamic window and a problem with the believability of the information presented (discussed in section 5.2). Because the application had a dynamic window, including named files that were copied, the user took no steps to stop the processing. (The application installation was progressing as expected.)

The major issue involved the expectations set by previous installations that the "thermometer" would accurately predict how much had been accomplished and how close to completion the installation was. The user's scope tolerance window, adjusted by the updates to the "thermometer," established a minimal time needed for completion. Because the installation took much less time, the user was already concerned that something had gone wrong and erroneously indicated completion. Worse, the error message (essentially unrelated to the bulk of the installation), was sufficient to add enough questions to the process to reject the claim that the installation had completed.

The system used a display object that many users interpret as a linear time indicator to instead indicate a percentage of tasks completed (potentially very non-linear). Had the "thermometer" been replaced by a list of programs that, for example, were grayed out when they were unpacked, the user might have believed the completion indications, especially if he or she could later check that the names at the end of the list were indeed in the directory. See Figure 3.

The role of error messages in reducing confidence is especially important. An error message says something went wrong (perhaps not fully understandable even to experienced users). Just as task-length predictions can increase the tolerance window (because the user knows to wait longer before suspecting problems), error messages have the potential of reducing confidence and thus shortening the tolerance window. The likelihood that the error message would prejudice the overall task depends on how clear the indications were during the major task that progress was normal (i.e., how well the eight task affordance properties were presented during the task).

4.3 Scenario 3

In the manufacturing floor fabrication equipment scenario , the fabrication equipment time window was fixed based on programmer expectations when loads were significantly lighter. The design was for a static window, even though a dynamic window capability was possible. For example, the time window was reset each time a buffer or block of primitives was received, not at the beginning of processing of legacy application data.

The driver program that interfaced with the legacy application and built primitives from the data "knew" when it was building a primitive. It could either have (1) determined whether a primitive would take a while and sent an estimate to the fabrication machine [scope], or (2) set appropriate timers to trigger the sending of "status OK" messages to the fabrication machine [heartbeats] if the computation for a particular primitive was extensive. The same timer could have been used to check on the legacy application (to see if it might have crashed). Figure 4 gives an example of a dialog box showing primitive-by-primitive progress as well as overall task status. Similar information could have been sent in the "status OK" messages to the fabrication machine.

FIGURE 4. Possible dialog box for hierarchical reporting (displays progress for graphics primitives). This box shows both the overall task remainder (highest abstraction level) and a lower level of abstraction in which something happens within the tolerance window (in this case, the current primitive processing status changes).

4.4 Scenario 4

The world-wide web scenario illustrates how an otherwise very well designed application can "miss" important components of a time affordance. Once the hypertext item was selected, initiating a transfer, the progress component never clearly indicated the goal of the status information. Ideally, the hypertext being executed should visibly change in appearance (e.g., change color) to indicate that the current delay is being caused by selection of that hypertext. In addition, the corresponding universal resource locator (displayed before the hypertext was selected) should remain visible during the time delay.

The problem with the submit button was primarily the lack of an indication of completion, a component of a time affordance, but also important state information even when there are no time delays.

5. Basic Principles and Considerations

Principle: Every user is engaged in some degree of diagnosis during the operation of an overall task. He or she is prepared to stop the task if something appears to be wrong. The nature of the delay, the context, and the individual's thresholds affect whether their response will be appropriate (i.e., in accordance with the actual state of events).

• Static delays provide no information and are the source of potentially destructive actions by an actor (user or second computer interacting with the system in question).
• Dynamic delays are always preferable to static delays. The quality of the dynamic delay is determined by the information available during the delay (i.e., the time affordances).
• Dynamic delays are generally achievable by engines that can walk the task-step hierarchy seeking status information that is changing at a rate fast enough to hit the progress tolerance window.
• Dynamic delays are also achievable by expanding the time windows using predictive algorithms that set expectations for a longer wait (thus enlarging the progress tolerance window).
• System actors are often programmed with some form of progress tolerance window (e.g., a time-out). By enriching protocols to include the status information in a time affordance, we can reduce or eliminate unnecessary time-outs.

Principle: It is important for the system to provide a good time affordance, ensuring that any delays are dynamic delays wherein progress is observable. A good time affordance will provide all eight properties of a task (acceptance, scope, initiation, progress, heartbeat, remainder, exception, and completion).

5.1 Notions of What is Happening

This paper has focused on the important ingredients in a time affordance. As stated earlier, the guidelines and tradeoffs in the actual format of the information should be explored by work such as [6 and 2], principles [5] , and heuristic design principles [8]. Whatever the format, we believe the following to be true:

Principle: An indication that "something is happening" is an important ingredient of a time affordance. Interfaces need to be designed with the necessary "hooks" to provide such feedback within the tolerance window.

The vagueness of the phrase "something is happening" is deliberate. The perception of change that is interpreted as a heartbeat need not be clearly understandable information. From flashing patterns of console lights, we were able to easily recognize the cross-reference stage of an assembler, signaling the nearing completion of a job. Rather than information overload, the lights provided us with interesting patterns from which we could begin to perceive stages of progress. In the same way, Mosaic's byte transfer messages are useful as a heartbeat even though most users do not seriously compute anything from them. We suspect that a starfield view as described in [1] could be designed to provide heartbeat and progress indications similar to console lights.

Because tolerance windows vary between users, time affordance displays may need some kind of "throttle" or tailoring capability, so that the frequency of indication showing that "something is happening" is not distracting.

5.2 The Confidence Factor: Telling the Truth

System designers have for years recognized the response time issue in computer systems as described in [5 and 4]. In an attempt to deal with tasks that do not complete right away, designers have used a number of approaches for dealing with the user. A given user will, based on past predictions and how they were actually realized, adjust their tolerance window. Let us examine the impact of some approaches designers have used to deal with time delays.

Distract: According to John Kemeny, in the original Dartmouth College time-sharing system, the line that printed the name of the program and the starting time was designed not only as an acceptance and initiation indication but also as a delay. The average student's program would compile and run within the time a Model ASR33 Teletype took to print that line. The system therefore seemed to have almost instant response. Thus, at least initially, the system did not require any kind of progress or heartbeat indication for most users. Billboard-style advertising of new features during product installations arguably provides a similar and useful form of distraction.

Mislead: Later time-sharing systems using video display terminals began to incorporate a flashing "working" message. Unfortunately, users soon recognized the message as placating rather than truly indicating heartbeat. The user not only learns to ignore the "working" indication, but worse, may learn to suspect any progress or heartbeat indication from the computer, even if valid.

We found similar behavior in a popular streaming tape backup program. Heartbeat was supposed to be shown by a progression of dots across the screen. Yet, on more than one occasion, the dots marched across the screen even when the tape backup was not proceeding at all. (Audible heartbeat indications, described below, that were normally present, such as disk rattles and whining tape, were not present). The dots were thus nothing more than an indication that the computer had not yet crashed!

Surprise: Some implementations provide information that surprises the user. The most common are: (a) progress or remainder indicators that are highly non-linear and therefore do not correspond with true delays. In Scenario 2, the first 18% of the task took much longer than the remaining 82%, causing the user to expend significant time ensuring that the task in fact completed. On the PC, many progress indicators will zoom to 100% only to pause for tens of seconds before any addition heartbeat. Some network copies of small files will show 50% done when the networked computers did not in fact successfully negotiate the protocols and the copy was never completed.

Principle: A system should provide a true estimate of time delay, so that numerical and implied (i.e., spatial) percentages correspond to linear progression over time rather than some other task-related information. If the information is not believed, any time affordance can do very little to extend the tolerance window because the enhanced explanation and forecasting of delays will be suspect.

5.3 Alternatives to Visual Feedback

A lot of attention has been paid to visual indications of response time and progress indicators. In desktop and laptop computers, hard and floppy disks are often nearby and the noise from seeks and transfers is usually audible. Similarly, streaming tape drives usually whine during transfer and modems provide dialing tones and line noise before connecting. Users quickly learn to interpret such noise a an indication that something useful is happening. While it may not be a good idea to depend on a disk rattle for feedback (especially in a noisy environment), modem designers have apparently standardized on the notion of providing connection noise to convey that initiation and protocol exchange is being accomplished.

We believe that it may be desirable to provide the option for audible indications of heartbeat and progress. In environments where such noise is not objectionable, users might benefit from audible feedback on task progress freeing them to train their visual senses on other aspects of the job.

5.4 Multitasking

As true multi-tasking becomes more commonplace in desktop systems, users will be frequently executing more than one task at a time (although they may focus on one at a time). Users of such systems want to start a task, ensure that everything is going well, and then concentrate on another task. While concentrating on the other task, the user may not require any progress updates for a background task.

In a multitasking environment, the user must be able to easily associate time affordance properties with the correct task. There may also be a need for a foreground mode (with a very active display) and a background mode (once the user is satisfied that the task is successfully underway). In a Windows environment, the modes could change based on whether the display was visible or occluded.

6. Summary and Conclusions

A user requests an action of a machine based on a model of the current machine state and the tasks that the machine is expected to be able to carry out. That model is based on knowledge the user either gains explicitly from currently available displays or infers from present and past behavior. The user may lack confidence in that model either because of doubts about the current state or about how to request the desired task.

After initiating a task, the user may thus be looking for indications that the computer's "understanding" of the state and the requested task are the same as his or her own. The time delay during which the task proceeds provides an opportunity for the user to seriously question assumptions about the model and about what is currently happening.

Determining how best to establish a shared man-machine model is the subject of a separate investigation, which will be described in a later paper. However, even with a perfect initial model, enough uncertainty surrounds networked computing that users clearly need help in understanding what is happening during a time delay.

The contribution of this paper is that it pulls together and builds on various principles currently available in the literature related to computer response time and techniques for displaying and controlling task progress. We have developed and presented a taxonomy of time-related properties and a set of guidelines for evaluating information displayed during a time delay. We call this display a time affordance because it provides the user with enough information to determine whether to wait or to take action. A time affordance not only describes what information a user might need but also how frequently that information needs to be updated. Without this information, users are likely to take inappropriate steps, either acting too soon to stop a successfully progressing task or waiting too long to terminate a potentially destructive one.

The idea of a time affordance is based on Norman's concepts in [9] and is consistent with the affordances in [3] and percent done indicators in [6]. We believe the ideas are an extension of the concepts of response time, documented in [10] and [4], more completely characterizing the components of a thorough display of time-based information. Enhanced feedback concerning delays can avoid the kinds of inappropriate responses discussed by Senge in [11].

7. Acknowledgments

Thanks to Geoff Bock for helping establish the context of this work and to fellow members of the Technology and Systems Engineering Architecture and Characterization group at Digital for feedback on many of these ideas.

8. References

1. Ahlberg, Christopher and Schneiderman, Ben, "Visual Information Seeking: Tight Coupling of Dynamic Filters with Starfield Displays," CHI ‘94 Proceedings, pp. 313-317 and 479-480.
2. DeSoi, John F, Lively, William M., and Sheppard, Sallie V., "Graphical Specification of User Interfaces with Behavior Abstraction," CHI ‘89 Proceedings, pp. 139-144.
3. Gaver, William W., "Technology Affordances," CHI ‘91 Proceedings, pp. 79-84.
4. Geist, Robert, Allen, Robert, and Nowaczyk, Ronald, "Towards a Model of User Perception of Computer System Response Time" CHI ‘87 Proceedings, pp. 249-253.
5. Mayhew, Deborah J., Principles and Guidelines in Software User Interface Design, Prentice Hall, Englewood Cliffs, New Jersey, 1992. Chapters 9 and 15.
6. Myers, Brad A., "The Importance of Percent-Done Progress Indicators for Computer-Human Interfaces," CHI ‘85 Proceedings, pp. 11-17.
7. Nielsen, Jakob and Phillips, Victoria L., "Estimating the Relative Usability of Two Interfaces: Heuristic, Format, and Empirical Methods Compared, CHI ‘93 Proceedings, pp. 214-221.
8. Nielsen, Jakob, Enhancing the Explanatory Power of Usability Heuristics, CHI ‘94 Proceedings, pp. 152-158.
9. Norman, Donald A., The Psychology of Everyday Things, Basic Books, New York, 1988.
10. Schneiderman, Ben, "Response Time and Display Rate in Human Performance with Computers," ACM Computing Surveys, Volume 16, Number 3, September 1984. See section 5 in particular.
11. Senge, Peter M., The Fifth Discipline, The Art and Practice of the Learning Organization, Doubleday, New York., 1990. See chapters 3 and 5 in particular.
12. Thovtrup, Henrik and Nielsen, Jakob, "Assessing the Usability of a User Interface Standard," CHI ‘91 Proceedings, pp. 335-341.

Figure 1: Analysis of a familiar dialog box for ZMODEM.

A: Acceptance: Computer has accepted input and begun processing.

B: Initiation and Heartbeat: Blocks are sized so that they always change within the tolerance window. For huge file, this field shows heartbeat.

C: A finer granularity estimate of progress, largely redundant for a fixed rate transfer, but useful as a check on ZMODEM settings.

D: Scope and Remainder: Computer's estimate of time remaining is believed only if it has been reasonably accurate in the past.

E: Exception: User will seek error indications if progress is not being made. If the error rate is sizable, user may take steps to terminate transfer.

F: Progress and Completion: Visual indication via "thermometer" with percentage indication works only if it is roughly equivalent to time delay. If it is based on non-linear information (e.g., count of files differing in size), the visual indication becomes a source of confusion.

Figure 2: Relationship of progress and scope tolerance window to dynamic delays having heartbeats. The progress tolerance window is elastic and could have been extended with other indications of progress.

Figure 3: Possible dialog box for processing files where the size of each file is not known prior to the start of processing.

A: Acceptance: Computer has accepted input and begun processing.

B: Initiation and Heartbeat: Because the size of a file cannot be determined at initiation, only the current (and previous) file sizes are known. The "thermometer" serves as a heartbeat indicating the progress of the current file.

C: Scope: The total number of files is the only real indicator of scope.

D: Remainder: The remaining files tells how much work remains. A thermometer would be misleading because of the implied correspondence between the spatial progression and time.

E: Progress: The increasing total bytes processed along with the movement along the list of files indicates progress. The key point is that the list of files processed is clearly indicated so that even if the last 12 are small and take only a second, the user will know that the processing was normal.

F: Progress and Completion: As the files processed steps toward the number indicated by C, the user understands that progress has occurred, and completion is near. A separate dialog box might be used to indicate true completion.

Figure 4: Possible dialog box for hierarchical reporting (displays progress for graphics primitives). This box shows both the overall task remainder (highest abstraction level) and a lower level of abstraction in which something happens within the tolerance window (in this case, the current primitive processing status changes).

A: Acceptance and Initiation: Computer has accepted input and begun processing.

B: Heartbeat: Reporting engine uses progress in processing primitive to provide updates within the tolerance window.

C: Scope: The total number of primitives indicates scope initially. The program could provide an estimated job time either from a parameter or by using experience from previous runs saved in a data file. As processing proceeds, the estimated remaining processing time is updated based on current job experience.

D: Progress: indicated by the increasing bytes, the count of primitives processed (and the thermometers).

E: Exception: indicated by total and current retries.

F: Remainder and Completion: indicated by the estimated remaining time counters, primitives remaining and the thermometers.