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. Kirk On Sat, 2005-04-02 at 15:13 +0200, Diego Moya wrote: > On Apr 2, 2005 2:43 PM, Age Bosma <[EMAIL PROTECTED]> wrote: > > > You've got a point though some programs do tend to use multiple progress > > bars. Should this be something to address in the HIG with e.g. one or > > two examples to prevent people from using multiple progress bars? > > Would it be possible to recommend this in general in the first place? > > Personally I can't think of a reason why multiple progress bars are > > realy needed if you use your example but others might think of situation > > where it would be handy to use. > > The Synaptic package manager does this - but it download packages in > parallel not in sequence, and the multiple bars are folded under an > advanced "more info" panel. > > The Firefox download manager is another example of multiple progress > bars, and here there isn't a global progress. The common theme where > multiple progress bars seems to be legitimate is when there are > several independent processes. > > I agree that when there is one single process with several sequential > components, a single bar and a % text for the component is simple and > clear. > _______________________________________________ > Usability mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/usability _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
