I definitely agree that showing a progress bar makes a slow operation feel faster, I've seen this work many times.
I think I disagree about the constant speed vs stuttering progress bar example though -
Progress bars which progress smoothly are great if they are accurate. But because sometimes a UI will show a fake progress bar smoothly filling that will empty after filling and fill again, I've been trained to become skeptical of them. I don't think I've ever seen a stuttery progress bar that was "fake" in that way.
Showing a constant speed progress bar to hide stutter is effectively applying a low-pass filter. Since stutter carries information (that may not be of interest to all your users, but perhaps some), you're low-pass filtering that information.
It is a deceit - you're purposefully concealing information, and you're doing it for some reason. How bad is that? It depends on how much a given piece of information is useful to the recipient. Smoothing out something where its high-frequency data matters to the user isn't nice (and can be paternalizing at times). Imagine your car speedometer didn't display instantaneous speed, but a running average over a one-minute window. Would you feel comfortable about it? Or if your bank account displayed your balance as a running average over a week-long window?
Progress bars being accurate isn't that important for most, but it may be for some. In a same way you can get a feel for your car by listening to the sounds it makes, you can get a feel for the state of your computing environment by observing a progress bar. For example: does it seem to slow down hard whenever the "storage" light on your laptop is blinking fast (in the old days - when your HDD makes noise)? It may imply you have an issue with your storage. Smooth a progress bar out, and you're removing such environmental cues.
Why should the perception of speed have to be based on deceit?
I bet I would perceive a progress bar that progresses with constant speed as faster than one that stalls and stutters even when both of them take the same time to completion. Even more if the alternative would be an indefinite progress indicator (hourglass pointer, spinner) that just goes away when the task finishes.
On the other hand if the result is that a user is less annoyed by a process, I do not see why it should be wrong to convey that feeling artificially by setting up a situation in which the same result makes them feel better than in a more "honest" one (as you might call it?).
> Progress bars have very low credibility on Windows, because users have learned that they're basically useless as an indicator of wait time. A progress bar might get stuck at 7%, then suddenly rush to 100%; conversely, it might get stuck at 95% but never finish. The bar offers no real indication of the actual level of progress
I disagree with this; I find the progress bars more credible with erratic timing. (And ideally, a display of the task currently at hand, like "Copying tiny file. Copying tiny file. Copying giant file............")
A progress bar that smoothly fills from 0 to 100 looks like an animation that somebody thought it would make you happy to watch. A progress bar that lags at 7% and then rushes the rest of the way looks like the software has some internal metric for task completion, and is reporting according to that metric. This implies that when the number changes, progress has happened, which isn't the case for a progress bar that isn't affected by workload.
The software can't use "how much time has elapsed?" as a progress metric, because it doesn't know how much time things will take, and because the passage of time does not actually cause -- or reflect -- any progress. That progress bar would be a spinner, not a progress bar.
Don't have a link, but I recall research showing greater user satisfaction if you bias the progress bar to start artificially slow so that it can always be slightly accelerating. The acceleration of the bar helps to cancel the acceleration of the user's impatience.
There are similar UX concerns for progress bars. Users will perceive an operation as taking less time if the progress bar accelerates (i.e. the last half takes less time than the first half) than if it decelerates, regardless of actual time taken. This was an annoying problem with file copying in Vista where the typical behavior was to progress along to close to 100% then hang there for a while, which people hate experiencing.
I disagree. There's a difference between a progress bar that could just be a spinner or no progress bar at all because it's fake. And a progress bar that attempts to communicate real progress.
You're right that we should all strive to build UI that responds instantly. Unfortunately sometimes, for reasons out of a designers control there might be a legitimate reason for a site to reach that level - for that, adding a subtle progress bar does help.
Think of it as a local optimisation before you reach a global one of instant UI.
Good on you. Most progress bars are about user experience and not so much about accuracy. People just want to know that there's a long sequence of work and that progress is being made.
It's often an illusion and showing too much how the sausage is made makes the user start asking questions about what's happening behind the scenes.
That said, a long task that is prone to failure due to external factors should definitely be conveyed in the progress bar. If a bad network connection is affecting a process from finishing, you obviously want the user to know that so they don't blame the software for being slow. :)
I agree with the conclusion, but have different premises.
"Time is an illusion, lunchtime doubly so." -Douglas Adams
Progress bars were invented to give users an indication of how much time remains relative to how much has elapsed. This is problematic, because:
1. Progress bars have a linear appearance mapping to a discrete value, yet they often represent progress that occurs at an erratic, non-linear pace. A progress bar telling you the minutes remaining in a video is useful. Seconds are always the same. A progress bar telling you seconds remaining until the page loads is not. HTTP/XML requests are fickle things.
2. Even if a progress bar does accurately measure the relative time of a task, the utlitity of the bar is further confounded by the fact that people tend to have a non-linear perception of time. After all, users are much more forgiving in the first 10 seconds of a wait than the last 10 seconds. If a user simply feels that a task with a progress bar is taking too long, they might simply quit the task.
3. UI researchers at Carnegie Mellon found that arbitrarily accelerating the progress bar's movement toward the end of the task alone will make it appear to complete more quickly. So to make a progress bar that feels accurate and fair, lying to your users about the total relative time remaining is the right thing to do.
Much of the utility of progress bars comes from telling the user that the page is still working and has not halted. So unless the users are in for a real wait, its probably best to stick to spinners.
Progress bars are great when they convey meaningful information... sometimes it's nice to know if you have time to grab a coffee, or actually eat lunch. In my experience (when having to supply said bars) is that they serve primarily to tell the hapless user that things are still happening. In other words, the actual number is not important...what is important is real feedback that things are still happening and it's worth waiting. Or things are b0rked and you should start over. I don't care about a real time or % progress bar...just something that honestly (to OP's point) lets me know that things aren't screwed.
I think this research shows that you can influence perception of time without resorting to outright "making up" the progress bar. You can imagine using this technique not to lie about progress but just to make short progress bars appear to move faster.
I spent several hours in Google Analytics yesterday. It's been a few months since I've used it, and I remember thinking that it seemed a lot faster. They've recently refactored their UI, and possibly done some system improvements, who knows. But after looking at this research, I can see that they've also taken advantage of similar techniques to make their loading bars seem faster. It's a free improvement of 11% in perceived speed, just for changing an animation, without misrepresenting the underlying information.
Do you consider progress bars and loading states "deceit"? It helps to know that something is happening, vs just a frozen UI with no indication of work being done in the background.
I have an app that does some prediction based on values that a user enters. The prediction works pretty fast – unnoticably fast, like 50ms or so.
However, I had the idea to use a progress bar to achieve the opposite effect: To introduce an artifical waiting time together with a sense of progress (hence, progress bar). This should convey the feeling that the app is working hard to make Your Personal Prediction and since the app appears to be calculating a lot of stuff, the prediction Must Be Totally Accurate.
Surely, the target users are not necessarily sophisticated technical people.
I haven't implemented it but I definitely want to try it out.
For me, the annoyance comes from not being able to tell if the operation has stalled ("Did it just inch forward, or was that just a pulse?"), which decreases the amount of useful information available to me.
I would guess this is done intentionally, to keep impatient people from canceling the operation when they should really just let it run. If that's the case, however, I would argue that the real problem is not providing enough feedback to indicate whether the operation is still proceeding as planned. Ie, whether a long wait is expected at this step or not. I wonder if a progress bar is really the best indicator for this purpose.
There’s a trade off between speed and showing progress to the user. I find it better to show slow progress rather than wait 500 - 1000ms to do it faster, but it depends on the use case
If I click a button and it instantly shows me a dialog with a progress bar, and the progress bar progresses smoothly for one hour to complete the task, that is responsive (the UI responds to my click and the background update as quick as anyone could desire).
That the task takes an hour to complete may or may not indicate a problem with performance.
The fact that the task shows a progress bar at all is likely because at some point the task would complete synchronously and without a progress bar in say 10 seconds or 60 minutes. In that case, the programmer mistake was to allow the problematic performance of the program affect the responsiveness of the program.
So a progress bar is used when the performance can't be easily fixed but the program must be responsive.
I think I disagree about the constant speed vs stuttering progress bar example though - Progress bars which progress smoothly are great if they are accurate. But because sometimes a UI will show a fake progress bar smoothly filling that will empty after filling and fill again, I've been trained to become skeptical of them. I don't think I've ever seen a stuttery progress bar that was "fake" in that way.
reply