Progress Windows

A progress window can be used to provide feedback during an operation that takes more than a few seconds. See Section 6.17 ― Progress Bars for more details about proper use of progress bars.

A progress window should always appear as an independent window in a window list. If progress of a task makes a window temporarily unusable, do not present a modal dialog-like progress window in front of it. Instead, present progress somewhere in the original window, making all its other elements temporarily insensitive. This helps reduce visual clutter.

Figure 3-19 An example of a progress window
Title Format

Progress windows should have a title representing the overall operation: for example Copying Files, Installing, or Calling. As with other window titles, do not end progress window titles with an ellipsis.

Resizing

Progress windows should be resizable if they contain non-static information the user may want to copy (for example, the source URL in a download progress window). Otherwise they should not be resizable.

Guidelines
  • It is often better to use the progress bar contained in many primary windows' statusbar rather than a progress window. See Section 7.4.2.1.1 ― Progress Windows vs. the Statusbar for details on choosing between the two.
  • Progress windows should use primary and secondary text like an alert. See Section 3.4.1 ― Alert Text
  • The progress bar text should provide an idea of how much work has been completed. It is better to provide specific information rather than a unitless percentage. For example, "13 of 19 images rotated" or "12.1 of 30 MB downloaded" rather than "13% complete".
  • If possible, an estimate of the time left until the operation is complete should also be included in the progress bar text. Indicate that the "time left" is an estimate using the word "about".
  • Immediately beneath the progress bar, place italicized text indicating the current sub-operation being performed. This might be a step in a sequence, "Contacting control tower for permission to land", or it could be the current object being operated on in a bulk operation, "Rotating MonaLisa.png", "Rotating StarryNight.png".
  • If the operation in progress is potentially hazardous (destructive, costly, etc) or heavily taxes a limited resource for more than ten seconds (network bandwidth, hard disk, CPU, etc), consider placing a Pause toggle button to the right of the Cancel button. When paused, the italicized current sub-operation text should have " (Paused)" appended. This will allow users to perform important tasks requiring that resource, or give them time to think whether they want to procede with a dangerous operation they inadvertantly triggered.
Figure 3-20 A progress window for a file copy operation

3.5.1. Checklist Windows

Occasionally a procedure is comprised of a series of user performable actions. In these cases, particularly when it is desirable that the user acquire some familiarity with the actions involved in a procedure, checklist windows may be used.

Example 3-4 Firewall Setup Wizard

A personal firewall setup wizard might install the firewall package, add entries for the firewall to /etc/xinetd.conf, restart the internet super-daemon, and configure the user's web browser to operate through the firewall. It may be desirable that the user is exposed the series of actions involved in setting up the firewall to increase the chances that they will be sucessful in making modifications later, if they so desire.

Figure 3-21 An example checklist window (Ready to Start)
Figure 3-22 An example checklist window (In Progress)
Figure 3-23 An example checklist window (Completed)
Guidelines
  • If knowing the series of steps in an operation isn't that useful to the user, just use a regular progress window. Remember that you are probably more interested in the information than most users, many of whom will find the technical steps confusing rather than helpful.
  • Unlike regular progress windows, checklist windows should not close automatically when the operation is complete and should require explicit user input before they begin. This is because one of their purposes is to inform the user concerning an operation's contingent steps.
  • The progress bar indicates progress in the overall operation, not each step. While this is more difficult to program, it is the information most useful to the user. Just estimate how long each of the steps takes relative to each other and assign each step a fixed ratio of the progress bar's progress accordingly.
  • Do not use a checklist window for a series of internal programmatic steps, use a regular progress window. For example "Connect to mail server", "Authenticate with mail server", "Download messages", "Disconnect" would not be an appropriate series of steps for a checklist window, but would be appropriate sub-operation steps for a regular progress window.
Alerts Dialogs

About