3 ms·
The file download was a bad example. I understand the file download progress bar to mean how much of the file I have downloaded. No more, no less. Next to that
by sofal 15y ago
The file download was a bad example. I understand the file download progress bar to mean how much of the file I have downloaded. No more, no less. Next to that progress bar is the current rate and an estimate of the remaining time. This is not what frustrates me. What frustrates me is a progress bar for an installation task that sits at 99% or 100% for about the same amount of time it took to get there in the first place. I'm skeptical that this kind of problem happens merely because the last task happens to be unpredictably long every single time.
I'm betting most of the problems are less about variance in execution time and more about measuring the right tasks at the right granularity.
- donall 15y agoI agree that the download was a particularly bad example, but I think the same argument can apply to any progress bar. As a programmer, I always measure progress as the percentage of tasks completed, whether that is bit downloaded, modules installed, mappers finished mapping, etc. The mapper example is actually particularly pertinent. Hadoop's GUI shows me the progress of my M/R jobs with a bar, but it is as dependent on the amount of other tasks running on the cluster as downloading a file is dependent on the traffic in the network. There is no sane way to accurately estimate the amount of time a M/R job is going to take a priori, as far as I know. A stochastic method would be too variable and a method playing clever tricks with psychology seems especially insidious, from an engineer's perspective. You might as well replace it with an "Are we there yet?" button that responds to you in a soothing voice "Not much longer now".