5 ms·

The problem with progress bars as the coder is that it's often difficult to tell how far you are into a process if it's not a repetitive sequence of similar ste

The problem with progress bars as the coder is that it's often difficult to tell how far you are into a process if it's not a repetitive sequence of similar steps. 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.

WorldMaker 9y ago
That's an interesting idea. You'd still have an issue if the process has a very high standard deviation or a lot of outliers. You almost need some sort of useful UX for the error bars of the progress (+/- 3%, +/- 15 minutes), but if polling statistics seems to prove anything, error bar UX is something that we have never been able to build in a way that a person with no to little statistical background can appreciate. 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 https://github.com/WorldMaker/compradprog ; Blog post: http://blog.worldmaker.net/2015/03/17/compradprog/ http://blog.worldmaker.net/2015/03/17/compradprog/ ; Demo site is currently broken (hello tech debt from 2015), sorry
blincoln 9y ago
Regarding the "learning progress bar", I implemented something vaguely similar in software that I wrote awhile ago[1], although it was within the context of a single set of tasks, not for multiple sets over time. 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_Breaks.html https://www.beneaththewaves.net/Software/The_Mirrors_Surface...

WorldMaker 9y ago

That's an interesting idea. You'd still have an issue if the process has a very high standard deviation or a lot of outliers. You almost need some sort of useful UX for the error bars of the progress (+/- 3%, +/- 15 minutes), but if polling statistics seems to prove anything, error bar UX is something that we have never been able to build in a way that a person with no to little statistical background can appreciate. 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 https://github.com/WorldMaker/compradprog ; Blog post: http://blog.worldmaker.net/2015/03/17/compradprog/ http://blog.worldmaker.net/2015/03/17/compradprog/ ; Demo site is currently broken (hello tech debt from 2015), sorry

blincoln 9y ago

Regarding the "learning progress bar", I implemented something vaguely similar in software that I wrote awhile ago[1], although it was within the context of a single set of tasks, not for multiple sets over time. 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_Breaks.html https://www.beneaththewaves.net/Software/The_Mirrors_Surface...