Warp wrote:

>   There actually are some programmers out there (even pros) who have actually
> not understood the idea of the progress bar. They seem to think it's something
> akin go the spinning wheel which is often used when the total time is unknown

Yes, some programs just have some kind of wheel that lets you know that 
it's doing *something*, even if it can't estimate how long it will take. 
Which is fine - the problem comes when they make it look like it's a 
"progress" indication, when in fact it isn't.

> The most typical error is that if the
> task done by the program consists of dozens of sub-tasks 
> the progress bar is used to indicate the
> progress of each individual subtask instead of using it to indicate the
> overall progress. Thus the progress bar becomes useless.

Indeed.

>   More competent programmers (or program designers) will put *two* progress
> bars in the UI: One to indicate the progress of the sub-task and the other
> to indicate overall progress. That's a whole lot more informative.

Yes. Although it still sometimes has the problem that some subtasks are 
extremely fast, while others are insanely slow. Still, it does at least 
provide a monotonically-increasing bar which fills up when the task is 
done. It's just harder to estimate time remaining.

(Don't even get me started on "estimated time remaining"...)

>   Of course even then there's room for incompetence: For example, a progress
> bar that updates too rarely and makes big jumps, or which pauses for too
> long at the beginning or the end.

Yeah, I hate that!

> Of course depending on the task in hand it may
> be quite difficult programmatically to update the progress bar smoothly,
> but still...

If you can't estimate progress in a meaningful way, don't pretend that 
you can. ;-)

Post a reply to this message