New standard styles for system controls is a step back

[jp-weber]

Describe the bug
With version 2.2 some controls have deteriorated in appearance and operation. For example the button is bad in visibility due to the change, if the user hover over the control (dark theme without active transparency). #1171

Expected behavior
In all themes and VisualStates, the control element must be good visible and be operable.

Screenshots
For example the radio button:
standard

new

Why RadioButtonBorderThemeThickness = 1?

Version Info
NuGet package version: 2.2.190830001

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2019 Update (18362)	Yes
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Mobile
Xbox
Surface Hub
IoT

Additional context

[Felix-Dev]

Previous radio button design looked so much more familiar...the new look doesn't even come close to the familiar radio button style in win32 controls/Windows:

New Style:

Win10:

Windows Vista:

Win2000:

The design of radio buttons having an "inner dot" to indicate selection status is well-known among (seasoned) Windows users. This new styling doesn't even have this inner dot any longer. It bears no real resemblence to the well-known radio button style established since at least Windows 2000. I would have strongly hoped that the Microsoft Design Team would have respected 20+ years of Windows UI history in this new design and not axe the familiar inner dot. Alas....radio buttons had to be radically redesigned 😥
@chigy

[mdtauk]

Regarding the button in Dark Theme, I believe it should lighten when you hover on it, and darken in it's Pressed state

---

Mac OS and Ubuntu uses this Filled when Active approach, and it matches the new Checkbox control design

Android uses a fill for it's checkboxes, but an outline for it's Radio Button

I think the effort should be in moving the old Win32/WPF designs to the new control designs, rather than being "held back" by the past.

But if there are usability concerns, they should be investigated.

[Felix-Dev]

@adrientetar Care to explain your reason for the down vote? On Windows, isn't respecting familiar Windows UI design proven over decades a good thing? @mdtauk mentions Mac and Ubuntu featuring the new design. But these are different platforms. They are not Windows. Why is it perhaps more important to align with those "outsider" UI rather than with the established & proven Windows UI people grew up with?

[adrientetar]

@Felix-Dev C'est non.

[mdtauk]

... @mdtauk mentions Mac and Ubuntu featuring the new design. But these are different platforms. They are not Windows. Why is it perhaps more important to align with those "outsider" UI rather than with the established & proven Windows UI people grew up with?

• Partly for familiarity for users of multiple devices, coming to Windows for the first time.
• Familiarity of developers who are needed to bring in cross platform apps for Windows.
• Cleaner designs (which can be used for Win32 and WPF in future updates.
• Preparing for the new Modern versions of Windows, for new devices, with new Shell designs.

My personal opinon is that these new designs are not any less usable, and if TextBoxes, and Pickers are moving to 1px borders, having the Radio Buttons not match, would be a bigger problem.

I also am in favour of extending the Button styles of Outlined, and Filled, to all controls, so that would offer both styles.

[Felix-Dev]

* Partly for familiarity for users of multiple devices, coming to Windows for the first time.

* Familiarity of developers who are needed to bring in cross platform apps for Windows.

@mdtauk
Based on your screenshot showing the most-used consumer OS besides Windows is also using the classic Windows Radio Button design (at least inner dot) then there is all the more reason to keep the new design as similar as possible. After all, Android is by far the most used mobile consumer OS out there and it's market share is only growing.

My personal opinon is that these new designs are not any less usable, and if TextBoxes, and Pickers are moving to 1px borders, having the Radio Buttons not match, would be a bigger problem.

It's not about less usable. The old design was proven over decades and does the job perfectly. I don't see how the new design brings advantages to the table (see above: Android vs rest of mobile platforms). You could still change the border if that is absolutely necessary but otherwise keep the inner dot. Familiarity with Windows UI should account for something, especially when both in mobile and desktop the dominating OSes appear to use the same Radio Button style. Otherwise, it feels to me like decades of Windows UI history is not important any longer on the Windows platform.

[mdtauk]

Based on your sreenshot showing the most-used consumer OS besides Windows is also using the classic Windows Radio Button design I wonder why some (smaller) platforms such as Linux or Mac (iOS has its large share of customers but can't rival Android) should trump design Windows users grew up with. It feels to me like decades of Windows UI precendence is not important.

Windows has always changed controls through the years, so because for example the Taskbar was grey for 5 years, was not a good enough reason to not change it in Windows XP onwards.

Plus Mac recently made the change to their Radio Buttons IIRC - when they introduced Dark Mode and the concept of an Accent Colour. I didn't cite them as reasons for the change, but comparable platforms using that particular idea for their Radio Button controls.

If you follow your argument and Android is using the same Radio Button style as Windows did then there is all the more reason to keep the new design as similar as possible. After all, Android is by far the most used mobile consumer OS out there and it's market share is only growing.

I personally think keeping the design of the radio buttons and check boxes matching, makes sense, and other than personal opinions, I don't see any evidence of one design being more productive than the other. Windows has had lots of XAML control designs, that keep changing. Change in itself, is not a bad thing.

It's not about less usable. The old design was proven over decades and does the job perfectly. I don't see how the new design brings advantages to the table (see above: Android vs rest of mobile platforms). You could still change the border if that is absolutely necessary but otherwise keep the inner dot. Familiarity with Windows UI should account for something, especially when both in mobile and desktop the dominating OSes appear to use the same Radio Button style.

The inner dot is there. The control's background goes from empty to filled, like the check box. And the control has an outline in it's unselected state, so it sits well in a form along with pickers, text fields, and check boxes.

The selected state using the accent colour is sufficiently different to the unselected state with its outline, to show which state the control is in.

[Felix-Dev]

Windows has always changed controls through the years, so because for example the Taskbar was grey for 5 years, was not a good enough reason to not change it in Windows XP onwards.

As demonstrated by me, the Radio Button controls look was changed in nearly every Windows OS but it's overall look always remained similar. Keeping a UI similar means that you can still change it, however it doesn't have to be a radical re-design. It's not like I'm saying "hands-off, absolutely no change" here....

The inner dot is there. The control's background goes from empty to filled, like the check box. And the control has an outline in it's unselected state, so it sits well in a form along with pickers, text fields, and check boxes.

If you compare this re-design to the many other Radio Button re-designs which happened in Windows over the past 20 years, you'll notice they always kept the same style. This time, the re-design is not keeping that visual familiarity. You may argue the "inner dot" is still there but you will also see that it's a quite different design now (just compare all the radio button styles with the new one).

Change in itself, is not a bad thing.

Just as not changing something also isn't a bad thing. And when it comes the argument of familiarity you mentioned, the classic Radio Button style is both familiar to Windows users and for the vast majority of mobile users. Android users coming to Windows for the first time will instantly recognize the previously used radio button style.

I personally think keeping the design of the radio buttons and check boxes matching, makes sense, and other than personal opinions, I don't see any evidence of one design being more productive than the other.

Consistency with the WinUI checkbox design is a plus, I agree. But there are also enough reasons to keep the classic Radio Button style (and you can still change it visually as has been done by MS over decades). One compelling argument is to have consistency within Windows UI history.

Also, again, it's not about productivity here, as both designs will get the job done. It's about the classic style being at home on Windows and respecting its history when re-designing it. The classic radio button style is also the way to go if you want to create familiarity for first-time windows users as those will likely overwhelmingly come from Android.

[jp-weber]

Changes are always good as long as they are sufficiently justified and make things better. With the current changes there are some things, which are not explainable to me and also worsen the visibility. The RadioButtonBorderBorderThemeThickness with 1 is pixelated on normal screens (1080p at 24") and bad to see. The normal button is in the dark theme an impression, by hovering over the button the button becomes darker and you have no visible indication, as before with the light border.

Coming back to the radio button, the inner circle in the dark theme is a foreign body, why should this remain white? This seems inconsistent and not properly tested with the dark theme.

I am in favor of reversing these changes and taking time for the individual points.

[jevansaks]

Thanks all for the feedback! @chigy to review and make sure what's implemented matches spec ... and then we can review if the spec needs update or the implementation does. :)

[mdtauk]

I have spent most of the day, messing with virtual machines to make this timeline of Windows UIs

When it comes to WinUI, only the XAML controls so far, have been confirmed as being updated

[chigy]

Thanks all for the feedback! @chigy to review and make sure what's implemented matches spec ... and then we can review if the spec needs update or the implementation does. :)

Implementation matches the design. Starting conversation with design about this.

[jp-weber]

To take up the topic again. I find it strange that also with the new microsoft products the well-tried design is used.

MS Edge:

What I do not understand is why was chosen e.g. for the new radiobutton design for the UWP.

What affects the usability is the new behaviour of the button in dark mode. The button should get lighter on the hover and darker on the press. but this is not the case with the new design. Here the button gets darker on the hover and very bright on the press.

[mdtauk]

Edge uses the FastDNA control framework

[Felix-Dev]

@chigy The RadioButton look really should be reverted to the previous well-tested and proven design:

• Its new design introduced new color contrast issues (hence this thread)

• It breaks with the radio button design used in Windows since Windows 1.0 (see timeline image above). That's more than 30 years featuring a familiar RadioButton look!

• Edge Chromium - which is following/setting the newest UI standards by MS (as can be seen with the TabView control in WinUI catching up with the Edgium UI and not the other way around) - uses the well-known look (see posts above)

  Edit: As of at least version 85.0.522.1 Edge Chromium now uses the updated RadioButton style:
  

• Android, the most widely used OS in the market, uses the familiar UI look. The UI change in WinUI 2.2 was driven forward significantly in order to be "consistent with web and app style direction". (1)

• Fabric Web uses the familiar Windows look:
  

And before the comment will come, yes, Fabric Web also uses the updated checkbox look:

Note: I'm not calling for the border thickness to be reverted to 2px again, this can be easily changed by the developer using lightweight theme styling.

(1) I also tested out creating a form with radio buttons on the web using Microsoft Forms:

[Felix-Dev]

@mdtauk Out of interest, you always said WinUI should at least look at Fabric Web if not look very similar to it (see this thread):

Fabric Web as well as Fluent Web do seem to be ahead of the pack, and XAML as well as WPF and WinForms/Visual Styles should follow!
(#524 (comment))

Fabric Web and Fluent Web are the most recent changes to controls from Microsoft since Fluent Design was announced, and so it is natural that we look at those designs to help us find a direction where these UIs will go to.
(#524 (comment))

I have been making control design ideas for the past few years for my own purposes and for twitter conversations, and some of the things now in Fabric Web and Office Xaml were things I had wanted to change. Border thicknesses, certain inconsistencies with Radio Buttons, Check Boxes, drop downs etc.
(#524 (comment))

Shouldn't we have the same (or closely resembling) RadioButton UI in all of MS's UI offerings? If the RadioButton in Fabric Web is not planned to be changed, this will introduce new inconsistencies....which you have said you very much wanted to change for years.

If the Fabric Web RadioButton look is not updated to match WinUI's RadioButton look, based on all the points above, the RadioButton look should be reverted.

I'm not understanding the downvotes other than just being personal dislikes of the old UI. In Windows, Web and Mobile I see the familiar RadioButton style all the time. While the many UI changes introduced in WinUI 2.2 were meant to resemble Fabric UI, the web and mobile, it seems this RadioButton UI is meant to fork its own road.

[chigy]

@chigy The RadioButton look really should be reverted to the previous well-tested and proven design:

@Felix-Dev , Thank you for your feedback. I always appreciate your very candid comments.

This may not change your mind and it is not my intention. However I want to share why we have made this change. One of the design goals for Windows 10X is provide familiarity to the users that includes those who might not be very familiar with Windows. You are one of the Windows developers and very familiar with Windows but not all our potential users are. We even might have users who use Mac, Android, and Windows all in one single day due to the device they might be using for personal life as well as their work life.

@mdtauk had a good comparison here that sort of illustrate the point above. #1258 (comment)

The motivation of the change on top of familiarity above for Radio Button in particular is that our controls follow the systematic design. The model here is that selection is expressed not with the accent color but with the white. By doing so, we can ensure selected item has the accent color as a background while the selection visual like the dot or the check are white for both dark and light theme. This improves user’s scan-ability across a form for items that are “on”.

• Its new design introduced new color contrast issues (hence this thread)

I see that the original issue was opened using the gray color. Preselect accent colors are selected with contrast in mind, however some of the colors will not provide good contrast (e.g. yellow for light theme). It is a user choice to use a color that is not known to provide good contrast and user can always select the color that provides higher contrast.

• It breaks with the radio button design used in Windows since Windows 1.0 (see timeline image above). That's more than 30 years featuring a familiar RadioButton look!

As I have stated above, one of the goal for Windows 10X is the familiarity with other devices that people use outside of Windows as well as familiarity with itself.

• Edge Chromium - which is following/setting the newest UI standards by MS (as can be seen with the TabView control in WinUI catching up with the Edgium UI and not the other way around) - uses the well-known look (see posts above)

I am not sure where you got the impression that Edge Chromium is setting the standards? They might be leading the charge trying out some new design concepts that we may end up adopting later, but we might not. We are working to bring Windows 10X design through WinUI working with the Windows design team very closely. Design teams are working together under Fluent Design System which includes Edge, Windows, Fabric, and more. And I don’t think any single area alone is “setting the standards”…

• Android, the most widely used OS in the market, uses the familiar UI look. The UI change in WinUI 2.2 was driven forward significantly in order to be "consistent with web and app style direction". (1)
• Fabric Web uses the familiar Windows look:
  

Can you elaborate? I’m afraid I understand what you are trying to point out.

And before the comment will come, yes, Fabric Web also uses the updated checkbox look:

As stated above, this is because we, as Fluent Design System, is working together to align our UI as best as we can without causing too much disrupt to our existing customers. So it is not a co-incidence. Thank you for noticing. :)

[Felix-Dev]

@chigy

Can you elaborate? I’m afraid I understand what you are trying to point out.

I used Android as an example for the most widely used consumer OS out there which is using the "classic" Windows RadioButton look. The initial idea behind the WinUI UI changes was "to be consistent with web and app style direction" (see the title of issue #524). And Android is a huge app market and as such its default UI reaches a lot of users all over the world.

As for Fabric Web, it's a) the leading Microsoft UI product for the web (please correct me if I'm wrong here) and b) issue #524 mentions as a "should" criterion: Control update feel coherent with the same controls used by Fabric, Edge, and Xbox (Point 4 in the list of functional requirements). Which is why I was pointing out the, in my view, considerable differences between the design in WinUI and the design in Fabric Web & Edge (I don't own an Xbox so I don't know how RadioButtons look there).

I am understanding a revert back to the old look is off the table. In that case, would it be possible to add the old design back as a style in WinUI to be consumed by developers/designers if they so choose?

Issue #524 made sure any UI change made to the thickness and corner radii of controls could easily be reverted without having to create a hard-copy of the control style (point 3 in the list).
However, reverting back to the previous design of the RadioButton is not something which can just be done by overwriting a theme resource like ControlCornerRadius. It requires the developer instead to retemplate the control.

Why would I want to use the previous look of the RadioButton in my apps? Because I want the RadioButton to appear familiar to users coming from Windows, Android and the web. As such, I would very much welcome it if I as the developer/designer can consume a RadioButton style shipped in WinUI to provide the previous design:

<RadioButton Style="{StaticResource OutlinedRadioButtonStyle}" />

For completeness, the resulting UI:

(The prefix Outlined has been copied from @mdtauk's post here #1258 (comment))

Now, before someone will say "You know, WinUI is open-source so all you need to do is copy/paste the pre WinUI 2.2 radio button style into your app" I would like to point out this a) creates a hard-copy of the RadioButton style frozen in time and b) whether a framework is open source or not should not influence how easy & straightforward it will be for developers/designers to create familiar UI for their users.

You probably noticed it by now, I really want to use the old style in my apps because I'm seeing it being used very widely in different products (Edge, web and mobile). I believe many users of my apps will be unfamiliar with the new RadioButton design as they either grew up with Windows, are coming from web/mobile or just use daily apps like Edgium which features the pre WinUI 2.2 RadioButton design.

As such, I would very much welcome it a lot if as a compromise, a new RadioButton style can be introduced in WinUI (see above), with the default style being the updated style in WinUI 2.2. If a developer/designer wants to build an app mainly for 10X, by all means shall they be happily using the updated design. If a developer/designer is targeting other customers (as written above) I would appreciate it a lot if they are given a choice by the framework - use the new RadioButton design featured prominently in 10X or use the classic RadioButton design.

[Poopooracoocoo]

The whole Windows 10X being more familiar to new users thing is a bit confusing. People would probably be coming from iOS, Android and Chrome OS. iOS doesn't have radio buttons and Android and Chrome OS both have the outlined style radio button. I don't think that Windows 10X is targeting macOS and GNOME users. And besides, a different default UI wouldn't make a difference unless stuff actually gets fixed and implemented. remember groove music maker lmfao. oh and control panel still exists. 🤣

all i really want is consistency. the new radio button is consistent with the checkbox but it feels like only WinUI uses the new radio button

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.