Microsoft-ui-xaml: Proposal: Add a non Indeterminate mode to Progress Ring.

Created on 12 May 2019  路  8Comments  路  Source: microsoft/microsoft-ui-xaml

Proposal: Add a determinate mode to the ProgressRing control

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

Summary

The ProgressBar control has both a determinate mode with a min/max/accurate value - as well as an animated indeterminate mode. The ProgressRing currently only has an indeterminate mode, and there is no determinate mode for this control.

Rationale

Ring indicators for Progress are used in many different systems. Xbox makes use of this type of display throughout the apps and Shell UI. Windows 8 and Windows Phone also used these types of controls. The ProgressBar control has an IsIndeterminate property and can be used to indicate either indeterminate and determinate progress. Why not the ProgressRing as well? It will help app developers who want to indicate determinate progress with a Ring.

Scope

| Capability | Priority |
|:--|:-:|
| Value and IsIndeterminate properties (aligns with ProgressBar) | Must |
| Aligned for use in other Microsoft products and reflects new designs | Should |
| Add DisplayValue (value is shown as text inside the Ring) | Could |
| RingThickness (the width and height would not alter the thickness as it gets bigger or smaller) | Could |
| StartingAngle (so you can choose where the ring starts to fill from) | Could |

Important Notes

image

image

image

image

image

image

Open Questions

1) There seem to be three styles of progress bar/ring designs in use by Microsoft at present. Perhaps one of these should become cannonical, and all three meet to match each other?

Progress controls (both ProgressRing and ProgressBar) will be evaluated for style updates to align across Microsoft.

image

image

Xbox - Fabric - Fluent/Win10

2) Should a non indeterminate mode for Progress Ring support segmented storage/progress?

Showing segmented storage is a charting control, not a progress control, and not within the use case for the ProgressRing control.

Possible scenario: showing different sections of a program being installed (the core program, assets, etc)

image

image
Example visualization from @mdtauk :
image

area-Progress feature proposal needs-winui-3 team-Controls

Most helpful comment

Thank you @mdtauk for the thoughtful proposal and @mrlacey for your helpful comments! I am focusing on F# support for the next few days but really appreciate all your contributions! Should it be a "non-indeterminate" mode, or a "determinate" mode?

@kathyang At the moment the ProgressBar has an InDeterminate property which is set to False by default, and switches to a looping animation when set to True

Ideally I would think it should match the ProgressBar exactly.

So a default mode with a value that moves from 0 to the max value. This would be translated to an angle from 0 to 360 degrees.

Then when the IsIndeterminate value is set to True, then the control's animation will play.

By the nature of the control, there may need to be properties for the Starting Angle and Ring Thickness.

All 8 comments

Note, the Community Toolkit already has a RadialProgressBar that can do most of what is described above.

@mrlacey I am aware of that control, but come WinUI 3.0 this whole project takes on a broader scope and bigger scale of changes will be possible. Should this not just be the default control, with both indeterminate and radial progress all together, as it is with the ProgressBar?

Perhaps even add Multiple Value properties to both bars to enable scenarios like:
image

image

It is a question of should ProgressRing and ProgressBar have feature parity, but just be different forms.

@mdtauk I was trying to fill out this proposal by highlighting more of what's currently possible/available.

When you get into controls supporting multiple values you get into the realm of graphing/charting. This makes it more about than parity between two controls and adding potentially complex new functionality.

By bringing ProgressRing and ProgressBar into parity, the difference just becomes one being a circle and one being a line. This could mean the only difference between them is a rotational transform. At that point, could they be one control with a property to indicate shape? (line or circle)

It would be good to have this conversation informed with the rational behind the original creation of the two different controls. I assume that ProgressBar was designed for flexibility and ProgressBar was created as a separate control to make a common, simple scenario easy to implement. The need to balance theses differing needs and requirements must not be overlooked when considering any changes here.

@mrlacey I agree that there is a fine line between charting and progress, so keeping it to a single value probably makes the most sense.

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?

But if there is a reason to combine Indeterminate states into the Progress Bar, but not the Progress Ring - I would be interested in hearing it.

Thank you @mdtauk for the thoughtful proposal and @mrlacey for your helpful comments! I am focusing on F# support for the next few days but really appreciate all your contributions! Should it be a "non-indeterminate" mode, or a "determinate" mode?

Thank you @mdtauk for the thoughtful proposal and @mrlacey for your helpful comments! I am focusing on F# support for the next few days but really appreciate all your contributions! Should it be a "non-indeterminate" mode, or a "determinate" mode?

@kathyang At the moment the ProgressBar has an InDeterminate property which is set to False by default, and switches to a looping animation when set to True

Ideally I would think it should match the ProgressBar exactly.

So a default mode with a value that moves from 0 to the max value. This would be translated to an angle from 0 to 360 degrees.

Then when the IsIndeterminate value is set to True, then the control's animation will play.

By the nature of the control, there may need to be properties for the Starting Angle and Ring Thickness.

@mdtauk I definitely agree with you that an InDeterminate property should match the behavior in ProgressBar.

I've created a new issue #880 to discuss progress in general - for ProgressRing, ProgressBar, and any other progress scenarios. I'd love to hear everyone's thoughts on progress controls there!

Thank you everyone for your help with this, I've started the spec here and the PR is here. I'd love to keep getting your thoughtful contributions and feedback on the spec!

Was this page helpful?
0 / 5 - 0 ratings