Re: [Usability] Progress Bars

[Kirk Bridger <kbridger shaw ca>]

Thanks for the reply Ross,

The exact situation on my machine is that I have two optical drives - a
DVD and an HP burner.  If I try to rip using cdparanoia a CD with some
types of copy protection (such as Air's Talkie Walkie), the progress of
the rip is different depending on the drive I use.

My DVD will simply slow down to a non-moving crawl (or so it seems).  I
left it for an hour or so and the progress in cdparanoia showed no
change on the command line - well almost no change.

If I use the HP burner, it rips, albeit slowly.  The entire disk takes
an hour or so.

A non-protected disk is ripped in my DVD in about 5 minutes usually.

So if we remove the individual progress bars, the single progress bar
may not have enough fidelity to let me know that I should switch drives
to get a faster rip.

So you see, the individual track rip progress bars are very handy in
some situation.

I suppose I should adjust my example then and say that individual
progress bars are useful when the user needs to know when in a series of
actions a failure occurs, provided the combined progress bar does not
have enough fidelity to convey that info?

Of course I may be approaching "unique user" status, and can suffer with
a stiff upper lip if nobody else thinks my point is valid in any other
situations.



On Wed, 2005-04-06 at 09:41 +0100, Ross Burton wrote:
> On Tue, 2005-04-05 at 21:21 -0700, Kirk Bridger wrote:
> > I'm thinking of at least one situation where a single progress bar would
> > not be sufficient - when the user needs to know at which point along the
> > way something failed during a series of actions.
> > 
> > For example, in Sound-Juicer, while ripping a series of songs, I want to
> > be able to see the progress of each song.  This way, if there is a
> > failure (or a slowdown due to copy protection schemes) I can see exactly
> > where along the series of steps the failure occurred.
> > 
> > This could also be covered by having SJ provide this info to the user
> > upon failure, but this reduces it to a binary state - working or not.  I
> > think the granularity of seeing the individual tasks in the series
> > should not be removed.
> 
> If there is a *failure* to rip a disk, SJ should move to the next song
> bring up a dialogue at the end telling the user what songs failed (I'm
> not sure this happens). Ripping speed reducing is a fact of life and
> will be ignored, as it could be caused by a scratch, the computer
> shaking, or copy protection.
> 
> The irony here is that currently SJ does have two progress bars, but I
> plan on removing one of them for G2.12.
> 
> Ross