microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.16k stars 668 forks source link

Proposal: Update WinForms, UXTheme and WPF default control styles to match WinUI and FluentUI #3559

Open mdtauk opened 3 years ago

mdtauk commented 3 years ago

Proposal: Update WinForms, UXTheme and WPF default control styles to match WinUI and FluentUI

Summary

There are rumours of a visual refresh coming to Windows 10/10X on or around build 21H2 of Windows next year. This effort will not be nearly as consistent and successful without the other major frameworks, adapting to match the fonts and stylings.

Rationale

Scope

Capability Priority
Non WinUI controls should adapt their control designs to fit better with the FluentUI designs Must
As many common dialogs and UIs as possible, should be updated to modern Xaml/WinUI designs Should
Reunion APIs could take over the rendering of apps using UXThemes and MSStyles to allow more flexibility and updating Could
Provisions should be made so apps can opt out of Reunion rendering, so it doesn't force all apps without opt in Won't

Important Notes

Open Questions

The version of the OS that moves over to this refreshed UI, should update the default control designs, but by open sourcing UXTheming, apps could bundle their own theme resources, or use pre-release versions as the design of Windows changes in the future.

How far should these theme updates go, without an opt-in or opt-out? WinUI uses a body font size of 14pt, but Win32 apps tend to use 9pt as it's baseline. Personally I think changes to metrics should probably be opt-in similar to how Use visual styles is an option for app devs. But colours and button corners and shadows etc, could be done without breaking UI layouts too much.

ShankarBUS commented 3 years ago

Related to microsoft/ProjectReunion#82, isn't it?

This one's a proposal and other's a question. Well... not a dupe then.

If UI/UX update doesn't breaking the layout of any existing applications, count me in. A opt-in as you said would be great!

But I doubt the new Update will look more like Fluent UI instead of WinUI due to the lack of Reveal, Acrylic and composition animations.

Your request is valid for Win32 and WinForms apps as the theme is tied up to the system.

But WPF however dosen't use the system's control styles directly. They have their own controls styles. As there is already a similar issue filed in WPF's repo https://github.com/dotnet/wpf/issues/1485, you could remove WPF from this proposal.

There are 3rd party libraries for WPF which incorporates Fluent Design (already mentioned in microsoft/ProjectReunion#82). So, WPF is irrelevant to this issue.

@Poopooracoocoo will be interested in this issue šŸ¤£. Let's see what MS do with this proposal.

mdtauk commented 3 years ago

@ShankarBUS There are currently proposals for updating the designs of the WinUI controls - to better align them to the FluentUI web control designs.

This is why I am proposing Reunion could be a place to consolidate efforts to bring better consistency between the UI frameworks and control designs.

Whether or not Acrylic and Reveal - when lifted from the OS, could be supported by more frameworks than WinUI, would not alter many controls like Buttons etc. The one area where consistency is needed most, but would require Acrylic, is ContextMenus.

Poopooracoocoo commented 3 years ago

Well my one was a proposal in the form of a question. :P Thanks for the mention, Shankar! :)

Microsoft doesn't have any reason not to as they use all of these old frameworks themselves. They cannot just tell other people to use MSIX, WinUI and UWP, and now Project Reunion, when Microsoft hardly uses them themselves. Let's look at a recent-ish example: Edge now uses Chromium and instead of changing shadows system wide, they decided to use a custom shadow for their menus. They don't even want to attempt consistency. I tried telling MS all of this in that GitHub issue and in the roadmap issue (which admittedly was off topic but I tried to get their attention). I doubt Microsoft will accept your proposal. They couldn't even understand that updating shadows, colours and corner radii wouldn't break anything, despite the considerable evidence: they have changed those themselves in Windows releases.

ShankarBUS commented 3 years ago

I do agree with you. I have seen recent changes in WinUI modifying some visual effects (such as removing tilt effect, proposals for removing/changing reveal?) to align with Fluent UI .

I like that they're making progress towards unifying Fluent UI and WinUI styles.

ContextMenus

Windows 10 squad agrees šŸ˜‚šŸ˜‚

JaiganeshKumaran commented 3 years ago

@ShankarBUS @Poopooracoocoo @mdtauk This is the new Fluent Design. It's nothing like the original Fluent. The reason why they are removing a lot of cool effects from WinUI to align with Fluent UI is that Microsoft no longer believes in native tech. Already Windows 10 uses lots of web components and I except "Sun Valley" to introduce more. Today the problem is these web-based junk don't look like native and these effects are hard to achieve on the web so if they remove them they can have a consistent design with less work. Let's not forget that they are now an Android OEM so they also follow Material and call it Fluent. If you didn't know Windows 10X is all about web tech. The start menu is web-based, the search is web-based, file explorer is web-based etc...

ShankarBUS commented 3 years ago

Even the new emoji picker and the new touch keyboard found in insider builds are also Web Based!

I hate web techs! But meh, I don't care.

JaiganeshKumaran commented 3 years ago

@ShankarBUS I'm not against any web technology and I actively develop web apps but Windows shouldn't become web-based. Already Windows 10 is a lot slower than 8.1 and many cheap laptops sold today are barely usable.

ShankarBUS commented 3 years ago

I too am not against Web tech used properly where they should be (PWAs, web apps, websites & etc). I too love and use Web Techs myself.

But I hate web tech used as UI for native stuffs! Who would use html for a native touch keyboard and OOBE?!!! It's silly and unprofessional for a tech giant to do!

Already Windows 10 is a lot slower than 8.1 and many cheap laptops sold today are barely usable.

Yes! This is the reason I hate electron based apps.

Use XAML! XAML is a MS product and if they don't even use it, why should others even care?

I'm sad that acrylic and reveal are slowly fading away from WinUI.

Ok, our conversation is getting out of topic. Let's get back to the topic before they kick us out.

We can't blame anyone, teams inside MS are so fragmented and each of them only care about work designated to them. Our conversation is useless in the sense of this repository.

stevewri commented 3 years ago

Not a Reunion (API) issue. XAML folks own comctl and WPF as well as the WinUI/Fluent story, so transferring this to their repo.

mdtauk commented 3 years ago

Not a Reunion (API) issue. XAML folks own comctl and WPF as well as the WinUI/Fluent story, so transferring this to their repo.

Really, the WinUI team own the Win32 Common Controls?

I can understand the Windows OS team owning UXTheme, but I am suggesting that could and should be open sourced so it can be iterated outside of OS updates

lorisobi commented 3 years ago

To allow better transition many winui controls need a compact sizing i think - as far as I know TabView, MenuBar, etc don't have it. I think compact sizing would fit better to some legacy programs, like task manager image

lorisobi commented 3 years ago

Any updates on that?

mdtauk commented 3 years ago

To allow better transition many winui controls need a compact sizing i think - as far as I know TabView, MenuBar, etc don't have it. I think compact sizing would fit better to some legacy programs, like task manager image

WinUI does support a compact density, but I don't think part of modernising these apps, is matching older sizing - the larger hit targets and font sizing is part of modernising, and supporting touch and pen too