Java TM Look and Feel Design Guidelines: Advanced Topics > Part II: Special Topics > 6: Responsiveness > Providing Operational Feedback   Previous Next Contents/Index/Search


Providing Operational Feedback

Responsive applications provide feedback--including visual feedback--about the state of operations in progress. This section describes:

  • How to decide whether to provide feedback for an operation
  • Which types of visual feedback you can provide
  • How to choose the correct type of visual feedback

For general information on how to provide operational feedback in your application, see Chapter 6 of Java Look and Feel Design Guidelines , 2d ed. Also see that chapter for general information about pointer feedback.

Deciding Whether to Provide Feedback

Whether your application should provide feedback on an operation depends on how long that operation usually takes.

 To decide whether to provide feedback on an operation, test how long the operation usually takes on the minimum system configuration that your application supports. Repeat the test at least 10 times, with different data sets or network loads. Provide feedback if the operation takes longer than 1 second in at least 10% of the tests.

Types of Visual Feedback

You can use two types of visual feedback for operations in your application-- pointer feedback and progress animations:

  • Pointer feedback changes the shape of the pointer. (The pointer tracks movements of the user's mouse or other pointing device). For example, a wait pointer indicates that an operation is in progress and that the user cannot do other tasks.
  • Progress animations show either:
  • How much of an operation is complete
  • Only that an operation is ongoing (such animations are also known as "status animations")

Progress Animations

To provide feedback with a progress animation, an application can display a progress bar or a progress checklist.

  • A progress bar shows how much of the operation is complete (a  measured-progress bar) or only that the operation is ongoing (an  indeterminate-progress bar). Measured- and Indeterminate-Progress Bars describes each type of progress bar in detail.
  • A progress checklist shows the sequence of stages in an operation but does not display time estimates for those stages.


NOTE ¯ Except where noted, the term "progress bars" refers to measured-progress bars.

Figure 63 shows a progress bar in a wizard page.

Figure 63   Progress Bar (in a Wizard Page)


Figure 64 shows a progress checklist, also in a wizard page.

Figure 64   Progress Checklist (in a Wizard Page)


Figure 65 shows an indeterminate-progress bar. (For information about wizards, see Chapter 7 . For information about feedback in wizards, see "Providing Operational Feedback in Wizards" on page 147.)

Figure 65   Indeterminate-Progress Bar


When providing feedback with a progress checklist, you can include a measured-progress bar directly below the checklist. The bar measures the progress of the current step in the progress checklist.

When displaying a progress animation, your application should open it as quickly as possible and close it automatically as soon as the associated operation is complete.

 When providing a progress animation, use a measured-progress bar if your application can estimate either:

  • How long the operation will take
  • What proportion of the operation is complete

If your application can make neither estimate, use an indeterminate-progress bar for operations with only one step. For operations with two or more steps, use a progress checklist that dynamically displays a check mark for each completed step.

 Ensure that a measured-progress bar measures an operation's total time or total work, not just that of a single step. An exception is a progress bar that measures the total time or work of the current step in a progress checklist.

Measured- and Indeterminate-Progress Bars

You can use two main types of progress bars in your application--measured-progress bars and indeterminate-progress bars. Measured-progress bars can be classified into the following types:

  • Time-remaining bars
  • Proportion-completed bars
  • Typical-time bars

There is only one type of indeterminate-progress bar.

Table 14 describes each type of progress bar.


Type of Progress Bar Description


An animation consisting of:


  • A bar whose changing length indicates how much time remains in an operation.


  • Text stating how much time remains before the operation will be complete.

Time-remaining bars are the most useful type of progress bar. Figure 63 shows a time-remaining bar.


A bar whose changing length represents the completed proportion--typically a percentage--of an operation's total units of work.

Proportion-completed bars are less useful than time-remaining bars but more useful than typical-time bars.


A bar whose changing length indicates how much time remains if an operation takes as long as it typically does.

Typical-time bars are the least precise type of measured-progress bar, but they are more useful than indeterminate-progress bars.


An animated bar indicating only that an operation is ongoing.

Indeterminate-progress bars are the least precise type of progress bar. Figure 65 shows an indeterminate-progress bar.

The correct type of bar to use depends on how precisely your application can estimate the duration of the operation in progress.

Progress Bars for More Predictable Durations

If your application can estimate how long a particular instance of an operation will take, you can provide feedback with one the following types of progress bar:

  • A time-remaining bar
  • A proportion-completed bar

You can use a time-remaining bar if your application will display an initial estimate of an operation's remaining time and then periodically display updated estimates. Each updated estimate should be based on changes that have occurred and that will cause the operation to finish more quickly or more slowly. If the operation will finish more slowly, your application can display an updated estimate that is greater than the estimate previously displayed.

You can use a proportion-completed bar if your application will estimate an operation's duration by counting the units of work completed so far, without regard for changes that might affect how quickly the remaining units will be completed. If the operation will process a known number of objects or a set of objects whose total size is known, equate the length of the bar to the total number of units of work that the operation will perform. At least every four seconds, update the bar to show how much of the operation is complete.

Progress Bars for Less Predictable Durations

For some operations, you cannot estimate the time remaining or the proportion of work completed. However, if you can estimate the typical time for that operation, you can provide feedback with a typical-time bar.

If your application overestimates the completed amount of work, the length of the bar can indicate "almost complete" until the operation is complete. If your application underestimates how much work is complete, the application can fill the remaining portion of the bar when the operation is complete.

You can use an indeterminate-progress bar to provide feedback on an operation whose duration you cannot estimate at all.

For general information about progress bars, see Chapter 6 of Java Look and Feel Design Guidelines , 2d ed.

 Use the most precise type of progress bar for the operation that you are timing. For a list and description of types, see Table 14.

Providing the Correct Type of Visual Feedback

To determine which type of visual feedback to provide for a particular operation, consider these factors:

  • Whether your application can provide an estimate of the operation's progress.
  • Whether the operation blocks the user from issuing further commands in your application.
  • Whether your application has a dedicated space--such as an area at the bottom of a window--for indicating the status of operations.

Table 15 shows which type of feedback your application should provide for operations that usually take at least 1 second to finish. In Table 15:

  • Internal progress animations are progress animations displayed in an application's dedicated status area.
  • External progress animations are progress animations displayed somewhere other than in a dedicated status area--typically, in an alert box.


    Current operation usually takes less than 5 seconds? User blocked from issuing further commands? Application has dedicated area to show status? Appropriate feedback
    for current operation

    Internal progress animation and pointer feedback


    Pointer feedback


    Internal progress animation



    Best provided by adding a status area.


    Internal progress animation and pointer feedback



    External progress animation and pointer feedback



    Internal progress animation




    External progress animation

     When providing feedback for operations that take at least one second, follow the rules in Table 15.

     Use a wait pointer in your user interface whenever users are blocked from interaction with your application for 1 second or longer. Display the wait pointer in less than 1 second.

    Letting Users Stop Commands in Progress

    Users sometimes need to stop a command--for example, because it is taking too long. Your application should let users stop commands in progress--even if stopping a command cannot undo, or "roll back," all the command's effects.

    To let users stop a command, place a Stop button near the progress animation for that command. (For more information, see Progress Animations.) Alternatively, you can place the Stop button near the user-interface control with which the user issued the command that needs to be stopped. Place the Stop button in this alternative location only if either:

    • There is no progress animation for command.
    • The progress animation is in a window's status area or in another location that lacks space for a Stop button.

    If a user clicks the Stop button, the effect should depend on whether terminating a command can have unwanted consequences--also known as "side effects"--such as an incomplete rollback of changes.

    Table 16 describes how to decide the correct behavior for the Stop button.


    Table 16   Correct Behavior for a Stop Button That Stops a Command
    Will terminating
    the command have
    unwanted consequences?
    Clicking the Stop button


    Immediately terminate the command.


    Open an alert box that warns of potential side effects. The alert box should have only two buttons:


    • A button for continuing the command's processing, canceling the request to terminate it


    • A button for immediately terminating the command's processing, despite potential side effects

    If clicking the Stop button opens an alert box, the button labels of the alert box should be specific and precise. Ambiguous button labels can cause users to terminate or continue a command unintentionally.

    Figure 66 shows an alert box for terminating a command.

    Figure 66   Alert Box for Terminating a Command


     If a command will likely take 10 seconds or longer to finish, provide a Stop button that lets users terminate the command's processing--even if your application cannot undo the command's effects.

     If stopping a partially completed command will not undo all the command's effects, display an alert box to warn users. Ensure that the alert box includes two buttons that enable users to choose between continuing the partially completed command or terminating the command regardless of the side effects. Label each button of the alert box as specifically as possible, for example: Continue Deleting Files and Stop Deleting Files.

    Java Look and Feel Design Guidelines: Advanced Topics.
    Copyright 2001. Sun Microsystems, Inc. All Rights Reserved.
    Previous Next Contents/Index/Search
    Table 15   Visual Feedback Types for Operations That Take at Least 1 Second 
Table 14   Types of Measured- and Indeterminate-Progress Bars 
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
Java 8 banner (182)