Guidelines and checklist for progress controls (Windows Store apps)

Article
01/07/2014

We describe best practices for using progress controls in your Windows Store app using C++, C#, or Visual Basic.

Roadmap: How does this topic relate to others? See:

Is this the right control?

The ProgressBar and ProgressRing controls shows users the progress of an operation that takes more than 2 seconds to complete. A ProgressBar can show an approximate percentage of completion (determinate progress), and both progress controls can indicate that an operation is ongoing (indeterminate progress).

It's not always necessary to show a progress control. Sometimes a task's progress is obvious enough on it's own or the task completes so quickly that showing a progress control would be distracting. Here are some points to consider when determining whether you should show a progress control.

Will the operation complete in about two seconds or less?

If so, don't show a progress control. If an operation takes more than two seconds to complete most (but not all of) the time, wait 500ms before showing the control to avoid flickering.
Is the operation waiting for the user to complete a task?

If so, don't use a progress bar. Progress bars are for computer progress, not user progress.
Does the user need to know that something is happening?

For example, if the app is downloading something in the background, and the user didn’t initiate the download, the user doesn’t need to track its progress.
Is the operation a background activity that doesn't block user activity and is of minimal (but still some) interest to the user?

Use text and ellipses when your app is performing tasks that don't have to be visible all the time, but you still need to show the status.

Use the ellipses to indicate that the task is ongoing. If there are multiple tasks or items, you can indicate the number of remaining tasks. When all tasks complete, dismiss the indicator.
Can you use the content from the operation to visualize progress?

If so, don't show a progress control. For example, when displaying images loaded from the disk, images appear on the screen one-by-one as they are loaded. Displaying a progress control would provide no benefit; it would just clutter the UI.

Don't use the "wait cursor" to indicate activity, because users who use touch to interact with the system won't see it, and those users who use mouse don't need two ways to visualize activity (the cursor and the progress control).

Choosing the right type of progress control style

There are 3 progress control styles:

The determinate progress bar style

Use the determinate progress bar style when a task is determinate. that is when it has a well-defined duration or a predictable end,. Here are some examples of determinate tasks:
- The app is downloading a 500k photo and has received 100k so far.
- The app is displaying a 15 second advertisement and 2 seconds have elapsed.
The indeterminate progress bar style

Use this style for tasks that are not determinate and are non-modal (don't block user interaction).
The indeterminate progress ring style

Use this style for tasks that are not determinate and are modal (block user interaction).

Treat partially modal tasks as non-modal. Some tasks block interaction until some progress has been made, and then the user can start interacting with the app again. For example, when the user performs a search query, interaction is blocked until the first result is displayed. Treat tasks such as these as non-modal and use the indeterminate progress bar style if the modal state lasts less than 2 seconds. If modal state can last more than 2 seconds, use the indeterminate progress ring for the modal phase of the task, and use the indeterminate progress bar for the non-modal phase.

General guidelines

Here are some general guidelines to follow, regardless of which progress control style you use.

Show a single progress control for multiple active related tasks. If there are multiple related items on the screen that are all simultaneously performing some kind of activity, don't show multiple progress controls. Instead, show one that ends when the last task completes. For example, if the app downloads multiple photos, show a single progress control, instead of showing one for every photo.
Don't change the location or size of the progress control while the task is running.

Guidelines for determinate tasks

If you can estimate remaining amount of work in time, bytes, files, or some other quantifiable units of measure, use a determinate progress bar. Here are some guidelines for using the determinate progress bar.

Switching from indeterminate to determinate If some time (or action) is needed to start providing determinate progress, use the indeterminate bar first, and then switch to the determinate bar. For example, if the first step of a download task is connecting to a server, you can’t estimate how long that takes. After the connection is established, switch to the determinate progress bar to show the download progress. Keep progress bar in exactly the same place, and of the same size after the switch.
Showing progress and status inline Suppose you have a list of items, such as a list of printers, and certain actions can initiate an operation on items in that list (such as installing a driver for one of the printers). When this happens and the operation is determinate, show a determinate progress bar next to the item. Show the subject (label) of the task above the progress bar and status underneath. Don’t provide status text if what's happening is obvious. After the task completes, hide the progress bar. Use the status text to communicate the new state of an item.
Showing multiple operations When you want to show a list of tasks, align the content in a grid so users can see the status at a glance. Show progress bars for all items, even those that are pending. Because the purpose of this list is to show ongoing operations, remove operations from the list when they complete.
Showing app-modal determinate progress in the app bar If a user-initiated a task from the app bar and it blocks user interaction, show the progress control in the app bar. If it's clear what the progress bar is showing progress for, you can align the progress bar to the top of the app bar and omit the label and status; otherwise, provide a label and status text. Disable interaction during the task by disabling controls in the app bar and ignoring input in the content area.

Do's and don'ts for determinate tasks

Do	If the operation is modal (blocks user interaction), and takes longer than 10 seconds, provide a way to cancel it.
	Space progress updates evenly. Avoid situations where progress increases to over 80% and then stops for a long period of time. You want to speed up progress towards the end, not slow it down. Avoid drastic jumps, such as from 0% to 90%.
	After setting progress to 100%, wait until the determinate progress bar finishes animating before hiding it.
	If your task is stopped (by a user or an external condition), but the user can resume it, visually indicate that progress is paused by setting the ShowPaused property to true. Provide status text under the progress bar that tells the user what's going on.
	If the task is stopped and can’t be resumed or has to be restarted from scratch, visually indicate that there's an error by setting the ShowError property to true. Replace the status text (underneath the bar) with a message that tells the user what happened and how to fix the issue (if possible).

Don't	Don’t decrement progress. Always increment the progress value. If you need to reverse an action, show the progress of reversal as you would show progress of any other action.
Don’t restart progress (from 100% to 0%), unless it’s obvious to the user that a current step or task is not the last one. For example, suppose a task has two parts: downloading some data, and then processing and displaying the data. After the download is complete, reset the progress bar to 0% and begin showing the data processing progress. If it’s unclear to users that there are multiple steps in a task, collapse the tasks into a single 0-100% scale and update status text as you move from one task to the next.

Don't

Don’t decrement progress. Always increment the progress value. If you need to reverse an action, show the progress of reversal as you would show progress of any other action.

Don’t restart progress (from 100% to 0%), unless it’s obvious to the user that a current step or task is not the last one. For example, suppose a task has two parts: downloading some data, and then processing and displaying the data. After the download is complete, reset the progress bar to 0% and begin showing the data processing progress. If it’s unclear to users that there are multiple steps in a task, collapse the tasks into a single 0-100% scale and update status text as you move from one task to the next.

Guidelines for indeterminate tasks

If the task is modal, that is it blocks interaction until its completion, use the indeterminate progress ring style. If the task is not modal, use the indeterminate progress bar style.

Indeterminate progress ring

Follow these guidelines for displaying the progress ring:

Display the progress ring in the context of the action: show it near the location where the user initiated the action or where the resulting data will display.
Provide status text to the right of the progress ring.
Make the progress ring the same color as its status text.
Disable controls that the user shouldn’t interact with while the task is running.
If the task results in an error, hide the progress indicator and status text and display an error message in their place.

Here are some guidelines for specific situations involving the progress ring.

In a dialog, an action occurs before we move to the next screen Place the progress ring just above the button area, left-aligned with the content of the dialog.
Showing progress in an app window with right-aligned controls Place the progress ring to the left, or just above, the control that caused the action. Left-align the progress ring with related content.
Showing progress in an app window with left-aligned controls If a control that starts the modal action is aligned to the left, place the progress ring to the right of that control. Or you can place it underneath the control.	- or -
Showing progress in a flyout Use a flyout if activity can proceed in the background when the user dismisses the flyout by tapping outside it.
Showing multiple items Place the progress ring and status text underneath the title of the item. If an error occurs, replace the progress ring and status with error text.

Indeterminate progress bar

Use an indeterminate progress bar for tasks that don't block user interaction (non-modal).

Here are some guidelines for specific indeterminate progress bar situations..

Showing progress in a flyout Place the indeterminate progress bar at the top of the flyout and set its width so that it spans the entire flyout. This placement minimizes distraction but still communicates ongoing activity. Don't give the flyout a title, because a title prevents you from placing the progress bar at the top of the flyout.
In an app window Place the indeterminate progress bar at the very top of the app window, spanning the entire window.

Guidelines for status text

When you use the determinate progress bar, don’t show the progress percentage in the status text. The control already provides that info.
If you use text to indicate activity without a progress control, use ellipses to convey that the activity is ongoing.
If you use a progress control, don't use ellipses in your status text, because the progress control already indicates that the operation is ongoing.