Faster Progress Bars: Manipulating Perceived Duration with Augmentations (2010)
chrisharrison.net
chrisharrison.net
This makes me mad at your app, and very slightly less likely to use your software.
Good luck measuring my slight disdain.
Yet, users want progress bars anyway. Without an apparent, finite timeline, they get frustrated and angry quickly. Thus the conflict.
So, the recommendation I’ve seen is 1) work very hard to get as smooth and linear if a bar as you can. And 2) fudge the numbers to give it a bit of acceleration to counter the user’s decreasing patience.
Transferring a file byte-by-byte is easier that a list of arbitrarily sized files. Fixing that would require reading all the file sizes first, or some complex logic to determine when to pre-plan the updates.
What about some kind of "learning progress bar"? It keeps track of the updates that have been made and predicts how long a new user will take based on previous users experience with the bar.
The classic case is installation progress bars, repeated uses of same/similar sequences of steps with indeterminate length of time. But if you aggregated the real-time data from all those progress bars, each new bar becomes a kind of dynamically-updated prediction of how much time is left on the bar.
Tangentially, I've experimented with a different sort of "learning progress bar", in that I think one UX problem we face is that we've learned the hard way that linear progress bars aren't allowed to go backwards/shrink. It confuses/angers too many users to watch a progress shrink and gives the wrong impression that something has gone wrong or is being rolled back (that progress is somehow "lost").
This is a problem because a lot of our problem solutions are recursive and we don't have a full estimate of the problem scope until we've recursed the full depth to the leaves of the problem tree.
My experiment [1] was with the idea that with a radial progress bar you can "shrink" it, but still give an indication of "forward" progress (clockwise movement in this case). You get to take advantage of the fact that perceptually people can tell the difference between small increments linearly, but not small increments radially (the reason why pie charts are actually not particularly great UX if you need someone to perceive subtle differences). It seems like a "best of both worlds" approach in that in the task discovery phase it acts like a "spinner" and as discovery completes it becomes more of a progress bar, and if for some reason a bunch of new tasks are discovered mid-flight you get a hybrid of the two.
[1] GitHub: https://github.com/WorldMaker/compradprog ; Blog post: http://blog.worldmaker.net/2015/03/17/compradprog/ ; Demo site is currently broken (hello tech debt from 2015), sorry
IIRC, the length of time each discreet operation takes is measured, and as the queue of operations is processed, the software keeps track of the minimum, maximum, average, and median time to complete an operation. I played around with various ways of using that to generate an estimate for the remaining operations to complete. I think I settled on taking the larger of the median and average, using that as value A, using the maximum as value B, multiplying both A and B by the number of remaining operations, then dividing both by the number of processing threads, and giving the estimate as "about [A]-[B] remaining."
One could do that in a GUI with a "fuzzy progress bar", or one with 2-3 coloured segments or something (one for worst-case estimate, one for average/median, and one for minimum).
[1] https://www.beneaththewaves.net/Software/The_Mirrors_Surface...
Otherwise it makes the ride more awkward because I try to avoid locking eyes with someone else through the mirror.
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.
My general perception is that most commercial software is putting in the effort to calculate time remaining these days. Are there any open-source tools that help with this? It would be awesome to collect analytics during development (opt-in in production) and apply it to calculate more and more accurate time estimates.
I see these way too often, and most operations really should feel instant to the user. Little things should not be taking multiple seconds to complete.
And for the occasional actually-time-consuming task, calculate the end point so you can display a proper bar. An indeterminate spinner is laziness, forcing the user to wait an unknown amount of time when you can probably figure it out.
Local (client-side) operations are a different matter entirely. Either precompute the result for common operations or optimize for speed!
As a general rule, every single edit should be able to return control to the user immediately. If the network can’t be reached, save locally and attempt an update in the background (showing a small, unobtrusive annotation that an update is pending, as opposed to a screen-erasing obnoxious progress popover). And definitely don’t erase everything the user did if the network ends up being unreachable.
> Progress bars with animated ribbing that move backwards in a decelerating manner proved to have the strongest effect.
So I guess that'd be the second, third and fourth from the bottom at the start of the video, but I'm listening without sound so perhaps someone can confirm.
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.
Unless they have a scale of "perceived speed to actual speed" for regular progress bars, that they're using to gauge the enhanced ones?
> For our final study, we selected a progress bar that featured Backwards Decelerating ribbing, as this was slightly preferred over the pulsating behavior in study three. This was compared against a standard, solid color progress bar. The test interface, instead of simply recording participant’s preferences, used the responses to warp the duration of the ribbed progress bar (the solid color progress bar had a fixed duration to act as a control). Specifically, if a user felt the ribbed progress bar was faster, its duration was extended (to slow it down). Conversely, if the user felt the ribbing was slower, the duration was reduced (to speed it up). Equal responses left the duration unchanged. The goal was to allow participants to converge to a duration where they believed the two progress bars “felt” equal. (For an extended discussion on method of adjustment experiments,please refer to [3], “Difference Thresholds”).
So I want to guess they were given some kind of interface that would let them decrease the speed in increments of 1%, perhaps.
I'd like a progress bar to actually report on progress. If you can't do that, don't feed me bullshit blinking lights, and pat yourself on the back. Just tell which part is hanging up, so I can either clear the bottleneck, route around it or throw everything in the trash.
I'm torn at this point, about which non-progress bars I hate more these days, Apple's or Microsoft's. Windows used to have the most useless progress bars:
But Apple system updates for OS X are possibly much, much worse. Reporting 20 minutes and taking 90, opaque, inching along pixel by pixel, and not telling you anything about what's slow, or whether there are parts to the process. Just one stupid line, and if it fails in the middle, start over. Is it unzipping, checking the integrity of file hashes, connecting to the internet, not connecting and waiting for a time-out, compiling open-source packages for this particular chip set?
One thing's for sure, I've been promised so many minutes, and instead lost hours.
But there was also a "show details" button, which would then open a mini-terminal (of sorts) and show the flow of what is actually happening behind the screen, so to speak (essentially identical to what you'd see if you were installing/updating at the command line).
So you not only got a nice and (usually) accurate GUI representation, but if you wanted, you could also see extreme detail of what was going on or why something was taking a long time (maybe it's trying different servers to find a dependency, or it's downloading a file and something is slowing it down - or maybe your router has crashed, and its just sitting there, etc).
IMHO, that's a much better way to represent things - keep a simplified view as default, but allow the option to see all the sausage making in the background, for those who want or need it.