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.
Comments
Anonymous
April 30, 2007
Wouldn't it be nice if Visual Studio Orcas would have a determinate progress bar when you start it for the first time rather than an indeterminate progress bar? "consider showing the list of steps and using check marks to indicate the completed steps" But that reminded me of the Pareto principle. Would it be worth the time it would need to implement a accurate progress bar as well as the time to calculate the range? I think the Windows installer has gone a better way, rather than trying to display an accurate time until the user is prompted the next time to do some settings or enter the key install everything silently and then prompt the user for all the settings at the end of the installation.Anonymous
May 01, 2007
The comment has been removedAnonymous
May 01, 2007
Operational lies the progress bar. Oops, wrong blog. http://blogs.msdn.com/oldnewthing/archive/2007/05/01/2346459.aspxAnonymous
May 02, 2007
The comment has been removedAnonymous
May 03, 2007
You guys won't catch me defending the VS progress bars. I think we're particularly bad offenders here, and part of the reason for my post is to raise awareness and ultimately make things better. :)Anonymous
May 06, 2007
The biggest news in the C# community is the official announcement of Silverlight at the MIX conference.Anonymous
May 07, 2007
Steve, Great post, I'm with ya brother. It seems Vista has really taken the Progress bar to new depths and the comboboxes on my Explorer windows are constantly gyrating I suppose in hopes I'll slow down long enough to appreciate all the "work" their doing.