[Tfug] Progress indicators

[Bexley Hall]

Hi, Jeff,

--- On Tue, 1/13/09, Jeffry Johnston <tfug at kidsquid.com> wrote:

> Here are my thoughts:
> 
> When the prediction is constantly being updated, I feel
> like I cannot trust the number of minutes left.  For example,
> it initially says 12 minutes remaining.  I come back in 12 
> minutes and it says 9 minutes remaining.  This can be somewhat
> lessened by waiting a little bit before declaring the time 
> remaining.  I think Firefox does this.

Yes.  OTOH, are you NOT disheartened by seeing the progress
bar cruising along at a steady pace (e.g., 5% per second)
and then, *suddenly* stalling?  I.e., how long will it stay
"stuck" in this place?  Go away for 12 minutes and it is
*still* stuck when you come back!  Etc.

> Another thing which is annoying is that even though
> estimates and re-estimates are continually wrong, the 
> program continues to use the same estimation technique, 
> so you know it'll be wrong in the future too.  So then
> you end up estimating how long it'll REALLY take.  Seems
> like it should periodically do a curve fit to the data, and
> update the algorithm .. linear, geometric, logarithmic, 
> exponential, etc that best matches the past performance.

Well, I'm talking about use in an *appliance* so I can
be a lot smarter than a desktop application  :-/  My point
was to make a *hasty* estimate initially and then refine it.
So you can show *some* indication, then fix it.

But, I am *mainly* concerned with the fact that traditional
"progress indicators" monotonically increase.  I.e., even if
it *stalls* -- or *jumps* ahead -- it is always moving in
one direction.

OTOH, indicators that are expressed in terms of time estimates
do not exhibit this monotonic behaviour!  I worry that seeing
an idicator go from (graphically *or* numerically) "27%"
to "10%" will be very counterintuitive -- DESPITE the fact
that the 10% is accurate!

Consider, for a moment, what it would be like if the typical
"progress bar + estimated time remaining" *pair* of (concurrent)
indicators were swapped.  Typically the progress bar slowly
(perhaps erratically) increases and the ETA display bounces
around as time estimates are updated.  Instead, imagine the
numeric value shows the "percent complete" (i.e. replaces
the progress bar... constantly increases!) and the progress
bar depicting the estimate of remaining time (i.e., one second
it's a short bar, then it's a LONG bar, then it's somewhere in
the middle, etc.)

[sorry, I have not expressed this well... but, if you think about
it, I think you'll see the example I am trying to illustrate]

I.e., if the *current* type of indicator usage had swapped the
"% complete" and "time remaining" roles (graphically/digitally),
I think you would be very distressed watching that bar animation
bounce all over the place!

:-/

Grrrr....