Showing progress for a long many-step process with a discrete progress bar?

Question

I've got a desktop-focused web application where the user is going to be initiating tasks that take a long time. Sometimes, these tasks will take hours to complete (users don't have to do anything other than wait for the job to complete). I'm trying to figure out what's going to be the most effective way to show the task's progress.

It's going to be technically infeasible to show a traditional continuous file-copy style progress bar with an overall estimated time to completion. There are defined steps in each task, but each step could take massively different amounts of time to complete - some maybe a couple of seconds, some maybe 45 minutes. Just because you're on step 40 of 50 doesn't mean you're 80% done time-wise.

So, I'm wondering if it makes sense to break the progress bar into discrete increments. Maybe a non-continuous progress bar would avoid giving people the wrong impression about the task's progress? Something like this:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Does this seem like a reasonable solution? Or just by looking like a progress bar, is that enough to make people think that halfway through the bar means they are halfway to completion?

Would it be more effective to list "Step 30/50" in text somewhere?

Answer 1

A progress bar should be an indication of how far the process is. If someone sees a progress bar 50% complete, they are most likely going to assume that it is half way done.

In your situation, that is not the case, so you should avoid using a progress bar, unless you have some way of pre calculating approximately how long each process will take. In that case show an approximation of the progress in time.

I would suggest you explain that it may take a long time, and show an indicator that the process is still running (a time counter may be fine for this). Then give the the information in steps and give some short description of what the step is.

Here is a rough mockup of what I would suggest - the design could do with some work:

Answer 2

If you know generally which steps take longer, then you can still use a progress bar, just make sure each of the steps has a section proportional to approximately how long the step will take.

Dominos Pizza tracking app does a good job of showing which steps take longer than others, as you can clearly see, step five can be up to 1/3 of the total time.

The pizza tracker also flashes on the section being completed, it shows an uncertainty as to how much longer that step will take, while still being in an active state.

Answer 3

What information is your user wanting to know? Do they want to know how complete the job is or do they want to know when it will be done?

If the user's expectation is that the interface will tell them how long it will take, then give them information about the time elapsed and use the progress bar to indicate elapsed versus average. Rather than a segmented progress bar using tasks as the unit, use time, since that is what the user is trying to find.

If time is not something you can accurately estimate, then I would not reference time at all. Rather, focus on the steps. Your example does this well if you removed the time label.

However if you are able to give time approximations, then it would be helpful to provide that information with appropriate context so that it is meaningful to the user:

^{download bmml source – Wireframes created with Balsamiq Mockups}

In short: determine the unit of measure that is more important/useful to the user, and design the interface to clearly communicate status in that unit.

Try to not mix your units as that can create confusion as the user questions whether they truly know what the system status is.

Answer 4

Based on your example, you can tell how much time each individual step will take, correct? If so, then I think I agree with you and would suggest a structure like this:

Step 30/50 | Reticulating splines (est 8:47 remaining)

Time spent on total task: 47:52 (est 1:25:00 remaining)

Give the user what step they are on, the name of that step, and how long the step will take to complete. Nearby I would have an indicator of the total time the task has taken so far, and if you can give a time based estimate to task completion there I would.

In the end all the user wants to know is how long a task is going to take. It doesn't matter if it is a bar, a clock, or list of steps. (Personally, the bar is always my least favorite option as a user.)