Introduction

Typical software packages today follow a rule-of-thumb approach to giving the user feedback. If the delay is known to be longer than ten seconds, an effort is generally made to estimate the delay and display feedback to the user -such as a dialog box with a progress indicator. Shorter delays are usually dealt with less visibly -such as an hourglass or spinning disc replacing the standard mouse icon.

This methodology works fine until there are unexpected outside influences on the speed of the system. One such example is an application which is running across a network. Increased network demands reduce the frequency with which packets can traverse the network between individual machines. This adds time between when a command is issued and when the networked processor begins acting upon the command. Thus, network delays can alter the total time between command selection and command completion.

Users have time expectations. If the system response time for a simple task exceeds 10s, users can become impatient (Kuhmann et al, 1987). Also, users subjected to uncontrollably long pauses in the system's response can become emotionally excited, exhibiting higher levels of perspiration (Kuhmann et al, 1987). This excitement and impatience can lead to excessive, and undesired, command execution. One such example is clicking on a menu item multiple times due to frustration.

Another issue to consider is whether an application continues to accept commands from a user, referred to as busy-delayed-response, or type-ahead. Applications can either practice busy- delayed-response, or refuse to "listen" to commands until after the current command has finished processing (Pérez-Quiñones & Sibert, 1996). Because very few systems specifically indicate whether they allow the user to "type-ahead," the prudent behavior is to assume that the system does in-fact follow the "busy-delayed-response" pattern (thereby assuming that whatever command has just been issued will be processed following completion of the current command). Any repeating of commands might therefore yield undesired results which would require later repair.

This experiment will treat extra mouse clicks as errors in order to illustrate the importance of keeping the user informed of the system status.

Department of Computer Sciences Direct questions and comments to the student editorial team