When an internal computer operation takes an indeterminate, but potentially
substantial amount of time, people may assume something has gone wrong.
They may reissue the command, or attempt other commands (clicking on
the desktop etc.) with potential for confusion if interactions are buffered.
Alternately they may look for clues as to the state of the system e.g.,
listening to the disk drive, asking colleagues in the same room if the
network is working for them, etc. A quaint example that an author
came across involved an ICL mini turn-key installation, where the operator
had turned up the volume of the diagnostic speaker attached to the computer
back-plane so that she could hear, by the change in tone, what stage in
the process the system was at, and could guess when printing would commence.
The real problem here is the indeterminacy of the wait — so if an indeterminate pause can be avoided, it should be. Unfortunately, this is necessary in some situations. At least, giving an indication that the system is still basically working will alleviate some of the anxiety.
Therefore:
Give feedback to the user that the system is basically functioning (by an animated image driven by events generated in the process) and if possible indicate the stage of the process that has been reached.
When this solution is implemented it is most likely appropriate to prevent input buffering, BUFFERING MAY BE DANGEROUS (#). If it is possible to make an estimate of the time that a process will take, then this should be given to the user so that they know that they have TIME TO DO SOMETHING ELSE (#) . . . .