[Tfug] Progress indicators

[Bexley Hall]

Hi, Paul,

> Progress indicators should have one main purpose that
> should not be lost. That being that it indicates progress. I

Yes.  But, progress indicators not only indicate how far you
have *come*... but, also, how far you have yet to go!
Yes, they provide some reassurance that progress *is*
being made... but, I suspect people subconciously look
at the "right side" and watch to see how much it is *shrinking*
rather than how much the left side is *growing*.

E.g., the progress bar that IE displays is silly.  It keeps
creeping along as if progress was actually being made -- when,
in reality, it is just *waiting* for a reply from the site
(i.e., the processor could just as easily be HALTED and
"as much" progress would be made).  This is a great example
of the spinning indicator in another guise (watch the network
activity indicator, instead, to see if anything is *really*
happening!)

> have seen some very clever ones and some really stupid ones.
> The worst ones are those that indicate progress of each task
> and not the over all. You see this little blue bar zip to
> the end quickly, seemingly hundreds of times, giving you no

Right.  It just shows that the processor hasn't crashed.  :<
I think part of the problem is developers fail to take a
look at the whole "process" (activity?) to determine how best
to indicate progress.  It's just much "easier" to show the
progress of some trivial little *component* in that process...

> real information. Even the bars that are inconsistent in the
> speed at which it reflects completeness are better than
> those.
> 
> The most clever I have seen was actually done by Microsoft
> in the install of Age of Empires. They had some little
> fellows with hammers building a wall or castle or something
> and it was cool to watch. When the edifice was finally
> erected, the program was installed. Probably overkill but
> still it was interesting enough to make an impression and
> cause me to comment positively on something that Microsoft
> did.

But, this would quickly get boring.  Soon, you'd start looking
carefully at all their "activity" and notice they're moving
around a lot but no bricks are getting laid...  like an hourglass
that is continuously dripping sand, while no sand actually
*accumulates* in the lower half of the hourglass!  :<
 
> The done vs. remains is a not answerable for everybody.
> Some like to see progress, others like to know how much is
> left. To meet the needs of both whatever progress meter you
> design should have a visual means to determine both. An
> example might be a graphical representation of two buckets.
> A character walks between them with a dipper carrying bits
> from one bucket to the other. I can ether watch one bucket
> dran and see progress or watch the other fill to visually
> note how much is left until it is full.

But, this still sidesteps the issue of all those "trips"
where no *real* work was accomplished.  E.g., no water
*actually* removed from bucket A nor deposited in bucket B.
I.e., you might as well have the guy sit down and start
drinking "cartoon coffee".

Note that I am not saying that the process is *stalled*
(which is what the coffee break would imply).  Rather,
that progress *is* being made but it is at a slow enough
pace as to render this particular choice of illustration
ineffective.  (e.g., MS's "flying paper" to show file
transfer progress... lots of paper flying but very
little *progress* shown)
 
> I do prefer the meters that travel at a steady rate. I can
> see where this might be difficult to actually accomplish but
> still it is my preference.
> 
> I am not a minimalist. There is a certain "class"
> and "professional polish" that should be applied
> to any product that goes to market. The fancy graphics may
> seem like a huge waste of time but they usually offer the
> first impressions of the product. If I see a blank screen
> with a twirler in the middle I wonder if that same laziness

Exactly.

> pervades the whole product. If I see something that shows
> skill, polish and artistic talent during an install, I
> expect good things to follow. It is the way the brain works;
> especially for the average non-technical user.
> 
> The visual paradigm would change once the application is
> running, though. If you are writing an FTP client you need
> your status meter to be useful and a natural addition to the
> visual art and appeal of the application.The buckets example
> above would be difficult to do right in this scenario.

I'm just trying to assess psychological needs on the user's
part.  How those metrics are conveyed to the user can vary
(though the more consistent the presentation, the more
accepted, in general -- principle of least surprise)
 
> If you are going to use a plain old standard, progress bar
> then it does not really matter if it fills left to right or
> right to left or bottom to top or any other direction so
> long as it is obvious where you are at and that it
> represents the progress of the complete task.

--don