4 ms·

The rate of change of that progress bar would be the gradient of the progress with respect to time. Could be a handy thing to have if, for example, you were de

The rate of change of that progress bar would be the gradient of the progress with respect to time. Could be a handy thing to have if, for example, you were designing some progress animation...

sockaddr 4y ago
To further your point, most UIs now don’t even go to the trouble of showing progress. It’s either an infinitely spinning glyph or a “progress” bar that just keeps scanning from left to right effectively providing zero information. Fun times.
- hnfong 4y ago
  What's the point? The downfall of progress bars because software engineers don't bother to learn calculus, or that they realized trying to solve the halting problem is an exercise in futility?
enlyth 4y ago
Progress bars are subtly evil, they seem simple on the surface but if you want to smoothly animate them you have to know or predict the exact time each segment will take proportionate to every other segment, and in most scenarios this is an exercise in futility, so a lot of progress bars end up being fake. I've seen a lot of cases where progress bars actually jump backwards because these predictions fail, whether it be games or applications, which feels like the universe is making fun of your existence when it happens. Sometimes it feels like a 'this action is not stuck' indicator would be more appropriate.
hnfong 4y ago
You're trying too hard to make up fake reasons to use calculus. Any self-respecting CS theorist would tell you that accurate progress bars are generally impossible to make because that would reduce to some version of the halting problem; and any self-respecting software engineer would tell you that even in the simple cases where the halting problem is not a problem (eg. simple copying of files), in practice many things outside of the software's control could stall the progress. Even if you could get an accurate progress value, you don't need a "gradient" to animate it. Just update the bar with the current value as a percentage at 60FPS and you're already done. (Progress bars generally ask the programmer to supply the current progress value, not a stream of progress rates in real time) If you tried to predict the progress "gradient" past the present point, you'd end up having to "lie" (more progress than actual) or have the progress bar jump back when it turns out the actual progress was slower than predicted. If all you had was a hammer, everything looks like a nail. That almost always applies for those enamored with advanced maths.

The rate of change of that progress bar would be the gradient of the progress with respect to time. Could be a handy thing to have if, for example, you were designing some progress animation...

sockaddr 4y ago

To further your point, most UIs now don’t even go to the trouble of showing progress. It’s either an infinitely spinning glyph or a “progress” bar that just keeps scanning from left to right effectively providing zero information. Fun times.

hnfong 4y ago
What's the point? The downfall of progress bars because software engineers don't bother to learn calculus, or that they realized trying to solve the halting problem is an exercise in futility?

enlyth 4y ago

Progress bars are subtly evil, they seem simple on the surface but if you want to smoothly animate them you have to know or predict the exact time each segment will take proportionate to every other segment, and in most scenarios this is an exercise in futility, so a lot of progress bars end up being fake. I've seen a lot of cases where progress bars actually jump backwards because these predictions fail, whether it be games or applications, which feels like the universe is making fun of your existence when it happens. Sometimes it feels like a 'this action is not stuck' indicator would be more appropriate.

hnfong 4y ago

You're trying too hard to make up fake reasons to use calculus. Any self-respecting CS theorist would tell you that accurate progress bars are generally impossible to make because that would reduce to some version of the halting problem; and any self-respecting software engineer would tell you that even in the simple cases where the halting problem is not a problem (eg. simple copying of files), in practice many things outside of the software's control could stall the progress. Even if you could get an accurate progress value, you don't need a "gradient" to animate it. Just update the bar with the current value as a percentage at 60FPS and you're already done. (Progress bars generally ask the programmer to supply the current progress value, not a stream of progress rates in real time) If you tried to predict the progress "gradient" past the present point, you'd end up having to "lie" (more progress than actual) or have the progress bar jump back when it turns out the actual progress was slower than predicted. If all you had was a hammer, everything looks like a nail. That almost always applies for those enamored with advanced maths.