[kde-guidelines] Styleguide: Progress indicator

[Thomas Pfeiffer]

On Monday 08 July 2013 15:35:08 Heiko Tietze wrote:
> System triggered notification
> * Show a progress indicator for lengthy actions.
> 
> http://techbase.kde.org/Projects/Usability/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.

I don't think the word "contentual" exists. What did you mean?

> * 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).

I'm not sure what you mean by "waiting bar". You mean the one that looks like 
a progress bar but just continuously moves to show that the application does 
not know when it's finished?
I agree that those are bad for the user experience, but we need to suggest an 
alternative for when we can't really tell the progress because we don't know 
the overall amount of work yet (i think vastly inaccurate progress bars are 
even worse than "waiting bars").
Do you know a better way to visualize an indefinite busy state?

> * Don't combine a progress bar with a busy pointer.

I'm fine with all the rest.