Progress/Status Indicator Usage Guideline 
RCUX Document Version 5.0.2 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (11.1.1.2.0)
Last Updated
25-Jan-2011
Progress indicators and messages inform users about the status of a process.
Note: Images in this guideline are provided as a general reference, and may not be exact representations of FusionFX pages.
Related Guidelines
| Guideline | Section | For Information About |
|---|---|---|
| Language in UI | All | General directions for writing message text. |
| Message Framework | All | Error, Warning, and Confirmation messages may be associated with processing. |
Related ADF Elements
Refer to the ADF Faces Rich Client demos page to find demos and tag documentation for the ADF elements related to this component:
| ADF Element | Notes |
|---|---|
| af:progressIndicator | Displays the progress indicator that is used in processing dialogs. |
| af:statusIndicator | Displays a page status indicator. |
General Principles
Purpose:
Inform users about the status of a process.
Description:
- Progress indicators and messages appear when users start an action that requires a noticeable amount of time for the system to complete.
- When a process is started, applications can provide information about that process using one of the following methods:
- Page Status Indicator: For brief processes only.
- Processing Dialog: For longer processes.
Page Status Indicator
Processing Dialog with Progress Indicator
Processing Dialog with Progress Bar
Usage:
- Progress indicators and processing dialogs do not appear unless specified by product teams.
- Progress indicators and processing dialogs should be used primarily for processes that interrupt the user's task flow, such as a delay while fetching data or writing data to a database.
- Processing dialogs should conform to both FusionFX and your corporate guidelines. See the Message Framework guideline for details.
Note: Some applications can perform long background processes on the server without interrupting the user's work. Such background processes provide status within application pages and do not use FusionFX processing dialogs or page status indicators.
Page Status Indicators
Purpose:
Indicate that a process is running.
Description:
- A page status indicator consists of an icon in the top right corner of the page (top left in right-to-left languages). The icon is animated while the process is occurring.
- There are two status options for a page status indicator: Busy or Idle. The Busy indicator appears when data is being fetched, retrieved, or processed. The Idle indicator appears whenever the page is not fetching, retrieving, or processing data.
Page Status Indicator
| Busy Icon | Idle Icon |
|---|---|
 |
 |
Usage:
- A Busy page status indicator should be used for very short processes—usually between one and five seconds. Page status indicators are also recommended for processes of five to ten seconds in high-productivity applications, where it is necessary to reduce the distraction of additional dialog boxes.
- A Busy page status indicator may be followed by a Confirmation message when users need confirmation that a process is completed. In this case, it is recommended to display the Confirmation message in a message box instead of a dialog. See Confirmation Messages in the Message Framework guideline for details.
- When a Busy page status indicator appears and the user is blocked from performing any action, product teams should change the mouse pointer to indicate that actions are unavailable.
- Page status indicators are also used on read-only pages that display active data. See Active Data in the Table Elements guideline for details.
Processing Dialogs
Note: ADF provides progress indicators for use in processing dialogs, but product teams must implement the dialogs themselves.
Purpose:
Draw the user's attention to the process that is running.
Description:
- The Processing dialog is a specific type of dialog (see Dialogs in the Secondary Windows guideline) that provides an indication of where a process is within its cycle.
- Processing dialogs contain both messages and visual indicators of process status. Processing dialogs have three types of indicators and associated text depending on the type of process:
- Indeterminate Processing: The length of the process cannot be determined, or is short.
- Determinate Processing: The length of the process can be estimated.
- Checklist Processing: A long process can be divided into meaningful steps.
- After initiation of the process, a Processing dialog may become a Message dialog with a corresponding change of icon and dialog title (see Message List Dialog in the Messaging guideline):
- On successful completion: an Information or Confirmation message dialog
- On error: an Error message dialog
- On warning: a Warning message dialog
- If a message requires a user response (for example, to give the user the option of continuing the process despite an error or warning), the product team may launch a modal message dialog on top of the processing dialog.
- When a modeless processing dialog is displayed, navigating to another page or closing the browser cancels the process. Product teams should display a warning dialog to the user before allowing the process to be cancelled.
Note: Developers can get a warning dialog automatically by setting the uncommittedDataWarning flag on af:document.
Progress Message Examples:
- Your report is printing.
- The system is updating your information.
- Your credit status is being verified.
- Your request is being processed.
Usage:
- Processing dialogs should be reserved for processes that require at least five seconds to complete, to inform the user that the process is running.
- Processing dialogs should be used instead of other kinds of feedback, such as page status indicators and pointer changes, when users are performing high priority tasks that require both clear feedback that the process is proceeding correctly and confirmation when it is completed.
- For example, when a user submits a high priority report for review, and the scope of the submission requires processing time, the employee should receive both visual feedback that the submission is in progress and confirmation when the submission is completed.
- If the user has the option to cancel the process, provide a Cancel button.
- Processing dialogs can be modal or modeless:
- When users are blocked from performing any action until the process is completed, use a modal processing dialog.
- When users can continue to perform actions on the page, use a modeless processing dialog. If they are engaged in a high priority task, use a modeless processing dialog which switches to a Confirmation message dialog upon completion.
- By default, the size of the dialog message region is 340 pixels x 125 pixels. When the content within the message region exceeds the width and height of the message region, the content scrolls.
- When developing progress message text, product teams should refer to the specific messaging guidelines for their company.
Indeterminate Processing Dialog
Purpose:
Draw the user's attention to a process of undetermined length.
Description:
- An indeterminate processing dialog displays message text and an animated progress indicator while a process is running.
- The indicator has two states: "In Progress" and "Finished".
Indeterminate Processing Dialog
Usage:
- Display an indeterminate processing dialog in the following contexts:
- When the system cannot calculate approximately how much progress has taken place, nor how much is remaining. If it is possible to make even a rough time estimate, use a Determinate Processing dialog instead.
- For relatively short processes—between 5 and 10 seconds—when other page status indicators are not available. See Summary of Processing Options below.
- When the user is blocked from performing other actions until the process is complete, product teams should change the pointer to indicate that other actions are not permitted.
Indeterminate Processing Dialog Showing Completed Process
Determinate Processing Dialog
Purpose:
Draw the user's attention to a process with a length that can be estimated.
Description:
- A determinate processing dialog displays message text and a progress bar while a process is running.
- The completion status is shown in a tooltip when the user moves the mouse over the progress bar.
Usage:
- Display a determinate processing dialog when the system can calculate how much progress has taken place, or how much is remaining.
- A determinate processing dialog is preferred for longer processes if duration can be roughly calculated. See Summary of Processing Options below.
- Product teams configure the refresh frequency and completion percentage of the progress indicator. By default, completion percentage refreshes in 5% increments.
- Product teams should supply detailed message text below the progress bar to provide real time updates on the process. Common progress text includes:
- "{ObjectType} {Action}: n of n" (such as, "Files Downloaded: 1 of 10" or "Records Transferred: 2 of 1000")
- Percentage complete (such as, "20% complete," "5% processed," "98% downloaded")
- Time remaining (such as, "2 minutes, 35 seconds remaining").
- If it is also possible to divide a long process into meaningful steps, it is recommended to use a Checklist Processing dialog instead of a determinate processing dialog.
Determinate Processing Dialog Showing Detailed Message Text
Checklist Processing Dialog
Purpose:
Draw the user's attention to a long process that can be divided into multiple steps.
Description:
- A checklist processing dialog displays a list of steps preceded by status icons while a process is running.
- The status icons indicate the state of each step as the process continues:
- In Progress
- Complete
- Error
Checklist Processing Dialog
Usage:
- Use a checklist processing dialog when all of the following conditions occur:
- A process is expected to be longer than 30 seconds.
- The process can be divided into steps that are generally meaningful to the user. For example, a list of database-related steps would be meaningful to a database administrator, but not to the average application user. Ideally, steps should be structured so that each step takes a similar amount of time to complete.
- Checklists should list all steps when the dialog is loaded.
- The checklist processing dialog should contain a progress bar unless the list of steps exceeds the height of the dialog message region. The progress bar shows completion status for the entire process, not for each step (step completion status is provided by the status icons).
Summary of Processing Options
It is strongly recommended to use a processing dialog when a process is expected to exceed 10 seconds. Processing dialog options are as follows:
- If the system can provide a rough estimate of process length, use a Determinate Processing Dialog.
- If the system cannot estimate process length, use an Indeterminate Processing Dialog.
- If the process can be divided into steps that are generally meaningful to the user, use a Checklist Processing Dialog.
- See Processing Dialogs for general usage information applicable to all three dialogs.
The choice of processing methods depends on the length of the process, whether the user is blocked from further actions, and whether the application design allows for the option of page status indicators. The following decision table summarizes the recommended methods:
| Duration | User Action Blocked | Page Status Indicators? | Display Method |
|---|---|---|---|
| 1 - 5 seconds | Yes | Yes | Page Status Indicator plus pointer feedback |
| Yes | No | Pointer feedback only | |
| No | Yes | Page Status Indicator only | |
| No | No | Modeless Processing Dialog | |
| 5 - 10 seconds | Yes | Yes | Page Status Indicator plus pointer feedback |
| Yes | No | Modal Processing Dialog | |
| No | Yes | Page Status Indicator only | |
| No | No | Modeless Processing Dialog | |
| >10 seconds | Yes | Modal Processing Dialog | |
| No | Modeless Processing Dialog |
Note: All processing methods should be combined with a Confirmation message when users require confirmation that a process is completed. See Confirmation Messages in the Message Framework guideline for details.
