Pattern 48: Sense of progress
AKA:

Back to Diagram 1 - Getting started Back to Diagram 2 - Useability Back to Diagram 3 - Adding detail Back to Diagram 4 - Workflow/security

View sensitizing image - Sysiphus tbd

Because of the need for FEEDBACK (41) and NO UNPLEASANT SURPRISES (46), we need to feed back to users the level of achievement of their goals and, indeed, ours.

In particular, web users are often unaware of

This may lead them to making errors with dire, or at least irritating, consequences. These will mean they will probably not become RETURN VISITORS (68).

Therefore

Make sure that a sensible indicator of commitment/rollback is displayed prominently.
Identify all the steps needed to achieve a goal and provide a visual indication of:


Consider that a transaction may, at least in the mind of the user, span more than one visit to the site. In that case use RETURN VISITOR (68) and CACHE TRANSACTIONS (67). Remember to SUPPORT COLOUR WITH SPATIAL METAPHOR (69). On workflow sites use PIPELINE INTERACTION (78).

Contributors and sources
Chris Simons


Discussion - forces - known uses

The interface should provide a sense of progress. Feedback is needed for this because effects can be thus related to causes and allows the user to see if the results of each step are contributing to the overall task. Slow tasks or network delays should be made visible in this way, so that the user can tell if the system has really crashed or is just plain slow. Changing the mouse pointer to an hour glass is a helpful and often used technique but one can still wonder whether the system has hung. Providing an estimate of the anticipated time in the form of a gauge is useful in such contexts.

Web technology presents content one page at a time, unlike a book where we can flick through the pages to gauge progress. Steps need not be linear. Any order may be appropriate.

Feedback on progress through a task is needed because effects can be thus related to causes. It allows the user to see if the results of each step are contributing to the task in hand. Slow tasks or network delays should be made visible in this way, so that the user can tell if the system has really crashed or is just plain slow. Changing the mouse pointer to an hour glass is a helpful and often used technique but one can still wonder whether the system has hung. Providing an estimate of the anticipated time in the form of a gauge or progress bar is useful in such contexts.

Examples
Putting labels on pages detailing both the current step and the total number of steps, as in Figure 48.1. Using a progress bar or gauge graphic and/or hour glass cursor to indicate progress of retrieval of a page or other item.

One bank labels sequential screens with ‘Stage n’ but fails to indicate which stages cause irrevocable commitment to be made. You commit at stage 3 but it doesn’t tell you this until Stage 7. Woe!

Figure 48.1 Label pages [refer to book]

In linear, stateless solutions (such as credit card payment for the contents of shopping basket) one may

  1. provide card number and expiry date;
  2. display the total due and the payment date(s);
  3. provide confirmation of payment;
  4. if confirmed, commit the payment transaction and confirm its completion (perhaps by email as well).

Non-linear, stative solutions (such as filling in a household insurance proposal form) may use visual techniques such as check boxes, traffic lights (and other ways to SUPPORT COLOUR WITH SPATIAL METAPHOR (69)) and so on.

Browse the language What is Wu? Look at an example pattern sequence Structure of the patterns
Comment on Wu Contributors Return to TriReme home page Links to related sites