| I agree with the conclusion, but have different premises. "Time is an illusion, lunchtime doubly so." -Douglas Adams Progress bars were invented to give users an indication of how much time remains relative to how much has elapsed. This is problematic, because: 1. Progress bars have a linear appearance mapping to a discrete value, yet they often represent progress that occurs at an erratic, non-linear pace. A progress bar telling you the minutes remaining in a video is useful. Seconds are always the same. A progress bar telling you seconds remaining until the page loads is not. HTTP/XML requests are fickle things. 2. Even if a progress bar does accurately measure the relative time of a task, the utlitity of the bar is further confounded by the fact that people tend to have a non-linear perception of time. After all, users are much more forgiving in the first 10 seconds of a wait than the last 10 seconds. If a user simply feels that a task with a progress bar is taking too long, they might simply quit the task. 3. UI researchers at Carnegie Mellon found that arbitrarily accelerating the progress bar's movement toward the end of the task alone will make it appear to complete more quickly. So to make a progress bar that feels accurate and fair, lying to your users about the total relative time remaining is the right thing to do. Much of the utility of progress bars comes from telling the user that the page is still working and has not halted. So unless the users are in for a real wait, its probably best to stick to spinners. |