Proposal: Update the corner radii of common controls to be consistent with web and app style direction

[sravya03]

Proposal: Update default control styles with rounded corners and make them easy to customize

---

Corner Radius (aka Rounded Corner) How-To document PR is created.

This will be added to docs.microsoft.com as a documentation. It will be a new page under https://docs.microsoft.com/en-us/windows/uwp/design/style/.

Ask to community: I am trying out writing a little more "background explanation (WHY)" that our customers have expressed we provide with our documentation in some of our focus groups. I would like feedback as this does not follow normal documentation pattern.

Are those extra information useful/helpful, not relevant, other info missing, etc.?

---

Summary

Update default control styles with rounded corners and make them easy to customize. Developers should not have to retemplate the controls to "unround" the corners or round them further.

Rationale

Problems today:

• XAML controls are inconsistent with how web and mobile apps are evolving – this highlights the inconsistency across app ecosystem on Windows when these UI are used intermixed with each other.

• There are many different levels of corner rounding in the market today but the way XAML controls are architected require those developers who wants to update to retemplate all the controls, locking them to a version of the control that will not be able to take advantage of future updates as easily.

Functional Requirements

#	Feature	Priority
1	When developers use common controls as is, all the controls are consistent with each other. (Update default control style.)	Must
1.1	Users experience form controls (e.g. button, text box, etc.) with rounded corner.	Must
1.2	Users experience popup/transient menu type controls (e.g. flyout, CommandBarFlyout, etc.) with rounded corner and they look appropriate with shadow.	Must
1.3	Users experience "bars" with rounded corners (e.g. selection bar, scrollbar, etc.)	Must
2	When developers use the controls in a normal use case, there will be no perceived performance issue or slowness in rendering	Must
3	Developers have flexibility to style values of corner radii without retemplating. (This is tracked by #684.)	Should
4	Control update feel coherent with the same controls used by Fabric, Edge, and Xbox	Should
5	Users experience fully circular slider thumb that feels more touch friendly.	Should
6	Developers are able to round the popup/transient menu type controls' corner further and users do not experience visual glitch	Could
7	Users experience rounded keyboard focus rectangle	Could
8	Controls with rounded corners are rendered in performant way when they are used in more stressful/less normal use cases (e.g. 100s of rounded corners are used at once, large surface has rounded corner that is persistent (i.e. not temporary or transient))	Could
9	Update controls to render with more performant ninegrid so there are less measurable performant impact (this is measurable by data, but still not perceivable by user as in number 4 above)	Could
10	Make it possible to round the inner and outer lines of border individually rounded vs. not	Won't
11	When performance is measured, there is no difference between when the corner is not round vs. round (this is physically impossible)	Won't

Important Notes

There are three categories of changes being proposed (requirement number 1.1, 1.2, and 1.3) and here are mock up of those.

Here are relevant visual comp files: https://github.com/microsoft/microsoft-ui-xaml-specs/tree/user/chigy/roundedcorner/active/RoundedCorner/ImageFiles

Courtesy of @mrlacey , we have this easier to view version of the above file folder: https://github.com/mrlacey/microsoft-ui-xaml-specs/blob/RoundedCornerVisualizations/active/RoundedCorner/ImageFiles/index.md

Form type controls (req 1.1) • Button • CheckBox • ComboBox • DropDownButton • Slider • SplitButton • ToggleButton • ToggleSplitButton • Flipview • GridView • ListView • TreeView • ContentDialog • AutoSuggestBox • PasswordBox • RichEditBox • TextBox • DatePicker • CalendarDatePicker • Tab control

Popup/transient menu type controls (req 1.2) • CalendarDatePicker • DatePicker • TimePicker • Flyout • TeachingTip • ToolTip • DropDownButton • SplitButton • Slider • AutoSuggestBox • CommandBarFlyout • MenuFlyout • ComboBox • ColorPicker • MediaPlayerElement • ContentDialog • MenuBar • ToggleSplitButton

Bars (req 1.3) • NavigationView • Pivot • ScrollIndicator • ProgressBar • Slider • ColorPicker • MediaPlayerElement • WebView (not a part of XAML change)

User Feedback

Windows 10 Reddit Thread

Open Questions

[chigy]

I have a couple suggestions about the flyout menus. With the shadows demarcating the menu, do we really need the border? And IMO the selection highlight could cover the entire width of the flyout surface, without leaving gaps.

@quantumfrost , Yes, as a matter of fact, we do. Shadow is smart. So when the system is on low power mode or some other situation where we turn off the shadow, the border will come into the play. We designed the border in such a way that it is subtle. We did evaluate several different options but this is what was most robust.

[chigy]

@nepxune, @mdtauk Thank you for your feedback. Let me respond to a few of the points you make above.

The option to provide user setting to have corner rounding something user can choose from is an interesting one. However it also has a lot to do with this feedback over other important features that we have to weigh against in Windows system as a whole.

As application developers, I hope you all are keenly aware of the need to prioritize and do what's right for your customer. For Windows case, the customer is the users who uses the OS. Of course, developers who create apps on this OS are also important customers, and I believe by providing the ease of switching corner radii, we are able to address the main issue that this change would have introduced.

As to the users who use the OS, we heard from our customers that Windows are too intimidating. Both Windows and Office team did user study where they ended up concluding (independently) that even as subtle as a rounded corner makes a difference in making the product feel familiar and approachable.

So I know many people on GitHub and other forum mention that we are following iOS and Android, but it is not so. We are arriving at this decision from understanding our users. Yes, the fact they use rounded corner adds to the familiarity aspect, but we are not blindly following what the industry is doing.

[chigy]

I have a sort of a different perspective on this. Earlier in the thread I saw discussion about bringing Fabric UI (Web) and Windows (UWP) styles closer together, and this worries me a bit.

Here's some context: I have been a user of Microsoft Edge for years, and one of my favorite things about it was its UWP-inspired look and feel. When Edge Insider was revealed, I was very disappointed to see it used modified Chrome and Web UI design instead of its predecessor's UWP styling. While the round corners shown are very minimal, to the point where I have no problem with them, this thread is giving me the same sense of disappointment. I don't want to see Windows lose its unique (and superior!) look and feel in favor of matching ill-designed "web standards." In fact, I'd rather see aspects of Fluent UWP design make their way to Fabric!

@19lmyers Thank you for your feedback about your worry about Windows loosing its own unique (and even superior) look. As mentioned in above comment, our users do not necessarily appreciate Windows being too different because they are not familiar to them, so this is a balancing act.

Under Fluent Design System, design teams across the company are discussing many differences and trying to eliminate unnecessary differences introduced thus far. Just as the comment I made about iOS and Android above, those design that we are proposing are not because we are copying Fabric, but our Windows designers arrived at them based on re-evaluating their own UI system. They often result in the similar design, interestingly enough... That said, I really appreciate many people's enthusiasm for keeping Windows unique.

[SavoySchuler]

Welcome to our repo, @zag2me! We're excited to have you joining the discussions here. I agree and its the right place to draw attention to the issues that matter to you! You can find our Feature Request form here: https://github.com/microsoft/microsoft-ui-xaml/issues/new/choose

[Felix-Dev]

@chigy

The option to provide user setting to have corner rounding something user can choose from is an interesting one. However it also has a lot to do with this feedback over other important features that we have to weigh against in Windows system as a whole.

As to the users who use the OS, we heard from our customers that Windows are too intimidating. Both Windows and Office team did user study where they ended up concluding (independently) that even as subtle as a rounded corner makes a difference in making the product feel familiar and approachable.

We are arriving at this decision from understanding our users. Yes, the fact they use rounded corner adds to the familiarity aspect, but we are not blindly following what the industry is doing.

Thank you for your feedback about your worry about Windows loosing its own unique (and even superior) look. As mentioned in above comment, our users do not necessarily appreciate Windows being too different because they are not familiar to them, so this is a balancing act.

And here is the problem I have with that: You mention "Windows users" but if anything, this thread and other linked reddit threads have shown so far is that there isn't a homogenous group of "Windows users". At the end of the day, a company can always follow the direction the majority of its customers want it to go but even that leaves problems. What if the ratio is rather small (and behind each number woud be a huge absolute number of users)? Based on the feedback here, in reddit and other places I don't get the feeling there is a overwhelming majority for one UI or another.

Which leads us to the proposal a few of us have been floating: Adding more UI customization options to Windows.

As you rightly say so, the given customization options should be meassured carefully, but customization in and of itself shouldn't just be discarded as an option. As you said, and at this point I am starting to repeat myself, the proposed corner radius change is a small change, so any impact of making it a user choice on UI should be negligible or straight out non-existent. I and others have also pointed out limitations for this very example, such as a set of values in the range of 0 - 2 for corner radii, to ensure users can't just customize their Windows in a way which would break the "Windows UI Identity" your team wants to create.

Long story short, carefully meassured customization options on top of these design changes sounds like a great way to address the many different UI preferences among us Windows users and would go a long way in creating a satisfying UI for the entire family of us passionate Windows users.

[shaheedmalik]

@chigy Most people would agree that 2px would be a good radius. Giving the rest an option to turn it off would be a good ideal.

Most users want Windows to be on the cutting edge of UI and but other legacy users don't want to change.

Don't sacrifice change for the few, just give them the option to turn it off.

[Felix-Dev]

@shaheedmalik There are no "legacy" users here and I also don't see how you arrive at "most users want [rounded corners]" or that the current Windows look isn't "cutting edge".

UI is highly subjective but that doesn't mean we can just gloss over differing opinions as "legacy", "unwilling to change", etc...

Let's not try to just discard what other users say as opinions from "users who don't want to wake up from the past" and keep the current discussion passionate but also respectful as it has been so far.

[shaheedmalik]

@Felix-Dev Legacy users are ones who would've stayed on Windows 7 given the chance, ones who were resistant to changes made in Windows 8, ones who are resistant to the OS UI changes moving forward.

Apple and Google copied features from Windows 8.1, implemented them and users jumped over to those platforms because they were seen as cutting edge. In the meanwhile, Microsoft listening to legacy users, scaled back because of a loud vocal minority.

In this particular, case the majority want rounded corners as linked (https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/)

[Felix-Dev]

The thing is, I'm no legacy user though and it appeared to me you just threw everyone not liking the current rounded corners push (and possible border thickness reduction) into that exact category. I am also not getting your down vote for my post.

About the majority case: I wasn't aware of any design survey by MS about this very topic and based on the reactions of many users one month ago when details about this push first appeared on the Internet many users weren't aware of either (so likely hadn't been asked). If you check this reddit post (which btw has three times as many comments as the reddit thread you linked above so far) you'll notice that from what we know the picture isn't exactly clear-cut. I'm in no position to claim "this position is clearly in the majority" and I'll refrain from doing so in the future too.

If I'm mistaken about your post, then I apologize but from the way I read it, it was clearly dismissive of any voice making the case against this change declaring it to be the voice of a "legacy user who doesn't want change". That is disrespectful to me and all the others would added their voices to this debate.

[mdtauk]

@Felix-Dev Let's not try to read any personal opinions into these up/down votes and replies.

The simple answer is that these changes are not being made on a whim, or to copy other platform UI styles - but as a result of consultation, feedback, and an expressed will of users and developers.

We should try to keep the discussions constructive, so not about whether or not the changes should be made, but in what way should they be made.

[shaheedmalik]

People hated the rounded corners in the original post as they were too round. This newer post links to this updated GitHub proposal. The newer feedback reflects responses of the updated proposal. Additionally, the original post from a month ago was linked to show users the changes from the original proposal to the revised proposal.

[Felix-Dev]

I agree, we should get back to the proposal and just forget about these last posts.

I think it's pretty clear at this point that these changes will be made and all I'm trying to do is to convince @chigy that there is a case for carefully measured customization, something every participant here might find useful at some point - whether they like the current UI change or not. Just as I and others have said, including @shaheedmalik, adding some sort of corner radius customization could be a good ideal to strive for.

[mdtauk]

Right now there is a proposal for making it easy for devs to set their own CornerRadius on every control ( #684 ), which is also enabling the team to add CornerRadii to the controls by default.

Doing it at an OS level is a complicated task, and the research does not quite warrant the engineering time and effort involved in implementing that.

But you have made your views clear @Felix-Dev and if after the new controls are in the hands of a majority of Windows users, the feedback received, could lead to this idea being explored in the future.

[chigy]

I've updated spec to remove "AppBarSeparator" from rounding since I confirmed that is 1px line.

[mdtauk]

I've updated spec to remove "AppBarSeparator" from rounding since I confirmed that is 1px line.

@chigy At 100% scaling it will be 1 epx - but at 200%, 300%, 400% scaling, this may need some attention.

If it really is a line, and not a rectangle - perhaps setting the StrokeStartLineCap and StrokeEndLineCap to PenLineCap.Round

[Felix-Dev]

@mdtauk

Doing it at an OS level is a complicated task, and the research does not quite warrant the engineering time and effort involved in implementing that.

This proposal already seems to do most of the work, adding a CornerRadius property to controls. Only thing remaining then would be the creation of resource SystemCornerRadius those controls could bind to for their actual corner radius (similar to how today you use a SystemAccentColor resource to color elements of your UI in the accent color the user sets in the Settings app.

As for how much work it would be to create such resource and make it updatable via the Settings app, that remains for MS to comment on. But given the work this proposal is already doing anyway and also the previous work in the form of exposing an AccentColor resource, I don't see how it would be so demanding as you put it to be. The OS level would literally only be providing a corner radius value which can be read from and written to and then use the same system you already have in place for today's accent color resource.

[mdtauk]

@mdtauk

Doing it at an OS level is a complicated task, and the research does not quite warrant the engineering time and effort involved in implementing that.

This proposal already seems to do most of the work, adding a CornerRadius property to controls. Only thing remaining then would be the creation of resource SystemCornerRadius those controls could bind to for their actual corner radius (similar to how today you use a SystemAccentColor resource to color elements of your UI in the accent color the user sets in the Settings app.

As for how much work it would be to create such resource and make it updatable via the Settings app, that remains for MS to comment on. But given the work this proposal is already doing anyway and also the previous work in the form of exposing an AccentColor resource, I don't see how it would be so demanding as you put it to be. The OS level would literally only be providing a corner radius value which can be read from and written to and then use the same system you already have in place for today's accent color resource.

Would it be a slider or a toggle?

[X] Rounded corners on controls

There wouldn't just be a single Corner Radius value to set btw. Some elements would only have the rounding on one side, or only the top corners would be rounded. The flyouts and pop over controls will be getting a 4 epx radius, where as other controls will only have 2 epx.

You would be setting many variables as this setting changes in the OS. Then what about testing? Also there would be expectations. How will users react to apps they decide to ignore the user's preference? How do you communicate with the users which controls get rounded, and which don't? Some controls will have inner border or outer border elements. These would need their CornerRadius values adjusted to ensure the hug the edges of the shapes properly.

In the end, this may be a change that is welcomed without much fuss, and so it could be considered an over-reaction to add yet another option to the OS.

[Felix-Dev]

@mdtauk @chigy It certainly would need some planning but the team clearly wants to make it very easy for devs to create squared controls. As such, instead of a corner radius value setting, I'd be fine with a simple UserRoundedCorners boolean switch. In fact, the idea of setting values was just to add even more options whereas the users disagreeing with this move were always about just giving them an option to revert the look of the controls back. So, that won't be an issue at all.

As for the "yet-another option" part: That sounds like there already are too many options available to the user which is an entirely different issue and shouldn't be used as a defining point to not add this simple switch.

Windows and the Design team talks daily (on twitter) how it wants to include users and not exclude them. Here is a chance where I feel it is relatively easy for MS to add a single option to respect the sheer variety in opinions of their users.

How will users react to apps they decide to ignore the user's preference?

I don't think that's a problem as well, as long as essential Windows apps/UI elements would honor it (i.e. Settings app, Security app, Clipboard, taskbar network flyout connect/disconnect buttons....). Third-party apps are free to use a style they want, a simple note in the Settings app saying that third-party apps are not guaranteed to follow this user setting would be fine.

[Neptune-mk2]

@mdtauk @chigy I believe that @Felix-Dev is right on this one, a boolean switch with a simple toggle could be the way to go for customization at user level , I feel a slider for customization of this at user level would be over complicating things, however if its a slider with 3 fixed preset positions things could change.

A slider with 3 fixed options would allow an additional setting that could have a more drastic corner radii change like the one that was originally proposed, so you could have :

Sharp - Sharp corners like they are now Middle option - The new smaller radii Rounded - The original proposed radii change or something even more rounded

This option has the potential to satisfy all groups and additionally it is a drastic change enough that you could actually pass this off as a new "Theming" feature in Windows, basically even though this is more a change for developers by branding it as a new "Theming" feature with either the toggle implementation or the 3 preset slider, you could also pass it off as a new feature for consumers.

how would users react to apps that decide to ignore the user's preference?

I feel the user would simply see it the way they currently do with the accent color when it is not available, third party apps should be free to do whatever they want but like @Felix-Dev said Windows apps/UI elements would definitely need to honor the user's variable.

I don't think there is a need to put a note in settings saying third-party apps won't honor the setting, there was no need to put a disclaimer in the accent color section, so believe it is the same for this as well.

[Qowy]

Doing it at an OS level is a complicated task, and the research does not quite warrant the engineering time and effort involved in implementing that.

But you have made your views clear @Felix-Dev and if after the new controls are in the hands of a majority of Windows users, the feedback received, could lead to this idea being explored in the future.

I feel like I have to point out something here. While I do not feel strongly about the changes proposed either way (I have to work with too many UI Styles over different ecosystems every single day for inconsistencies or changes to bother me anymore), I feel like this mindset is not a good one in order to create a rich user friendly experience.

Please do not release features that are 80% done and might or might not be brought to 100% in the next release. What would probably happen is that no dev would spend the time to test and develop his apps for both rounded or not rounded borders. And why would they. The system now uses rounded, why should anyone want their app to look slightly different than the OS (otherwise they would go for full theming anyway) If there was a system wide toggle there would be an incentive to implement it. But if you are doing things this way around, no need for a toggle will ever arise because no app will see the need to implement it in the first place.

On the original Topic: I Think the 2px borders look great except the Combo Boxes. The highlight of the last element should not leave a white border below it (or at least not more than left and right, of course this means that the bottom highlight corners must be rounded, too) and maybe there should not be rounded corners in the expanded state between the box and It's flyout. I feel like it gives this weird disjointed look between them. Maybe it would be better to make the flyout 2px smaller on each side and let it have no rounded corners on top. This way it would look like a piece of paper being pulled from a dispenser. (I hope you can understand what I mean :D sadly I have no tools available right now to sketch it up)

[mdtauk]

On the original Topic: I Think the 2px borders look great except the Combo Boxes. The highlight of the last element should not leave a white border below it (or at least not more than left and right, of course this means that the bottom highlight corners must be rounded, too) and maybe there should not be rounded corners in the expanded state between the box and It's flyout. I feel like it gives this weird disjointed look between them. Maybe it would be better to make the flyout 2px smaller on each side and let it have no rounded corners on top. This way it would look like a piece of paper being pulled from a dispenser. (I hope you can understand what I mean :D sadly I have no tools available right now to sketch it up)

I know what you are describing, and I did consider that for my design mock ups. The problem with that is it means ComboBox would get its own flyout template, which would make it different to context menus, menu flyouts, Prefix, Suffix, AutoComplete flyouts, etc.

[Qowy]

That's what I meant (except that the Box itself could keep the bottom corners rounded) Yes the different flyouts would be different, but then again there are inherently two types of flyout. Those that are attached to something an those that aren't. That they now would have to be different is just the cost of doing rounded corners ;) Furthermore if corner radius would become stylable couldn't it just be set by the Parent control.

My XAML is a bit rusty but a Combobox Template like:

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

[mdtauk]

Furthermore if corner radius would become stylable couldn't it just be set by the Parent control.

My XAML is a bit rusty but a Combobox Template like:

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

That is similar to how you may override styling, but for use in templates you would need separate styles for each orientation.

<Thickness x:Name="FlyoutLooseCornerRadius" Value="4,4,4,4"/>

Orientations:

• Bottom
• BottomEdgeAlignedLeft
• BottomEdgeAlignedRight
• Full
• Left
• LeftEdgeAlignedBottom 
• LeftEdgeAlignedTop
• Right
• RightEdgeAlignedBottom  
• RightEdgeAlignedTop  
• Top
• TopEdgeAlignedLeft
• TopEdgeAlignedRight

---

The Flyout is embedded inside the ComboBox control. So the control would have a CornerRadius property which would affect the ComboBox only, not the flyout included, that would have the be a ThemeResource being overridden.

<ComboBox CornerRadius="2,2,2,2">  
      <x:String>Blue</x:String>
      <x:String>Green</x:String>
      <x:String>Red</x:String>
      <x:String>Yellow</x:String>
</ComboBox>  

[mdtauk]

Following on from adjusting the CornerRadius property on the Flyout when it is aligned and attached to ComboBoxes (and other controls) It may require the addition of TopEdgeAligned and BottomEdgeAligned to the FlyoutPlacementMode enum to achieve the desired result.

(Updated Image)

I have also included a closer 800% look at the Flyout styling. The Two borders would ensure the flyouts look elevated in both Light and Dark themes with or without the shadow.

[Qowy]

That looks very good. Of course the attached look, looks kind of strange when the item you attach it to is smaller than the flyout, but that is definitely something for the individual app to decide. The focus highlight of the items in the bottom row should probably not be rounded on the bottom (Since the top isn't for the top row) but that is probably not intentional.

By the way I just noticed that this "attached look" is how the MacOs Top Menu Bar works so this look does not seem to be outlandishly uncommon ;)

[mdtauk]

That looks very good. Of course the attached look, looks kind of strange when the item you attach it to is smaller than the flyout, but that is definitely something for the individual app to decide. The focus highlight of the items in the bottom row should probably not be rounded on the bottom (Since the top isn't for the top row) but that is probably not intentional.

By the way I just noticed that this "attached look" is how the MacOs Top Menu Bar works so this look does not seem to be outlandishly uncommon ;)

I had forgotten the rounding, so I updated the image to fix that, and also add a little more detail with the Zoomed example - oh and included the Hover state

[Qowy]

I am not sure if I prefer middle items to have a rounded highlight or not, since on the one hand it is more consistent, on the other it leaves those little aggressive looking (Ok now I am just making stuff up :) ) sharp white spaces between highlighted elements and the border. But that is something I leave up to real designers to decide :D

[mdtauk]

I am not sure if I prefer middle items to have a rounded highlight or not, since on the one hand it is more consistent, on the other it leaves those little aggressive looking (Ok now I am just making stuff up :) ) sharp white spaces between highlighted elements and the border. But that is something I leave up to real designers to decide :D

I agree, I am in two minds about it too. I think I like it straight edged but as the controls summoning the flyout will be rounded, and these are controls within a control, they should be rounded.

And some Context Menus will contain controls that don't span the full width of the flyout, so the rounded selection will work for those

[shaheedmalik]

I am not sure if I prefer middle items to have a rounded highlight or not, since on the one hand it is more consistent, on the other it leaves those little aggressive looking (Ok now I am just making stuff up :) ) sharp white spaces between highlighted elements and the border. But that is something I leave up to real designers to decide :D

I feel the same way. If the combo list is the same size as the combo box, then they should stay straight at the point of origin, otherwise the side that doesn't line up should be round.

[Felix-Dev]

@mdtauk @Qowy @shaheedmalik would it be possible for you to create an own issue specific for comboboxes? This thread is about corner radius in general and not some specific cases which could easily spawn an entire new conversation as seen here, and thus overshadow talking points about the general approach.

Please don't misunderstand this, but if we have such specific discussions for many of the controls, this thread will easily lose its general focus.

Much appreciated!

PS: About non-border highlighted elements: The element highlight should definitely be a rectangle. Making it have rounded colors is just weird.

[jkellywilkerson]

I'm probably in the minority here with my opinion, but changing the corner radii of the common controls is honestly a terrible idea. Looking at the menu example above from @mdtauk and comparing that to the current Edge menu leaves me a bit disgusted. Things are finally getting settled with Fluent design and everything is finally looking consistent and really good. Now, let's change it all to look like the Web? No...let the Web be the Web and leave Windows (and the Common Controls) alone. If devs want to implement rounded corners using third-party controls in their own apps, so be it. But, to start changing the default look and feel now is just heresy - let Apple be Apple, Google be Google, and the Web be the Web. Y'all just continue to be Microsoft and do your thing - it's working, so let it work. I, for one, actually love the Microsoft Windows 10 look and feel of Fluent design and want my apps to look like Windows - not Apple, Google or the Web. I can't stand the way Chrome looks - Edge is light years better looking and Windows much better in form and function than macOS. And, TBH, bring Windows 10 Mobile back to the phone. Good grief, quit giving up on stuff so quickly and leave Fluent design alone and let it do its thing.

[jkellywilkerson]

@mdtauk

Doing it at an OS level is a complicated task, and the research does not quite warrant the engineering time and effort involved in implementing that.

This proposal already seems to do most of the work, adding a CornerRadius property to controls. Only thing remaining then would be the creation of resource SystemCornerRadius those controls could bind to for their actual corner radius (similar to how today you use a SystemAccentColor resource to color elements of your UI in the accent color the user sets in the Settings app. As for how much work it would be to create such resource and make it updatable via the Settings app, that remains for MS to comment on. But given the work this proposal is already doing anyway and also the previous work in the form of exposing an AccentColor resource, I don't see how it would be so demanding as you put it to be. The OS level would literally only be providing a corner radius value which can be read from and written to and then use the same system you already have in place for today's accent color resource.

Would it be a slider or a toggle? [X] Rounded corners on controls There wouldn't just be a single Corner Radius value to set btw. Some elements would only have the rounding on one side, or only the top corners would be rounded. The flyouts and pop over controls will be getting a 4 epx radius, where as other controls will only have 2 epx. You would be setting many variables as this setting changes in the OS. Then what about testing? Also there would be expectations. How will users react to apps they decide to ignore the user's preference? How do you communicate with the users which controls get rounded, and which don't? Some controls will have inner border or outer border elements. These would need their CornerRadius values adjusted to ensure the hug the edges of the shapes properly. In the end, this may be a change that is welcomed without much fuss, and so it could be considered an over-reaction to add yet another option to the OS.

Having a 2epx corner radius here, 4epx corner radius there, and a different in another place because 2 or 4 doesn't look quite right is terrible UX. Leave the Common Controls like they are - Job Done...move on to making something else great.

[Felix-Dev]

@chigy So I made a count from the responses in the reddit thread I started a few days ago and here it is (unfortunately, there seems to be no obvious way to easily see the total number of users who participated):

Opinions expressed pro-corner radius (contra current UI): 18 Opinions expressed pro-current UI (and contra corner radius): 12 (+1 if I include me as the reddit poster, also included @shaheedmalik in the pro-corner-radius count)

The rest:

• Asking for MS to provide UI choices
• Fine with both
• Didn't state an opinion on the proposal
• Expressed a general frustration with the inconsistencies in the Windows system (i.e. Win32 programs vs UWP apps)

Especially the last group (frustration) was a good chunk of the people who participated in the thread.

Summarizing the result, we see that we have sizable factions both for rounded corners (the proposal) and for squared corners (current UI). Add to that the group of people who expressed their wish to be able to switch between these two styles in the system. However, aside from rounded corners or not, the most given response - by a mile - is to finally bring consistency to the Windows system as a whole. WinUI 3.0 and the MS teams will have their work cut to bring all the different Windows system components and UWP apps under a single UI Design Language.

@chigy With all the talk by the Microsoft Design Team to "include" users instead of "excluding" them, I think this thread and the above reddit thread shows there are good reasons to provide a simple option in the UI to switch between the proposed rounded corner UI and the current UI (sharp corners).

[mdtauk]

@Felix-Dev Technically the post I made was about the Flyout control, the ComboBox is just one of the controls which has a flyout component.

I happen to think rounding on all corners makes sense in all circumstances. And the team decided flyouts and dialogs will use 4 epx corners, and other controls will use 2 epx.

[Felix-Dev]

@mdtauk, as I said, please don't misunderstand this. I think it's absolutely fine to point out specific control UI in this thread (such as I asked about the weird looking corner thickness for checkbox corner radii in the treeview example). Just, if there is conversation spanning multiple posts happening regarding a specific UI element (such as flyouts/comboboxes/...), I feel it is best to create a separate issue for this particular. And as you saw, your post about flyouts soon led to a discussion regarding comboboxes. Now just imagine someone then starts a conversation about how focus shadows should look like and we have a whole "mess" (as in multiple specific UI elements being discussed in close proximity) starting where it will be hard to bring the thread back to the general proposal and how to deal with it.

[mdtauk]

@mdtauk, as I said, please don't misunderstand this. I think it's absolutely fine to point out specific control UI in this thread (such as I asked about the weird looking corner thickness for checkbox corner radii in the treeview example). Just, if there is conversation spanning multiple posts happening regarding a specific UI element (such as flyouts/comboboxes/...), I feel it is best to create a separate issue for this particular. Just imagine someone then starts a conversation about how focus shadows should look like and we have a whole mess starting where it will be hard to bring the thread back to the general proposal and how to deal with it.

I don't intend to make a separate issue just for flyouts, but I was specifically discussing the Corner Radii of that control.

I wonder if @chigy could offer us some kind of estimate when we will be able to see an updated Design Toolkit with all the updated control designs, so the conversation can move to more specifics, than general complaints about the decision to change them to begin with.

[shaheedmalik]

If you are going to count the posts, you should count the upvotes as well.

[Felix-Dev]

@shaheedmalik Not explicitely counting the up-counts as I don't know exactly how those up-voters feel about these UI types (for example, they could be fine with either choice but still like the rounded corder proposal just as the current UI). More importantly, they might have upvoted a post because of a certain part in that post, such as pointing out UI inconsistencies. Hence, I only counted the actual posts where you can clearly see an approval for either UI in the author's statement.

FWIW, "2px seems to be the sweet spot." got the most up-votes with 54 points.

There is also a highly-rated post (+21 - 4th place) calling for "end user theming support" though I cannot determine if all those upvotes are for the call-for-customization part or for the part where the author criticizes the missing consistency in the system.

[chigy]

I wonder if @chigy could offer us some kind of estimate when we will be able to see an updated Design Toolkit with all the updated control designs, so the conversation can move to more specifics, than general complaints about the decision to change them to begin with.

Thank you for asking. I linked to the design comps in the “Important Note” section of the issue, so please make sure to check that out.

In general, I want to make sure we keep the conversation here focused on how we can make rounded corners work in WinUI. I know folks have differing opinions on this idea or even if rounded corners are a good idea in general. So I felt it is worth me mentioning that this is part of the overall Windows design direction that is being driven out of another team at Microsoft. We are just trying to figure out how to make WinUI work with this new design direction, making it easier for developers. We don’t really have the authority to conclude that rounded corners aren’t a “thing” in Windows. In other words, rounded corner is already a plan, and so we wanted to make you aware and consult with our WinUI community to make sure that we implement this capability responsibly. Hope that makes sense.

[19lmyers]

We don’t really have the authority to conclude that rounded corners aren’t a “thing” in Windows. In other words, rounded corner is already a plan, and so we wanted to make you aware and consult with our WinUI community to make sure that we implement this capability responsibly.

I suspect a lot of people here would like to talk to the people with said authority, because this is the major issue for a lot of us.

[mdtauk]

Thank you for asking. I linked to the design comps in the “Important Note” section of the issue, so please make sure to check that out.

In general, I want to make sure we keep the conversation here focused on how we can make rounded corners work in WinUI. I know folks have differing opinions on this idea or even if rounded corners are a good idea in general. So I felt it is worth me mentioning that this is part of the overall Windows design direction that is being driven out of another team at Microsoft. We are just trying to figure out how to make WinUI work with this new design direction, making it easier for developers. We don’t really have the authority to conclude that rounded corners aren’t a “thing” in Windows. In other words, rounded corner is already a plan, and so we wanted to make you aware and consult with our WinUI community to make sure that we implement this capability responsibly. Hope that makes sense.

You did mention conversations about some things are still ongoing, such as the TextBox border thickness etc - so I assumed those designs were an initial idea rather than a finally final. (I guess I was hoping to still be able to influence things like the TextBox, Buttons, CheckBoxes, etc)

I think I know the answer to this, but I will ask anyway - are there plans to share these Windows UI designs that team have decided on?

Will these changes being planned by Windows, also apply to the Win32 Visual Styles and the Shell window TitleBars etc. If so, WPF should probably also update their default controls when running on those versions of Windows this new style applies to. ( I already suggested that should happen #699 )

[mdtauk]

We don’t really have the authority to conclude that rounded corners aren’t a “thing” in Windows. In other words, rounded corner is already a plan, and so we wanted to make you aware and consult with our WinUI community to make sure that we implement this capability responsibly.

I suspect a lot of people here would like to talk to the people with said authority, because this is the major issue for a lot of us.

I guess this will appear in the Feedback Hub when the design changes go live - That will most likely reach the Windows Team.

[chigy]

You did mention conversations about some things are still ongoing, such as the TextBox border thickness etc - so I assumed those designs were an initial idea rather than a finally final. (I guess I was hoping to still be able to influence things like the TextBox, Buttons, CheckBoxes, etc)

I think I know the answer to this, but I will ask anyway - are there plans to share these Windows UI designs that team have decided on?

@mdtauk Yes, and to be very transparent here... The reality is, sooner this particular issue's conversation slows down, sooner I can get to work on that... :)

[mdtauk]

@chigy I apologise if I have contributed to the derailing of the conversation and slowing progress. I only ever wanted to help, and ensure WinUI 3.0 looks as good as it can!

[Felix-Dev]

@chigy I'm confused now. You are a person working on the Windows Fluent Design Team, WinUI is said to be "[...] highly-optimized native UI platform used to create Windows itself" (quoted from here, section "Benefits of WinUI 3". So, if this isn't the place to influence the Windows 10 Design Language, then what is it?

I don't know how to feel about your reply. You are basically asking us for feedback but it turns out we never had much chance to influence the proposal anyway? If there is no one with actual authority in this post, then all we do here is basically hot air. Even in cases like Martin's one where he is posting his design concepts in the hope they will get implemented by the desgin team. WinUI can't style the controls differently from where the "windows design authority" wants it to go, because as the WinUI team itself said: "WinUI 3.0+ will be THE Windows UI".

@chigy I and others have invested much time, energy and passion into trying highlight that "Windows users" isn't a homogenous group as some of your comments seemed to have suggested. We showed you there are voices outside of Martin's ones and others who don't like the new UI update and thus wanted to make a case for a carefully measured UI customization.

It also feels like you are ignoring this very demand. You say "We don’t really have the authority to conclude that rounded corners aren’t a “thing” in Windows.". I and others weren't calling for throwing out this UI push in the recent days, but to follow your own design talk on twitter of "including users" and not excluding them. We asked for an option, not a reversal of the move. Yet, so far, we didn't get much of an acknowledgement outside of "The option to provide user setting to have corner rounding something user can choose from is an interesting one. However it also has a lot to do with this feedback over other important features that we have to weigh against in Windows system as a whole.". I guess that's a start, but where are we now?

You say you don't have belong to the actual team with authority over the Windows design. That means we all have been speaken to the wrong person all along! If we never talked to a member who is in the team actually calling the shots, I wonder why you couldn't have said so sooner.

I'm disappointed, after all the energy invested, to now learn that I never talked with someone with authority to begin with. That basically all the feedback and I others gathered, making the case for UI customization will basically result into nothing (because you aren't even a person whe need to convince).

I'm sorry, I just can't wrap my head around it. A member of the Windows Fluent Design Team on the repository supposedly driving Windoiws UI now tells us after days that we never talked to a person that really mattered.

Sorry if this comes down as a rant, but I'm a bit shocked here. You might not know how much I invested into this particular discussion (and others who wrote passionate replies), but I'd like to ask for clarifications.

Where does our call for UI customization now actually stand? Does this repo really matter any longer for Windows UI discussions?

I'll leave it with:

"[WinUI 3.0] The native UI platform of Windows WinUI is the highly-optimized native UI platform used to create Windows itself, now made more broadly available for all developers to use to reach Windows. It's a thoroughly tested and proven UI platform that powers the operating system environment and essential experiences of 800+ million Windows 10 PC, XBox One, HoloLens, Surface Hub and other devices."

[mdtauk]

@Felix-Dev I hoped to influence, not insist my designs become the actual designs. I am a designer who has been a Windows enthusiast since the Windows Vista/7/Zune/Windows Phone days.

[Felix-Dev]

@mdtauk Indeed, although you certainly would have nothing against MS adopting your ideas, right? 😉 After all, you are convinced of them!

Sorry if it came around as you being pushy (and to be fair to me you also said so your proposals could come over like that), but the reply of @chigy was quite a shocker for me. Hope you can understand!

[mdtauk]

WinUI team != Windows Dev team.

Windows 10 is the current OS, but Windows Lite and Windows Core OS are the future directions.

@chigy is obviously looking at what the Windows Team is planning to do to the OS Shell, and wants to make sure WinUI 3.0 will look at home there. Windows apps like Calculator, Settings, the Taskbar Flyouts and Shell etc, will probably all use WinUI 3.0 so they will need to be on the same page, design wise.

The Fluent Design team at Microsoft make the rules (colours, font styles and sizes, materials, etc) that other Microsoft teams follow like WinUI, Windows, Xbox, Office, Bing, Teams, Fabric, Fluent Web with their UI design work.

I am sure I will be corrected if I have mis-understood the structure here.

My ideas that I have been contributing to this repo - have been trying to bridge the gap between Fabric Web and WinUI 3.0 - I have also included thoughts I have been mulling over since the Win8 days.

[Felix-Dev]

Clarification would indeed be nice, because here is how I understood it:

@chigy is a member of the Windows Fluent Design Team and with FD (Fluent Design) being the design language of Windows 10, she will thus be a member of the Windows Design Team.

Then there is WinUI 3.0 which has officially been described as as the platform which drives Windows and is used to create Windows itself. So Windows UI design discussions do feel at home here. Also based on the above description, it would mean the Windows dev teams will use WinUI to realize both apps and the system UI. Otherwise, it needs to be pointed out explicitely in those UI proposal threads that you won't talk to a person who actually matters and the proposal is really only about feedback on the actual implementations and not about the UI design.

And even if the Windows Fluent Design Team and the WinUI team are not the teams where native Windows UI is designed and realized in, it doesn't chanage the fact that @chigy never informed us that we never talked to someone who actually matters. We invested time and energy (you with your control concepts, me with trying to gather feedback, both us having lively discussions and not to forgoet all the others who participated passionately) when in the end we never talked with an actual Windows UI team member, someone we could actually try to convince of our ideas and beliefs.

[Neptune-mk2]

We don’t really have the authority to conclude that rounded corners aren’t a “thing” in Windows. In other words, rounded corner is already a plan, and so we wanted to make you aware and consult with our WinUI community to make sure that we implement this capability responsibly. Hope that makes sense.

Well this is a massive disappointment for me, like others stated its a huge issue for many of us, so if you have no leverage over this may I politely ask @chigy : Who is the person we should be speaking with? If not how can we make our voice heard over this clearly controversial UI change that many of use dislike?

This is very similar to the discourse that happened during Windows 10's development years ago when there was a proposal to make Square profile pictures into Circular ones, many people again disliked this and went to the feedback hub. There were multiple posts in the feedback hub with more that 1000000+ upvotes of support, asking for this not to be done.

The response was essentially just again telling people the change is going to be done regardless of their opinion...