views:

773

answers:

6

In this particular situation, there are 9 automated steps in a process that take varying lengths of time. We currently have a number showing percentage in the center of a progress bar, but it suffers from the common stop-and-go problem of racing up to 33%, waiting a long time, racing up to 55%, waiting an even longer time, then finishing.

What's the best way to present this to the user? Should we remove the number, remove the whole progress bar in favor of an ajax-type circle animation, add descriptive text for the nine steps and checking them off or leave it the way it is? What are your thoughts?

+3  A: 

If it really takes a long time, AJAX type of animation is probably not a good idea. I'd go with checklist of items.

Milan Babuškov
I agree, if you don't have many steps, show the user the steps your doing. Don't give them the false idea that a lot is going on under the hood and they'll get a lot of feed back when they won't.
Miles
+1, agreed. Show the user the steps, perhaps with an animated GIF of a spinner next to the currently active one. (And other visual feedback -- maybe finished tasks are green and ones not yet begun are gray.)
John Rudy
+2  A: 

The progress bar serves to reassure the user that something is going on. When you do not have a more detailed list of steps, I would recommend 'faking' them.

A basic solution would be to run a timer and slowly increase the progress, capping it at the next logic step value. If the steps take wildly different amounts of time, you can manually adjust the delta value for every timer 'tick' depending in which step you're in.

However, a better solution (I once implemented it this way, but I cannot post the code :)), would be to slowly decrease the delta as the step continues -- so it never quite makes it to the next step. Then the next step arrives, you have a nice jump and the cycle repeats.

+1  A: 

In some cases it's more important for a progress bar to indicate that something is happening than for it to be accurate and smooth. Users tend to panic when progress bars stop progressing.

If you have problems with the bar freezing for periods of time, it might be better to replace it with a generic animation that reassures the user that something is happening without worrying about showing how far along the process is. Or, leave the progress bar in place, but add some additional animation as a placebo.

Kluge
A: 

I had almost the exact same problem. We also had 9 steps, so the bar would go 11%, 22% 33% etc. and also with some steps taking longer than others.

I decided to make two of the longer steps count as two, so we how had 11 steps, so it wasn't as obvious, and the jumps weren't always even: 9%, 18%, 36%, 45%, 54%, 72%, 81%, 90%, done. The step values were always the same, but since the size of the step wasn't obvious, it worked..

James Curran
+1  A: 

If you're interested, here is a very interesting article on user perception of progress bars. Made me think a little bit about it:

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

Cassy
+1  A: 

To expand Cadet Pirx's answer, here's some WinForms C# code. You'll need a new UserControl. Put a ProgressBar control on it, called inner. Add the following code:

public partial class ZenoProgressBar : UserControl
{
    private const int DEFAULT_FACTOR_VALUE = 10;
    private const int DEFAULT_MAXIMUM_VALUE = 100;

    public ZenoProgressBar()
    {
        InitializeComponent();

        Maximum = DEFAULT_MAXIMUM_VALUE;
        Factor = DEFAULT_FACTOR_VALUE;
    }

    /// <summary>
    /// The "speed" of the progress bar. While it will never get to
    /// the end, it uses this number to decide how much further to
    /// go each time Increment is called. For example, setting it to
    /// 2 causes half of the remaining distance to be covered.
    /// </summary>
    [DefaultValue(DEFAULT_FACTOR_VALUE)]
    public int Factor { get; set; }

    [DefaultValue(DEFAULT_MAXIMUM_VALUE)]
    public int Maximum { get; set; }

    private void ZenoProgressBar_Load(object sender, EventArgs e)
    {
        inner.Dock = DockStyle.Fill;
    }

    public void Increment()
    {
        inner.Value += (inner.Maximum - inner.Value) / Factor;
    }
}
Roger Lipscombe