Proposal: Form Control Styles - Consistent to Fluent UI and FastDNA (Xbox too?)

[mdtauk]

Proposal: Form Control Styles - Consistent to Fluent UI and FastDNA

Summary

As requested by @chigy this is a proposal to introduce some kind of FormControlStyle property to relevant controls, which enables the developer to set the visual look of their Form Controls from a set of known and approved designs which align to Fluent UI and FastDNA concepts of button types - without manually overriding or setting Xaml Styles - which would lead to inconsistent variations,

image is an example of how the controls would look in these initial 4 styles

Rationale

• Microsoft's other UI platforms have not agreed and aligned to a single pure spec for these control designs, and some offer various button types, where only the visual design is different, but functionally identical - this would allow different design expressions, without duplication.
• It would address some of the concerns that have been expressed about the new direction the controls have moved towards with Windows 10X, and trying to make the controls align closer to other design systems for other platforms - these alternative designs are currently in use with other UI frameworks influenced by the Fluent Design System.
• It could potentially allow for easy style replacements by device type for Xbox styled controls, or for apps running as a GameBar widget - without having to dynamically load in ResourceDictionaries which could be a performance hit.

Scope

Capability	Priority
The alternative styles would meet accessibility concerns and be approved by Microsoft Design teams	Must
Windows 10X Shell and Inbox apps which currently roll their own styles should move to setting this API as best practice	Should
Whilst not in the forefront of my mind, there could be some kind of extensibility so a developer could create their own styles (Xamarin with Material Design perhaps)	Could
The addition of this property or enum should not break existing apps	Won't

Important Notes

An initial thought would be some kind of enum which when set, will apply the alternative style to the control, and this could possibly be done at the App level, or inherited from a containing panel or page, as well as on an individual control. If that container panel also contains controls where this property does not apply, those controls should appear as normal.

public enum FormControlStyle
{
      Accent,
      Filled,
      Outlined,
      Ghost,
//    TenFoot
}

<Button Content="Button text" 
        FormControlStyle="Outlined"
        Width="240" Height="32" />

Open Questions

The easier it is to set this style, the better it will be for developers who would rather not re-template controls just to make a slight change based on preferences - but this could also be done with ResourceDictionaries. If that approach is taken, then ensuring those can be created by Microsoft and distributed in some way, with plenty of exposure - is the only way I can think of to try to maintain consistency.

Also I am not sure about using the word Style in the property name, as it could be confusing with the existing Style property. So deciding on what these "alternatives" should be referred to would need to be decided on.

The idea is the key thing, the implementation is up to the community and the WinUI team.

Related Issues

• Proposal: Define and implement distinct button styles, outline, fill, and ghost #1054 Proposal: Define and implement distinct button styles, outline, fill, and ghost
• Feature Proposal: Form Control #82 Feature Proposal: Form Control
• Discussion: More default and consistent button styles? #2233 Discussion: More default and consistent button styles?
• Inconsistent design with native controls #2092 Inconsistent design with native controls
• New standard styles for system controls is a step back #1258 New standard styles for system controls is a step back
• Proposal: Default button concept #930 Proposal: Default button concept
• Discussion: Xbox Next: Will it use XAML, should WinUI 3.0 have built in support for templates and styles? #698 Discussion: Xbox Next: Will it use XAML, should WinUI 3.0 have built in support for templates and styles?

[Felix-Dev]

@mdtauk +1 For including a RadioButton OutlineStyle alone.

[mdtauk]

@mdtauk +1 For including a RadioButton OutlineStyle alone.

Knew you'd like that. 😃

With the ghost style I was thinking of the ToggleMenuFlyoutItem and RadioMenuFlyout which enable selection, whilst not including the unselected visual.

[niels9001]

Thanks for the writing up the proposal! My only concern is with the ghost variants of the radiobutton and checkbox: removing the borders are a pretty big usability flaw IMO. I think those need to stay because the controls are now pretty much unrecognizable.

[mdtauk]

I did place a dot where the mark should be, but it is also possible that there is another way to handle the indicators there, or just not have the ghost style apply to them.

[niels9001]

I did place a dot where the mark should be, but it is also possible that there is another way to handle the indicators there, or just not have the ghost style apply to them.

I'd go for the latter, so that the controls are still recognizable as a CheckBox/RadioButton.

[mdtauk]

I did place a dot where the mark should be, but it is also possible that there is another way to handle the indicators there, or just not have the ghost style apply to them.

I'd go for the latter, so that the controls are still recognizable as a CheckBox/RadioButton.

Maybe these designs are subtle enough to be considered ghost or stealthy.

20% Opacity for the borders at rest
40% when checked or three-state

60% opacity for the marks inside

[marcelwgn]

Using the colors in your screenshot, on a white background, you are unfortunately not meeting common contrast ratios such as WCAG AA for controls (20%) and for normal text(20%,40%). I am not sure if that is fine, but I would tend to, it's not enough contrast. The problem is that contrast and "stealthiness" are opposing each others, so it's a very difficult decision to make here.

[chigy]

Using the colors in your screenshot, on a white background, you are unfortunately not meeting common contrast ratios such as WCAG AA for controls (20%) and for normal text(20%,40%). I am not sure if that is fine, but I would tend to, it's not enough contrast. The problem is that contrast and "stealthiness" are opposing each others, so it's a very difficult decision to make here.

@chingucoding is correct. Many of the controls do look like they are not meeting contrast requirements and it is something we need to ensure.

[mdtauk]

Using the colors in your screenshot, on a white background, you are unfortunately not meeting common contrast ratios such as WCAG AA for controls (20%) and for normal text(20%,40%). I am not sure if that is fine, but I would tend to, it's not enough contrast. The problem is that contrast and "stealthiness" are opposing each others, so it's a very difficult decision to make here.

@chingucoding is correct. Many of the controls do look like they are not meeting contrast requirements and it is something we need to ensure.

It is only the Ghost radio and checkboxes that are not meeting the requirement I think. The Outlined ones are based on the TextBoxes, so 40% border and 40% fill. The Filled controls are based on the button, so a 20% fill.

[dongle-the-gadget]

Some accent button style API samples:

Determining foreground:
(5 * <green value> + 2 * <red value> + <blue value>) <= 8 * 128 ? Colors.White : Colors.Black

Button style:
<Style TargetType="Button" x:Key="AccentButtonStyle"> <Setter Property="Background" Value="{ThemeResource SystemAccentColor}"/> <Setter Property="Foreground" Value="{ThemeResource SystemAccentForeground}"/> </Style>