Progress bar, the lie we all accept
Remember the good old days, when a progress bar in the user interface actually provided an indication of, well, progress? Alas, today the progress bar devolved into little more than a dancing monkey, doing the electric slide back and forth in its tiny box in an attempt to simultaneously communicate to me that something is happening while also trying to distract me from from the fact that I'll be waiting some indeterminate period of time for that thing to finish.
In the beginning, progress bars made a credible attempt to demonstrate the percentage of completion of some particular task. The movement of the progress bar wasn't always smooth -- it could linger on 25% complete a bit longer than 75% complete -- but it did provide a reasonable approximation of progress toward completing a task.
However, keeping the progress bar in general synchronicity with reality can be hard, so, over time, software designers began to give up. Maintaining any semblance of accuracy or smooth motion in the progress bar became a distinct non-priority. I remember my first exposure to this temporal dissonance while installing some software on Windows 95. The user interface provided a few vague textual messages about what was happening as the progress bar ranged from about 0 to about 90%. This took about 10% of the install's total time. During the remaining 90% of the total install time, as the progress bar inched its way the last 10% to completion, the installer provided textual messages with ridiculous detail on what it was doing. It's almost as if the point of the UI widget was to annoy rather than inform. Alas, this form of progress bar remains the most common species found in the wild today.
Shamefully, a colleague pointed out to me a particularly egregious progress bar in Visual Studio today, where it takes about 15 minutes to get to 100% and then lingers on 100% for several hours. Sigh.
And a particularly hideous offspring of the inaccurate progress bar is the one starts all over again from zero after it completes. Sometimes more than once. Oh, the humanity!
Anyhow... along came the web, which you might say forked progress bar behavior. Something like a progress bar was pretty difficult to do accurately in HTML, particularly when things you'd normally want to use a progress bar for tended to involve the code on the web site merely firing a single request to some other server, with no hope of knowing the progress. So instead of a progress bar, we got that progress-bar-appearing-thing-with-oscillating-Cylon-eye-motion. I'll call it PATWOCEM. The PATWOCEM's #1 goal is to encourage you not to navigate away to another web page by providing an indication that something worth waiting for is going on. On some level it makes total sense: If you just display some text like "please wait..." people will get impatient after a minute or so. However, add a PATWOCEM, and you probably increase their willingness to wait by a factor of at least 3x. While the psychological effect is no doubt real, I can't help but be frustrated by its functional uselessness and the continued devolution of the progress bar.
The PATWOCEM has found its way from the web to the rich client in the form of the indeterminate progress bar, which is so common in Windows Vista. I really do understand that this PATWOCEM is useful for cases where the overall progress cannot be determined, but I'm also confident that developers use this as a crutch when they don't want to do the bit of extra work involved in figuring out how to track progress of a given task. C'mon, do the work! Your users will be happier! My crack research staff (okay, me) uncovered the design guidance on progress bars for Vista on MSDN. The content is actually good. If only more developers followed it.