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.
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.
I long ago gave up on progress bars. All too often it would show a task as being 100% complete - for hours, as you noted - or just jump from staying on 25% complete for many minutes to stayong on 60% complete for many more minutes. As for the current graphical displays of spiraling wheels or dancing bananas or whatever, that's as useless (and annoying) as the endless loop of "Your call is very important to us, please stay on the line" in voice mail. The killer for me was trying to install VS under Win2K - it would get to the point of showing completion on the last CD, and then it would just stay that way forever, until I rebooted. The only way to tell that it was actually not doing anything was to use the Task Manager and see that the CPU usage had dropped from 100% to 1%. (BTW, the fix that finally allowed the installation was not simply to disable the Symantec security suite, as I had done, but to remove it altogether.) Anyway, when a process is hung and the performance bar tells you "Hold on, I'm nearly finished!", then it's an obstacle rather than an assistance.
Operational lies the progress bar.
Oops, wrong blog.
http://blogs.msdn.com/oldnewthing/archive/2007/05/01/2346459.aspx
I implemented a progress bar on loading files, for an old old application I worte (Win 3.1 days). It was an engineering application where files were in some hokey format, containing numerical data, configurations, diagrams (in a heirarchy), etc.
My project files could get arbitrarily complex and there was really no way to know how long they would load and get the internal representation all set up. So what I did was put in a "click" callback during the reading/interpretation code, and make it high-grained (i.e. many clicks, evenly spread out from start to finish).
When a project is loaded, you have a million or so "clicks" that measure how much "work" it took to load the file. This gets saved back out the next time the user hits Save. Odds are the next time you load the same project, the amount of work to load the file is going to be roughly the same. Because the clicks are evenly distributed, you now have a way to smoothly progress the progress bar on the second load. (For the first load, just guess.)
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. :)
The biggest news in the C# community is the official announcement of Silverlight at the MIX conference.
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.