Ask HN: Why don't progress bars ever work properly? I'm sending a text on my iPhone and the progress bar slowly moves from 25% to 50%, but then moves like a snail from 50% to 75%, then it zips to 100%. Why are progress bars broken? Ideally wouldn't the progress be consistent from 1% to 100%? This reminds me of loading for old flash games, it was never correct. Anyone know an answer? |
But typically you see stuff like:
for ( i = 1; i < 10; ++i ){ DoSomethingUseful( i ); DeterminateProgress( i, 10 ); }
So each iteration of the loop, the bar advances by one-tenth its maximum length, without regard to what DoSomethingUseful actually does.
Chalk it up to lazy coders and tight-fisted bean counters.
In the first case, if a task is subdivided in 4 subtasks, we can assign 25% for each subtask, but if the third task takes more time, then the progress bar will move slower for this subtask.
In the last case, how do you predict the future?
It is very important to test code under the same configuration that it will actually be used by real users.
In the case of network I/O, quite commonly the progress bar jumps when some data has been transferred into a kernel buffer, but the actual transmission of the data takes place in the kernel, and is not directly visible to userspace code.
There's no real way to know ahead of time how long a DNS lookup will take, so an indeterminate indicator is appropriate for that.
But when downloading a large file, the size of the file is often declared at the very start, in its HTTP header, yet we commonly get a spinning whirligig or a barber pole rather than an advancing bar.