As long as there have been computers that do work, there have been various forms for communicating progress to the user.
I find these often to be a bunch of lying liars.
When the bar fills up, the operation should be complete. If it’s not, then don’t fill up the bar.
Here’s the dialog that prompted this post. It is the installer of a Visual Studio update. The bar is filled up, but clearly there is more work to be done.
Web usability expert Jakob Nielsen writes about acceptable response times for actions done by a computer in his book published in 1993!
In cases where the computer cannot provide fairly immediate response, continuous feedback should be provided to the user in form of a percent-done indicator [Myers 1985]. As a rule of thumb, percent-done progress indicators should be used for operations taking more than about 10 seconds. Progress indicators have three main advantages: They reassure the user that the system has not crashed but is working on his or her problem; they indicate approximately how long the user can be expected to wait, thus allowing the user to do other activities during long waits; and they finally provide something for the user to look at, thus making the wait less painful. This latter advantage should not be underestimated and is one reason for recommending a graphic progress bar instead of just stating the expected remaining time in numbers.
To their credit, the Visual Studio team did provide a sprite so there was some motion while the installation took place. But contrary to Nielsen’s suggestion, a filled up progress bar did not “make the wait less painful.” It just plain irritated me.
In the same way that developers should make their error messages meaningful, the status reported out to users should be useful and convey accurate information.
Photo credit: https://www.flickr.com/photos/jacksonmedeiros/2719799718/
