When I implement progress bars I most often implement "pessimistic progress", so "considering all timeouts, worst case we are 46.5% (of the time) to some result", with an update every few hundreed milliseconds. As possible mix in data from completed subtasks.
Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.
Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png
Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged.
It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.
How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that:
1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.
2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.
Single pass and aggressive buffering seems to cover what I remember, but it worked better than it I expected, even on high speed drives or SSD to high speed drive. They may have had other tricks, it's been a while now.
The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.
I find the Progress bar is usually about as accurate as the Time Remaining calculation. Both are better than nothing but more of a fiction than reality.
True! I know some of the people involved in the windows update bar. Since cpu and dusk are so different across devices it’s hard to know actual time it will take. Instead teams divided their packages into theoretical weights and the progress bar showed the percent of total “weights”. That’s why it can be choppy is packages with few subdivisions have little to interpolate.
With a process that happens on regular intervals like a Windows Update, I always wondered why the system doesn't store metrics on how long the process has historically taken on previous runs, and then just uses a weighted average of historical times as a time-based total estimate, converted into a divisor for work-based progress estimates (i.e. if previous runs took 60 minutes on average, then progress at 25% would say "45 minutes remaining", then if it suddenly jumped to 50% would immediately say "30 minutes remaining." Even if they're choppy, those time estimates would actually be correct if you sampled and averaged them.)
Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.
Progress indicators that moving perfectly and steadily are probably time based, but I'd have thought they've always been work based. Example: you know you have to copy 20GB across the network; update the progress bar with 'percent of data complete' periodically (on a timer, in the byte copying loop, whatever.)
I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)
I've written progress bars that combine all of the above. Each sub-task had a weight though, and adaptive interpolation was used to animate the progress bar between chunky updates from less granular tasks based on how far they usually increment over which time interval.
