Menu
I know I am not the only one who does not like progress bars or time estimates which give unrealistic estimates in software. Best examples are installers which jump from 0% to 90% in 10 seconds and then take an hour to complete the final 10%.
Most of the time programmers just estimate the steps to complete a task and then display currentstep/totalsteps as a percentage, ignoring the fact that each step might take a different time to complete. For example, if you insert rows into a database, the insertion time can increase with the number of inserted rows (easy example), or the time to copy files does not only depend on the size of the file but also on the location on the disk and how fragmented it is.
Today, I asked myself if anybody already tried to model this and maybe created a library with a configurable robust estimator. I know that it is difficult to give robust estimates because external factors (network connection, user runs other programs, etc) play their part.
Maybe there is also a solution that uses profiling to set up a better estimator, or one could use machine learning approaches.
Does anybody know of advanced solutions for this problem?
In connection to this, I found the article Rethinking the progress bar very interesing. It shows how progress bars can change the perception of time and how you can use those insights to create progress bars that seem to be faster.
EDIT: I can think of ways how to manually tune the time estimate, and even with a 'estimator library' I will have to fine tune the algorithm. But I think this problem could be tackled with statistical tools. Of course, the estimator would collect data during the process to create better estimates for the next steps.
What I do now is to take the average time something took in the previous step (steps grouped by type and normalized by e.g. file size, size of transaction) and take this average as estimate for the next steps (again: counting in different types and sizes).
Now, I know there are better statistical tools to create estimators and I wonder if anybody applied those to the problem.
351
Each page's progress percentage-value is determined by the number of total pages in the survey. For a five-page survey, we take 100% and divide by 5, resulting in 20% progress per page. The 20% per page value is applied as follows: 20% progress after Page One is submitted.
Higher Number of Pulsations or Revolutions Another way you can make your progress bar feel faster to users is to increase the number of pulsations it has. The same research study found that “the progress bar with increasing pulsation was more likely to be perceived as having a shorter duration” [1].
Brad Myers, a professor at Carnegie Mellon's Human-Computer Interaction Institute, puts it thus: "There are many areas of computing where the system as a whole cannot predict how long [a task] will take, so progress bars don't move in a consistent way." Estimating how long it will take to install something as complex ...
Plainly, a progress bar increases our sense of engagement by allowing us to frame our work around a goal. It's no secret that much of our day to day tasks can be monotonous. But they're still things we have to get done—whether or not the results are immediately apparent.
While an undergrad, Julian Missig and I ran an experiment not unlike the Harrison et al. paper. As you might expect for a class project, we didn't really get enough data to make strong claims, except that for a 5-second interval, showing no progress bar was actually perceived to be shorter.
So, if the task is likely to take shorter than say 10 seconds, it's best not to show a progress bar at all. That's not to say that you shouldn't show any feedback, but a progress bar is likely to just make it seem slower.
If you're interested, Julian has the paper and poster on his site.
123
Thank goodness I'm not the only one!
I don't know of a library that handles estimation, but I can personally vouch for your profiling ideas. I once implemented a progress bar which was used to report the progress of a long, complicated file operation (several small files were being read, processed, and then combined into a larger file). I had the software keep track of the time it took for reads, writes and processing, and then adjusted the progress bar accordingly. After the program had been run a couple of times, the progress bar would move as smooth as silk. No pauses and no fast blips.
This works as long as the time taken for your operations are easily measured. I would be leery of using this method on something like a download progress indicator, since the speed of the network is completely indeterminate.
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
