×
Namespaces

Variants
Actions
(Difference between revisions)

Mobile Design Pattern: Progress and Wait Indicator

From Nokia Developer Wiki
Jump to: navigation, search
Larry101 (Talk | contribs)
hamishwillee (Talk | contribs)
m (Hamishwillee - Bot update - Fix ArticleMetaData and RevieweApproval)
Line 1: Line 1:
{{ReviewerApproved}}
+
{{ArticleMetaData <!-- v1.1 -->
[[Category:Mobile_Design]]
+
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
[[Category:Mobile_Design_Patterns]]
+
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Qt SDK 1.1.4]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|id= <!-- Article Id (Knowledge base articles only) -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20090506
 +
|author= [[User:Yiibu]]
 +
}}
 +
 
 +
[[Category:Mobile Design]]
 +
[[Category:Mobile Design Patterns]]
  
 
This design pattern is part of the [[:Category:Mobile Design Patterns|Mobile Design Patterns]] series.
 
This design pattern is part of the [[:Category:Mobile Design Patterns|Mobile Design Patterns]] series.

Revision as of 03:11, 10 February 2012

Article Metadata
Article
Created: User:Yiibu (06 May 2009)
Last edited: hamishwillee (10 Feb 2012)

This design pattern is part of the Mobile Design Patterns series.

Contents

Description

Indicators used to represent an active process. A progress indicator indicates the progression of a task, while a wait indicator simply indicates that a process (of undetermined length) is still ongoing.


32-progress-wait.jpg

Figure: Some typical wait and loading indicators.

Advantages

  • Even if the task is fairly short, providing such an indicator can be helpful to reassure the user that something is happening. On mobile devices, the fact that network connectivity may fluctuate makes this even more important, as what may initially appear to be a short task may suddenly last longer if connectivity fluctuates.
  • These indicators also provide excellent cues that other processes may degrade while the current process is ongoing.

Disadvantages

  • On a small screen, it can be tricky to find adequate space for these indicators. They are however too important to omit.

Use when

Progress indicator

  • A process is expected to be time consuming (i.e. last more than 2-4 seconds).
  • The system can calculate (with a reasonable degree of accuracy) how far the task has progressed.
  • It is best practice to display progress indicators in conjunction with a Cancel command. This enables the user to manually abort the task if needed.

Wait indicator

  • A process is expected to be time consuming (i.e. last more than 2-4 seconds) however its duration and progress cannot be calculated.
  • It is best practice to display wait indicators in conjunction with a Cancel command. This enables the user to manually abort the task if needed.
  • The most common use of this indicator on mobile is to indicate the loading of as-yet undetermined amounts of data from the network i.e. downloading emails, web feeds etc.

Use how

Progress indicator

  • Clearly indicate what process is underway ex. ‘Downloading nokia.sis’
  • Use animation to show the actual progress.
  • Provide additional visual cues where possible, for example:
    • Number of kilobytes uploaded or downloaded.
    • Number of files uploaded or downloaded if there are multiples.
    • Percentage of the task expended or (if known), the amount of time or data remaining.
  • Provide the user with an easily discoverable means to cancel the operation.

Wait indicator

  • Clearly indicate what process is underway ex. ‘Installing nokia.sis’
  • Use a simple, looping animation to clarify that the process is ongoing. While this does not provide actual progress, it increases confidence that things are behaving as planned.
  • Provide the user with an easily discoverable means to cancel the operation. This is particularly important in the case of wait animations, as the user has no idea how long the process will take. If the action times out, the system should (ideally) provide some indication of this however if a crash occurs, the animation may sadly keep looping indefinitely until the user cancels the action manually. Note: The later is not an ideal scenario but is nonetheless a very common one.
  • Even if there is not enough data available to display a formal progress indicator, it can still be quite useful to display related information. Ex. Displaying the number of kilobytes downloaded even if the full amount is not known still provides the user with an idea of the potential data costs and an opportunity to abort if necessary.

Note: Both indicators can be presented inline or within a modal dialogue. If the task is particularly long and/or is not expected to monopolize other processes, it can be useful to allow the user to hide the dialogue while they continue to use the application. In this case, an easily discoverable mechanism should be provided to show the indicator once again.

Design Tips

  • Where possible, position the indicator close to the process it is clarifying.
  • Wait and progress indicators are often displayed in a modal view which has full focus during the operation. This is often simply due to the type of action that is being indicated ex. A download or an installation. Consider what actions will be monitored with the indicators you provide and whether they would benefit from retaining focus while the task is completed.
  • Display the Cancel command close to the progress or wait indicator and ensure that the manipulation model is clear i.e. must the user navigate to the command? Will doing so remove focus from the wait or progress animation? Will a loss of focus matter?
  • Wait indicators can be quite creative, as they simply need to imply an ongoing process. Progress indicators are somewhat more constrained by the need to clearly visualize progress however they can still take on a variety of interesting shapes and metaphors.


33-fun-progress.jpg

Figure: The Nokia VINE progress bar is simple yet informative and engaging.

41 page views in the last 30 days.
×