Ask HN: Why don't progress bars ever work properly?
4 comments
Multiple factors influence the task being run, for a download it will be the speed that may vary, something being processed may vary too along the processing, same thing happens with file copy, many small files tend to be slower than a large one, and copying a mix of the will cause that too.
But isn't there a way you can trick the visual of the progress bar to be smooth and consistent instead of jumping around or is this an impossible development task?
Yes, there are all kinds of ways to do that.
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.
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.
Progress bars should show what? Percentage of "progress", ie. of the work done, or percentage of time spent processing the whole task?
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?
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?
Quite likely their accuracy is not tested by the software publisher. To the extent they are tested at all, they are tested using their own servers, in-house, perhaps over a LAN.
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.
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.
What really gets me down is when an indeterminate progress indicator is displayed during a determinate process.
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.
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.
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?