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%.<p>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.<p>Anyone know an answer?
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.
Progress bars should show what? Percentage of "progress", ie. of the work done, or percentage of time spent processing the whole task?<p>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.<p>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.<p>It is very important to test code under the same configuration that it will actually be used by real users.<p>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.<p>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.<p>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.