views:

31

answers:

3

I'm wondering it this is a really bad usability idea, so I'm open to feedback.

I need to perform two steps on a large number of items, with step 2 starting any time after step 1 has completed. However, Step 1 for Item 2 can begin any time after Step 1/Item 1 has finished, and even while step 2/Item 1 is going on.

Is a multi-segment progress bar a bad idea for the consumer? For example (what I'm picturing), the following form would display that step 1 has been done on 75% of items, but step 2 has only been performed on 50% (I intended the brown to be blue or something nicer, but couldn't get it right in my photo editor).

Unified Progressbar

The way I was considering doing it before was this, but I don't know if that's more of less clear to the end user, since the activity timeframe of the bars is overlapping:

alt text

Any feedback on which makes more sense to the user? If the first image is better, is there a control out there that does this?

+1  A: 

I like option 2. I see some installer programs like that, so it's not unheard of...

And the visual is always nice.

Edit - added

Just for fun, I found this paper on the progress bar and user perception....

http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf

David Stratton
+3  A: 

Does the user actually care when step 1 completes? If step 2 always comes after step 1, can you not just display the progress bar for step 2 and not worry about displaying the progress of step 1 at all? The work is only "complete" when step 2 finishes anyway...

Alternatively, you could combine the progress bar into one. Just double the total number of "items" to process and increment the progress bar once when step one completes and once more when step 2 completes.

Unless I misunderstood something...

Dean Harding
I hadn't considered either of these options, actually - steps 1 and 2 will always need to be performed on all items, so I could easily double the number of steps in the progressbar and then just increment it any time either step finishes. Perhaps this is the most accurate way to display progress to the user.
rwmnau
+1: Agreeed, Step 2 is the most important, so there is no need for Step 1 reporting.
AMissico
"Perhaps this is the most accurate way to display progress to the user." Yes.
AMissico
+1, agreed. Don't expose your programming problems to the user. She won't give a hoot.
Hans Passant
Since step 2 can be significantly slower than step 1, I'll just end up displaying a progress bar for step 2 instead of one that's combined. Thanks for your input - I'm sure it will make a more straightforward summary for the user.
rwmnau
+1  A: 

You have two operations going on in parallel, then? Option (2) sounds the simplest to implement, although a little confusing for the user (exactly how close is it to finishing?).

I guess that performing step 1 decides what work there is to do on step 2. You could display a single progress readout, from 0 to 100%, that reflects the total of steps 1 and 2: however, when you start adding the work for step 2, you could see the progress go backwards.

I would first try to determine all the work that has to be done -- that is, all the work involved in step 1 and step 2 -- and use that to calibrate a single progress bar accurately. Then, display a single progress readout that starts on the first item of step 1, and finishes on the last item of step 2.

Tim Robinson