stupid progress messages

[waider]

DUMP: 99.92% done at 287 kB/s, finished in 0:00
DUMP: 100.00% done at 287 kB/s, finished in 0:00
DUMP: 100.00% done at 268 kB/s, finished in 0:00

I hate useless progress indicators, but it seems they're the most common type around. A progress indicator needs two things in order to be useful: knowledge of the completion time, even if only approximate, and consistent speed. I can't be the only person who gets ticked off at installers that go from 0 to 96% in 5 seconds and then spend two hours making up the remaining 4%. I'm not interested in how much work is left in the job, I'm interested in how much longer it's going to take to finish.

Comments

[boutell.livejournal.com]

I think it's probably possible to write a generic progress meter package that is adaptive -- the application would pass a meter ID and its best guess of completion percentage based on some rude metric like how much work is left in the job; the progress meter would keep statistics over time and learn how to adjust the curve for various meter IDs and get more and more accurate. You could also save the resulting data and include it when shipping an application so that results are close to perfect on the first go at least if the user's operation of the program is comparable to that during testing.

[bitpuddle.livejournal.com]

When my mobile phone grabs e-mail from a server, it puts up a little message that says:

Received: 1
Not Received: 0

I'm still not sure what "not received" means.

[sambushell.livejournal.com]

As soon as I see two decimal places in a percentage progress measurement, I know this hasn't been thought out enough.

This is a particularly hard problem when a long operation has two parts, and the amount of work in part 1 is known a priori but the amount in part 2 is not.