|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| __NOTOC__
| | {{ Moved To Community | KDE_Visual_Design_Group/HIG/ProgressIndicator }} |
| | |
| == Purpose ==
| |
| If a foreground task lasts longer than expected or when calculation takes some time a feedback on progress should be given by the system. Users are aware of response times of over one second and shorter. Consequently, operations that take two seconds or longer to complete should be considered to be lengthy and need of some type of progress feedback. But even in cases of short delays the user should be assured that the system is not hung or waiting for user input. Such a feedback is done by changing the mouse cursor to a ''busy pointer'' (aka Throbber). When operation lasts longer the user should be able to anticipate when it’s finished. The appropriate graphical control for this task is a ''progress bar''.
| |
| | |
| == Examples ==
| |
| | |
| == Guidelines ==
| |
| * Provide progress feedback when performing a lengthy operation. Users should never have to guess if progress is being made.
| |
| * Start with a busy pointer when the operation takes longer than 500 ms and show a progress bar in case of 5 seconds or more.
| |
| * User should be able to pause and cancel operations which last very long.
| |
| * Consider to move very long lasting operations to the background and notify on completion only.
| |
| * Clearly indicate real progress – and lack of progress. The progress bar must advance if progress is being made and not advance if no progress is being made.
| |
| * Show progress regarding contentual steps.
| |
| * Provide additional progress information, but only if users can do something with it, e.g. cancel the processing, relate an error to a particular processing step, etc. Don't provide unnecessary details.
| |
| * Don't use waiting bars (aka marquee style).
| |
| * Don't combine a progress bar with a busy pointer.
| |
| | |
| == Implementation ==
| |
Latest revision as of 11:26, 4 August 2016
