|
|
|
|
|
|
by WorldMaker
1703 days ago
|
|
|
I was relatively deliberate with my wording. I'm not saying "get rid of progress bars", I'm saying they are bad at their job but we've never managed to really make any thing better. Take your time estimation problem as the direct and obvious example: a progress bar on its own only really gives you a sense of timing if they move at a deliberate linear pace, which most can't do/promise (hence all the complaints about progress bars "stalling out at a percentage" when the system hits an outlier or discovers a lot more work to do), even then people are really bad at estimating linear speed of a progress bar. So a progress bar alone isn't great for judging speed. Other threads around here make jokes about trying to add time estimates near progress bars as another way to indicate progress. Again, they work some of the time, but also need assumptions that for instance past speed predicts future speed that are often hard to guarantee in practice. About the best progress bars can do is that "no it hasn't crashed yet" and spinners are generally better at that particular task (because progress bars don't have the granularity to show very small progression below 1/100th or 1/1000th or even 1/10000th of the overall workload), to the point that Windows added a spinner animation over top of its progress bars way back in Vista to make them better at the one job most users count on them for (for something of a best of both worlds, kind of, if you squint). Progress bars solve problems, they just solve them badly, and yeah, that was the point of my message that we also haven't found anything much better. I agree with you that they aren't perfect and are mostly fine. We just sometimes need to admit that they are bad at their jobs and we'd replace them in a heartbeat if we actually found a better progress indicator of some sort. |
|
|
My big idea was radial progress indicators to try a different "best of both worlds" approach to progress spinners versus progress bars especially for "composite" progress indication where you have an unknown number of subtasks all running at their own speeds and can be discovered/initiated independently (such as downloading files). People are worse at estimating percentages of circles than lines, which I see as something of a benefit (because the exact progress percentage should be fuzzy).
It's still not great at giving an indication of overall speed/estimated time, but it's potentially very great at "the application hasn't crashed and is busy".
It was fun to experiment with/prototype, but I don't expect it to replace progress bars any time soon. (I think it should, but it's trade-off space where every option has drawbacks and while it fits closer to what I think is my personal "ideal", it probably won't make everyone happy either.)
Demo: http://worldmaker.net/compradprog/
Source: https://github.com/WorldMaker/compradprog/
Blog post on intentions/thought process: http://blog.worldmaker.net/2015/03/17/compradprog/