Microsoft-ui-xaml: Progress - Story and Guidance

[kathyang]

There is an open spec here and PR here for this.

See the proposal for adding a determinate state for ProgressRing in #688. (Also relevant is updating ProgressRing style #837 )

The ProgressBar and ProgressRing controls provide visual indicators to users that something is happening. To quote from the Progress Controls Guide:

The ProgressBar determinate state shows the percentage completed of a task. This should be used during an operation whose duration is known, but it's progress should not block the user's interaction with the app.
The ProgressBar indeterminate state shows that an operation is underway, does not block user interaction with the app, and its completion time is unknown.
The ProgressRing only has an indeterminate state, and should be used when any further user interaction is blocked until the operation has completed.
Additionally, a progress control is read only, and not interactive. Meaning that the user cannot invoke or use these controls directly.

I'm exploring areas we can improve our progress controls by modifying existing controls or developing new ones. @mdtauk has noted the use for adding a determinate (or non-indeterminate) state for ProgressRing in #688. (Also relevant is updating ProgressRing style #837 )

Are there other scenarios that our progress controls are missing?

Important Notes and Open Questions

• Lack of guidance for ShowError and ShowPaused states

• Lack of support and/or guidance for situations where Progress is very short (200 ms to 800 ms) - quoted from @xyzzer:

  In past Windows UI design guidelines - there were recommendations for when to do nothing, when to show an hourglass/spinner cursor and when to show a larger progress UI...suggesting is to have a setting in the control that makes it so that when you set it to be active - it remains invisible for the first half second to a second and then it fades in if it's still set as active, so that when an operation it represents is quick - users don't see the indicator blinking in and out for sub-second operations. If it already takes longer than that time - it's also more likely to take much longer, so it should have time to fade in and out. This makes the UI seem less glitchy.

• Is it possible to integrate a Progress control with the task bar icon?
  

[kathyang]

@mdtauk said the following over in #688 :

It would be good for the design process and rationale to be more open, especially when UWP joins WPF and WinForms as open source presentation platforms. Could the community update the default styles and templates for WPF and WinForms controls to bring them in line with Fabric Web perhaps?

And I am also in favour of taking a look at the disparate expressions of Fluent design which currently exists, and try to unify them in an open discursive and collaborative process.

You could have a ProgressControl with a Shape property and an enum ProgressShape.Ring, ProgressShape.Bar as well as Indeterminate property, and possibly even include paused and error states as is present in WPF.

Why have a Fabric Spinner, an Xbox Spinner, and the Windows dotted ProgressRing - all looking different, but doing the same thing?

Why do the different Progress Bar Indeterminate states have different animations?

[mdtauk]

WPF and I believe Windows Vista onwards had a Paused and Error state for their Progress Bars.

The WinRT control has ShowError and ShowPaused properties still, but I've not seen any guidance as to how those states should look.

[xyzzer]

It would be nice to be able to easily integrate a progress control with the task bar icon's state/progress indicators.
It would also be nice to have an option for delayed show, perhaps with a fade in animation, where an indicator would stay invisible even in active state until a certain delay (e.g. 1s), so that for short burst operations the progress UI wouldn't blink.
At one time I was also looking into creating a smart (perhaps AI-backed) progress bar control that would be able to collect statistical data about progress events to reason about expected duration of an operation based on past experience and the timing of data points from a current operation...

[mdtauk]

Not sure if this is a Progress control, or if it needs to be a new one, whilst matching the visual style of the Progress controls:

[kathyang]

It would be nice to be able to easily integrate a progress control with the task bar icon's state/progress indicators.
It would also be nice to have an option for delayed show, perhaps with a fade in animation, where an indicator would stay invisible even in active state until a certain delay (e.g. 1s), so that for short burst operations the progress UI wouldn't blink.

@xyzzer I'm not quiet sure I get what you're saying, could you elaborate more on what you mean? My current understanding is: 1) Have a progress control replace the task bar icon (i.e. a ProgressRing instead of the icon) and 2) delay before a ProgressRing/ProgressBar appears "so that for short burst operations the progress UI wouldn't blink". I'm having trouble understanding the scenarios you're describing for both points - I look forward to your clarification!

@mdtauk Someone else also brought up storage controls as a potential scenario! I will definitely discuss this with our team. Thank you for making the graphics! May I add them to the proposal to show our team?

[mdtauk]

@kathyang Any images I post can be used, I am happy to contribute!

---

As for the Taskbar progress, this was introduced in Vista and Win 7

[xyzzer]

@kathyang

@xyzzer I'm not quiet sure I get what you're saying, could you elaborate more on what you mean? My current understanding is: 1) Have a progress control replace the task bar icon (i.e. a ProgressRing instead of the icon)

What @mdtauk said. Have a switch on the control that will make its progress/indeterminate values correlate with the task bar icon values. Not sure if it's feasible without OS-level changes - do UWAs have access to the task bar APIs (other than jump lists)? Can they interact with it when they're not an active/forward window?

2) delay before a ProgressRing/ProgressBar appears "so that for short burst operations the progress UI wouldn't blink". I'm having trouble understanding the scenarios you're describing for both points - I look forward to your clarification!

So, in many if not most use cases, the progress indicator is only displayed while it's also active, but sometimes the operation it's associated with might only last 200ms or 800ms which would otherwise lead to the control quickly blinking in and out of view looking more like a glitch. In past Windows UI design guidelines - there were recommendations for when to do nothing, when to show an hourglass/spinner cursor and when to show a larger progress UI. The current ones aren't as specific, although they do also mention the cursor (you might also consider integrating with that)! The idea I was suggesting is to have a setting in the control that makes it so that when you set it to be active - it remains invisible for the first half second to a second and then it fades in if it's still set as active, so that when an operation it represents is quick - users don't see the indicator blinking in and out for sub-second operations. If it already takes longer than that time - it's also more likely to take much longer, so it should have time to fade in and out. This makes the UI seem less glitchy.

[Poopooracoocoo]

@xyzzer

You may want to fix the formatting of your comment.

[kathyang]

Thank you everyone for your help with this, I've started the spec for Progress controls updates (including guidance for different states and modes) here and the PR is here. I'd love to keep getting your thoughtful contributions and feedback on the spec!