We’ve all sat in front of our computers watching the words “please wait” blink on the screen, watching some dot move in a circle indefinitely, or worse, watching a progress bar get to 99% in 10 seconds, then get stuck there for hours. Is there anything we can do to improve this user experience nightmare?
According to Ben Shneiderman, we should “offer informative feedback” to users as part of our interface design. When the computer is processing a user’s command, this needs to be explicitly indicated to the user if expected to take longer than two seconds. So, inadequate as they may be, we’ve got to keep using them – it’s better than nothing.
Most of these indicators fall under two types: loading symbols and progress bars. Loading symbols express that the computer is working on something for an unspecified amount of time. Progress bars specify the percentage of a computer’s task that’s been completed. (For purposes of this discussion, a bar-shaped indicator which does not express percentage of completion is still a loading symbol, not a progress bar.)
Unfortunately, I’ve noticed a couple of problems with these indicators. First, people use loading indicators when they should be using progress bars. This is fairly simple to solve – just establish a specific threshold of expected loading time at which point a progress bar is necessary, as opposed to a simple loading symbol. Jakob Nielsen advocates the use of progress bars when the computer is expected to take over 10 seconds to complete its task. Surely some additional research has been done that would aid user experience professionals in coming to a consensus about this issue?
The second problem I’ve noticed is that progress bars are grossly inaccurate. Some indicators display a number of minutes until completion which changes based on available bandwidth or other factors. This number often changes so radically over the course of the process that it loses its worth for the user. Other times, a download speed is shown, but this download speed varies drastically, seemingly at random. You could be getting a speed of 50 kbps, but close the window, start over and you get 250 kbps right off the bat. There’s probably a great explanation for this from the technical perspective, but to a user, that just seems like nonsense.
There appears to be no easily achievable solution to this second problem. The accuracy of progress bars is something developers have struggled with for what probably feels like centuries. The difficulty of the problem and apparent tolerance from weary users should not give us an excuse to become complacent in this matter.
A few people have begun the journey toward solving these problems. Chris Harrison, in his study study, “Rethinking the Progress Bar“, provides some helpful insights into users’ perception & preferences. For instance, he applies the concept of “peak effect” to conclude that reducing this effect makes a progress bar seem faster.
While this study does offer some suggestions for improving how progress bars are perceived by users, it does not provide distinct solutions to make progress bars correspond more accurately to the processes being performed by the machine.
Have you found or done any research in this area? Do you know any techniques for improving progress bar accuracy? How do you feel about the inaccuracy of progress indicators and its effect on user experience?
5 Comments
Loading comments… Please wait…
…………………………….
…………………………….
…………………………….
…………………………….
…………………………….
Unfortunately the progress bar will always be a casualty of the development process. The most important thing is to get a software product released on time. In most cases people just use the code that is already out there, and that probably won’t ever change. The progress bar’s job is to let the user know that the system is still working. Anything beyond that is usually going to be seen as a waste of resources.
While a Progress bar is definitely not going to make or break a project’s reception, it is a simple and nice way to let the user know that someone actually cares about them. Sitting, watching a progress bar for hours, wondering if it’s doing anything, not necessarily the highlight of my day.
I find the inaccuracies of “loading symbols” and “progress bars” to be VERY frustrating. It is not uncommon for me to wonder if something really is working (or is it stuck in a “loop”?) or how long something is going to take. Obviously, or at least it should be obvious to programmers/developers, that we don’t need progress bars that have millisecond accuracy. But it would be nice to have a progress bar that gives a realistic “ballpark” figure of how long something is going to take and not just take 2 mins to get to 99% and then another 25 mins to finish. Besides, the creative people could enjoy making cool looking progress bars so the waiting can be “entertaining”! lol
I agree that a threshold should be used to determine whether or not to use a load symbol/animation, or a progress bar.
However, with the exception of a page or information loading on the web, I think it makes the most sense to give the user an upfront estimated time to finish the task, let the user go about their work, and alert them when the task is finished.
Compare Internet Explorer’s download vs. Google Chrome’s download. Internet Explorer uses a separate window with a progress bar to show you what you’re downloading. Oh, and they’ll show you a separate window for every single download.
Google Chrome, on the other hand, keeps the download progress small, out of your face, and within the context of the download (within that tab). All of the downloads are placed within the little “download panel/area”. When the download’s done, the file icon changes appropriately. And for kicks and giggles you can access the history of your downloads from that same “download panel/area” (and re-download if you misplaced the file for some reason).
P.S. I’m procrastinating right now. So I’m commenting on your blog mang ;)