As part of my undergraduate coursework, I put together a small study with Daniel Dickison to look at the effects of progress bar speed on apparent task duration. It was just for an experiment design class, so it wasn't published, but I have the poster [pdf] and the paper [pdf] up on the web for the curious.
Ignoring the cognitive science debate about which model of temporal attention is correct, I concluded:
The progress bar increases attention to the internal clock, causing a greater accumulation of time pulses, which means a more accurate perception of how much time has elapsed. Without the progress bar, the participant is attending to the concurrent task quite a bit more and does not accumulate as many time pulses. …
It is clear, though, that the lack of progress bar does cause an underestimation of time for the 5-second duration. While current models predict this, it is a somewhat counterintuitive result and has interesting applications for computer interface designers—progress bars should be left out if the task is 5 seconds long (and perhaps less).
It was nice to find, via Coding Horror (and there via FriendFeed), that Chris Harrison of the HCII along with others have done more extensive research [pdf] in a paper published in UIST’07. They did not look at different durations like Daniel and I did, but they did further investigate different types of progress bars. Basically, pauses and hiccups in progress bars cause users to believe something is taking longer:
However, progress bars with dynamic completion conditions and roughly estimated durations (e.g., defragmenting a hard drive) can be augmented in two significant ways. First, since users seem to have a strong aversion to pauses especially towards the end of an operation, progress bars can be designed to compensate for this behavior. An intelligent progress bar can cache progress when the operation is first starting to mitigate negative progress behaviors (e.g., pauses or slow-downs) later on. Secondly, progress can be downplayed in the beginning and accelerated towards the end, providing a sense of a rapid conclusion that is highly favored by users in our experiment.
I think it's important to understand the effects that progress bars have on people's perception of task duration. We spend an awful lot of time staring at progress bars waiting for things to finish—designers should be aware that they have the means to make these waits feel as smooth as possible. For short tasks—a threshold somewhere between 5 and 10 seconds—the appropriate choice is no progress bar at all. For longer tasks, one should be trying to start that progress bar as early as possible and keep it running smoothly. I hope we see more work along these lines.