Microsoft-ui-xaml: Proposal: Refine Light and Dark ThemeResources - Use Pure Black for OLED only

[mdtauk]

Proposal: Refine Light and Dark ThemeResources

There has been a lot of feedback in the FeedbackHub about making changes to the Dark Theme colours to move to using a Dark Grey base colour instead of a pure black #000000.

This would work well on LCD displays like those commonly used on Desktop PCs, but would negate some of the power saving effects that Black gives for (AM)OLED displays commonly found on mobile devices.

Xbox already uses a specialised range of colours which avoids pure black and white which is beyond the non HDR range of television colour gamuts. Apps from Microsoft like OneNote which has Dark Theme support avoids using pure black and so has to override the default DarkTheme resources.

Summary

My proposal is that with WinUI 3.0 these Light and Dark ThemeResource brushes be re-examined and some mechanism be found to detect the display type and provide adjusted colours on OLED devices.

Rationale

• Moving to a Dark Grey base will avoid "glowing" artifacts around light coloured elements;
• Fluent ThemeShadows will show up for elements with elevation translations;
• White on Dark Grey avoids some eye strain;
• There is strong support for this change in the Feedback Hub;

Scope

| Capability | Priority |
| :---------- | :------- |
| Change the XAML ThemeResources to use Dark Grey as a base | Should |
| Allow OLED devices to use pure Black as a base | Could |

Important Notes

Dark Modes on other platforms avoid using pure Black as a base colour, and have special affordances to refine the colours used by the mode.

macOS Mojave uses a dark grey but then takes the predominant colour from the desktop background and then blends it into the colours to give a refined palette which blends in nicer than pure neutral greys.

Android Q is getting a dark mode, which specifically lightens the background colour of elements as they increase in elevation in order to give a sense of layer depth and heirachy

Office apps like OneNote also avoid using a pure black base colour, and that team's use of depth and subtle shadows were influenced by the Fluent Design guides, and so Windows should probably take note of this.

FabricWeb from the Office team, as well as the new Edge built on Chronium, also have moved away from using entirely neutral shades of Black > Grey > White - in favour of a warmer tone.

---

EDIT: I have made an image to demonstrate how the ThemeResources could work with these blended Base colours with the Dark Theme

EDIT: Also whilst there is no outcry for changes to the Light Theme, Here is how the same blended approach could work for it.

Open Questions

This whole topic is an open question. So I propose this to be as much a discussion as to the merits of the change, as well as how to implement it.

Should the Light and Dark themes use the warmer tones chosen and recommended by the Office and Fabric teams?

Should the Accent colour or the automatically detected colour from the wallpaper, be used to blend into the Dark Grey to White shades of colour, similar to how Apple's macOS Mojave Dark Mode works? This could help the dark app windows blend and sit more comfortably on the screen...

I am mentioning here @RudyHuyn who posted a poll and discussion on twitter.
https://twitter.com/RudyHuyn/status/1135968903585181696

Also mentioning @JeGentle who called out the Collection in the Feedback Hub asking for a Light, Dark, and Black theme for Windows.
https://aka.ms/AA1dxxf

[Felix-Dev]

I'd like to see any newly proposed standard dark color demonstrated in Settings and Security app of Windows 10. Below are pics of how they currently look:

For the settings app, there is a nice color contrast between the navigation pane on the left and the actual content on the right, something I'd definitely want to be preserved.

In case of the Security app not only do we still have the above color contrast (btw the navigation view should really be extended into the titlebar to match the Settings app) but we also have a powerful contrast between the dark background and the status color (green, yellow, red) for each security section, making them stand out which is desired here.

With those two examples above, any change in dark color should be subtle (looking at your color table above at most Gray200 I'd think - but even then I'd like to see that color in action for the apps above first before making a verdict).

I also don't think the dark/light theme color should be influenced by the current wallpaper. For one, just have one light/dark theme and don't introduce more variations again if what you want is consistency in the system. More importantly, however, the system has no control over the frequency of wallpaper switches. If a user decides to have a new background every minute, you'll end up with extremely irritating theme changes every minute as well.

[mdtauk]

The way macOS handles it's dark mode colour blending is not exposed as options for the user, but when dark mode is on, it then automatically tints the colours

[kmgallahan]

Regarding dark theme color shades, the Material Design docs have the right idea (as mentioned by @mdtauk):

Higher elevation, lighter surface
The higher a surface’s elevation (raising it closer to an implied light source), the lighter that surface becomes. That lightness is expressed through the application of a semi-transparent white overlay.

Although I'm not sure that a 'semi-transparent white overlay' is the best approach, beyond just using notion of it to decide on which shades of grey to display.

The UWP Fluent Design docs do go over the importance of elevation & visual hierarchy, but only in reference to how shadows are impacted by z-depth. The brief dark theme section also doesn't mention color usage in regards to elevation.

So something to consider with this conversation is if dark theme colors should be tied to z-depth, similar to how shadows are handled via ThemeShadow. This does introduce a couple of important questions:

• How to best assign colors to z-depths, including upper and lower bounds + default height?
• Should color transitions be smooth if/when z-depth changes are animated?
• Should composition lighting be used to change the shading (complicated by application to content vs background)?
• Should this only impact dark theme colors or light as well (and how)?

[mdtauk]

@Felix-Dev I used the Live Visual Tree while debugging to make some tweaks to the Settings app, I am using a very Dark Grey instead of Black and I think it looks fine

• I took my wallpaper and used the Average filter in Photoshop to get an average pixel colour #8b8cab
• I then added a black layer on top and changed the opacity to 90% and then took that colour to use to replace the pure black in the example above. #0e0e11
• Then I tweaked some of the controls to add the corner rounding that is coming with WinUI 3.0 and tweaked some font styles.

Here is black and the new colour side by side.

And here is the Acrylic fallback colour which is 10% lighter than the base dark colour, I think the contrast still works well. #272729

---

As for elevation, I think these will have to be provided as XAML brushes generated by the OS, rather than actually manipulating the colour at the rendering or composition level. The Z-depth Translation value could be linked to certain brushes, maybe even make it a XAML property, instead of having to do it all in code.

<Grid Elevation="03">
</Grid>

[Felix-Dev]

@mdtauk
Thank you for providing me with a chance to see how a darker gray would look like! I agree, it still looks good to me and as such that would be a color value I definitely would agree on (in fact, I barely notice a difference in the settings app 😃)

Looks like a perfect color compromise to me!

[Felix-Dev]

@Shaheedmalik @crse

Care to elaborate on your down vote/confusing reaction?

[mdtauk]

Here is an image showing how the various shades used by the controls, and the Elevations would work with the blended Dark Base Colour.

[KyleNanakdewa]

Is this something that would be OS-level? Essentially an additional mode, a "neutral dark" in addition to the existing light and dark modes? If the true black stays for OLEDs, I assume this is how it would need to be done.

My personal preference would be to keep the true black for all displays. I find dark grey to be incredibly hard on my eyes - more contrast is better. It's cleaner, sharper, easier to decipher colours (that first OneNote pic, the purple text is barely readable), and overall much easier to read. The Office apps and the new OneNote are some of the only apps that I don't use dark mode with - I can't stand the grey. Too hard to decipher UI elements and text.

Having 3-4 system-wide modes would be a valid option. This is already pretty common - Office desktop apps and Adobe apps both have 4 modes: black/dark > medium dark > light > all white. It would satisfy all users, and wouldn't be any harder to support in an app than the existing two modes are.

I'm not seeing a huge rationale for dark grey - it might serve as a "transition" for people used to light themes, but doesn't seem to have actual notable benefits. If eye strain is the concern, would not dimming the entire screen (and thus reducing that contrast) be a more logical option? I don't really see how "absence of light" is the issue here...

Most Fluent graphics (the new ones they just rolled out across Windows Dev Center) are using gradient colours on true black. If bold colour effects are going to be common in UI, that also needs to be considered.

I do like the idea of having lighter shades for transient UI and other elevated elements, it does provide useful visual hierarchy. Would light theme get the inverse (darkening with elevation increase), or would it continue to rely purely on shadows? Currently, all elevated surfaces are the same shade of grey with the light theme. Having different shades might help there too.

As for shadows... they do help with visual hierarchy. But again, I don't think slightly lightening the background would solve that. The effect would still be far more subtle than it is for light theme. The dark theme may need an alternate method, similar to how Reveal highlights are dark on the light theme. Perhaps an "underglow" effect, similar to Xbox's Reveal Focus (but desaturated)? Something like the element floating over the light, if that makes sense? Not sure.

The tinting/blending idea from macOS is interesting, but I think Acrylic already covers that effect. Any place that would benefit from that effect, would likely benefit from Acrylic.

[mdtauk]

Is this something that would be OS-level? Essentially an additional mode, a "neutral dark" in addition to the existing light and dark modes? If the true black stays for OLEDs, I assume this is how it would need to be done.

My proposal would be just using this new approach with the existing Dark Theme - but an OEM making a device with an OLED screen, would be able to tell the OS, and it would use pure Black in that circumstance. The display tech, would dictate that option.

My personal preference would be to keep the true black for all displays. I find dark grey to be incredibly hard on my eyes - more contrast is better. It's cleaner, sharper, easier to decipher colours (that first OneNote pic, the purple text is barely readable), and overall much easier to read. The Office apps and the new OneNote are some of the only apps that I don't use dark mode with - I can't stand the grey. Too hard to decipher UI elements and text.

Having 3-4 system-wide modes would be a valid option. This is already pretty common - Office desktop apps and Adobe apps both have 4 modes: black/dark > medium dark > light > all white. It would satisfy all users, and wouldn't be any harder to support in an app than the existing two modes are.

This would be another way to approach it, by making an additional mode or even a Toggle checkbox which shows up when the App mode is set to Dark.
[X] Adjust colours to avoid eye strain
_or perhaps something like_
[X] Use neutral theme colours

This may be a more global option if it is felt that the light theme would benefit from this colour blending also.

I'm not seeing a huge rationale for dark grey - it might serve as a "transition" for people used to light themes, but doesn't seem to have actual notable benefits. If eye strain is the concern, would not dimming the entire screen (and thus reducing that contrast) be a more logical option? I don't really see how "absence of light" is the issue here...

Pure black on a desktop screen causes white text and elements to exhibit a "halo" glowing affect, as well as making shadows impossible to see for elevated elements. It also causes Windows to appear totally transparent on Hololens, and can be painful to read text on - in the same way that pure white backgrounds with black text causes eye strain over time, and in darkened rooms.

There are design studies that probably have more qualititive arguments, and I am sure there are usability studies. The arguments for using pure black as a base colour, are mostly the battery benefits on OLED devices, and aesthetically blending into the bezels on black electronics.

Most Fluent graphics (the new ones they just rolled out across Windows Dev Center) are using gradient colours on true black. If bold colour effects are going to be common in UI, that also needs to be considered.

I took a look at the Windows Dev Centre dashboard and site, and in Dark Mode, the base colour is actually #1e1e1e and not pure black.

I do like the idea of having lighter shades for transient UI and other elevated elements, it does provide useful visual hierarchy. Would light theme get the inverse (darkening with elevation increase), or would it continue to rely purely on shadows? Currently, all elevated surfaces are the same shade of grey with the light theme. Having different shades might help there too.

Lighter shades for elevated surfaces would require guidance to pick appropriate brush resources or some kind of mechanism to take the XAML brush colour applied to the element, and an adjusted colour be applied to the element.

As for shadows... they do help with visual hierarchy. But again, I don't think slightly lightening the background would solve that. The effect would still be far more subtle than it is for light theme. The dark theme may need an alternate method, similar to how Reveal highlights are dark on the light theme. Perhaps an "underglow" effect, similar to Xbox's Reveal Focus (but desaturated)? Something like the element floating over the light, if that makes sense? Not sure.

I believe elevated elements should use a dark outer, and lighter inner border, which would do a lot to help reinforce this fact, and help mitigate the harder to see shadow. The Light border is subtle in a light theme where as the shadow is strong, and in Dark the light border stands out more.

That again is a guidance issue. Perhaps it could be made a material in the same way as Acrylic and Reveal. Perhaps Elevated and Acrylic Elevated

The tinting/blending idea from macOS is interesting, but I think Acrylic already covers that effect. Any place that would benefit from that effect, would likely benefit from Acrylic.
Acrylic is used for transient surfaces and shows elements behind - but has performance implications. The colour blending I am suggesting is Opaque and is no different to the current brushes, only the colour values have a tint applied, either taken from the Background wallpaper, or using the Accent colour.

[Felix-Dev]

I'm all for user personalization choices, and a recent poll which asked if users would prefer pure black or a darker gray was pretty close (52% for a "very dark gray background" with 48% for pure black with a total vote count of 2422).

@mdtauk did post an example color above which isn't pure black but still provides good contrast IMO. If the new dark color is set to a lighter gray, however, I'd definitely call for an additional theme option to be added to the system: "black" (#000000), "medium dark" (tbd) and "light" (possibly as it is now).

To sum it up, having two dark-themes to choose from seems like the way to go: "black" (#000000) (would probably be up for a color very very slightly lighter too) and "medium dark" (tbd), with "medium dark" addressing those who prefer a slightly less black theme color.

(Reference to the poll here: https://twitter.com/RudyHuyn/status/1135968903585181696 - already posted by Martin above)

[shaheedmalik]

Having a choice for options for Light, Dark, and Black would be the easiest.

Light (Currently)
Dark (Currently)
Black (#000000)

When it comes to OLED screens, having Black as a choice is a must.

[Felix-Dev]

@shaheedmalik
I'm not sure what you mean with "Dark (Currently)"? The current (base) color used by the "Dark theme" is pure black (#000000). (As seen by the Settings/Security app and also when creating a new UWP app with the system-provided black theme.)

[shaheedmalik]

@shaheedmalik
I'm not sure what you mean with "Dark (Currently)"? The current (base) color used by the "Dark theme" _is_ pure black (#000000). (As seen by the Settings/Security app and also when creating a new UWP app with the system-provided black theme.)

That's not the current base for Dark Mode. In fact, those apps haven't been updated since to reflect current dark mode.

Dark mode (around #373737) is currently reflected in apps such as the Feedback Hub.

[Felix-Dev]

Something to add to the idea of having two dark modes in the system:
As with many things it will be up to the developers to provide support for themes in their apps. Currently, with a single "dark" theme each developer can still provide his own version of it (compare OneNote app/ToDo app/Settings app). After all, there is no specific color associated with the "Dark" setting in the Settings app.
However, once we add more themes and even start to strictly bind them to a color, such as "Theme Black" (#000000) or "Theme LightGray" (some Light Gray color value) app developers might choose to not provide support for this particular theme because it wouldn't fit well with the overall look of their app.
That would introduce a whole new set of problems, i.e. a user sets the theme to "pure black" just to find out it won't get respected. Compare that to the current liberal description of just "Dark".

So, once we add more theme options and/or tie themes to specific colors there could be a risk of disgruntling users because not every app or system component they will use on the system might have support for that particular theme. One could argue this is alreadythe case today (not every app has a dark or light mode) but adding more options could increase the scope of this limited-support problem.

[Felix-Dev]

@shaheedmalik
I just created a new UWP test app targeting the newest SDK (SDK 18362). Setting the requested theme to "Dark" gives me a base color of pure black (#000000).

So according to that, the feedback hub is using its own dark theme.

[mdtauk]

@shaheedmalik
I just created a new UWP test app targeting the newest SDK (SDK 18362). Setting the requested theme to "Dark" gives me a base color of pure black (#000000).

So according to that, the feedback hub is using its own dark theme.

The Store also uses a different colour - I suspect this is because it was a mistake having Black as a base in the first place - but that leads to the problem of the Store on Windows 10 Mobile now being in grey instead of Black.

If the Dark Theme is updated, those apps need to move to the new default.

[KyleNanakdewa]

My proposal would be just using this new approach with the existing Dark Theme - but an OEM making a device with an OLED screen, would be able to tell the OS, and it would use pure Black in that circumstance. The display tech, would dictate that option.

There is already an option for OEMs to specify OLED - it's used for taskbar transparency. This is hidden from users, by burying it in the registry. Since opinions seem pretty split on this, might be better off surfacing the option in the Settings app. The OLED option could still be used to set the default.

Also the Fluent site I was referring to was this one with the new Fluent logo: https://docs.microsoft.com/en-us/windows/uwp/design/ (the logo is on a background that shows as #000000 in Photoshop for me). What I was specifically referring to, we haven't seen it yet in actual UI, but the use of colours.

Anyways... for built-in elevated controls like MenuFlyout, I suppose they could take the theme resources for shading - not sure if such resources are already present. These already take on both light and dark styles automatically, so no additional work there (assuming that darker=higher works for light theme). For custom controls, they can just use these resources as appropriate. I suppose it could just be tied to the app's set z indexes (as I believe the new drop shadows are), but that might be undesirable if it affects all controls.

The border colours is definitely something that needs to be standardized. In the Windows taskbar alone, there are at least four different border styles. A light+dark border would be great for ensuring clear separation, especially for transient UI.

However, once we add more themes and even start to strictly bind them to a color, such as "Theme Black" (#000000) or "Theme LightGray" (some Light Gray color value) app developers might choose to not provide support for this particular theme because it wouldn't fit well with the overall look of their app.

Developers don't set colours right now. It takes 0 extra work to support an additional theme. The OS handles everything.

Right now you pick out preset theme resources, which are like different shades. The OS will automatically pick out colours based on the user's chosen theme, and then use whatever shade was specified. i.e you specify "background colour" and the OS will automatically put white (for light) or black (for dark).

The current mess of shades is because of apps (seemingly) disregarding this behavior. Clearer guidelines might help. There isn't really any clear indication of what shade to use where, just that apps should use the theme brushes: https://docs.microsoft.com/en-us/windows/uwp/design/style/color#using-theme-brushes

A proposed "medium dark" theme would apply to existing apps with 0 changes. Apps are allowed to request a specific theme - presumably any that currently request Dark can continue using the current dark theme, to avoid any visual issues that'd require changes.

[Felix-Dev]

@KyleNanakdewa
My point was that for each app developers might think a modified theme is better suited than the default-provided ones. With helper apps like the Fluent Xaml Theme Editor, you can easily modify brushes present in all those themes and thus create your own "Light theme" or "Dark theme". That's how you get a different black color in apps like Feedback Hub compared to the Settings app, and the ToDo app for example uses yet another set of values for its dark theme. Not because of the OS but because the devs created their own set of colors for a theme. And they did so because they thought the default theme wasn't perfect for them.

Same applies to any new theme to be added. We have no gurantee devs will actually support such a theme, especially if tied to a specific color, (or even more than two theme options), so we add new options which might not be applied everywhere the user would expect it (thus creating user complaints).

That's what I like about the current choice. You have all those different apps, each with their own dark theme version which the devs think is best suited for the kind of content their app displays, and yet all those apps have a "dark theme". The moment themes with specific colors can be selected in the Settings app for themes, you might not get fully support for it across First-Party and Third-Party apps.
(Of course, that is also prone to user complaints about each app having a different dark theme.)

--
Anyway, I'll be away this weekend so I likely won't be able to reply to things getting pointed out.

[shaheedmalik]

@shaheedmalik
I just created a new UWP test app targeting the newest SDK (SDK 18362). Setting the requested theme to "Dark" gives me a base color of pure black (#000000).
So according to that, the feedback hub is using its own dark theme.

I am going off around what the actual apps are using.
I have checked like three apps and I saw, 1E1E1E, 373737, and 363636.

@shaheedmalik
I just created a new UWP test app targeting the newest SDK (SDK 18362). Setting the requested theme to "Dark" gives me a base color of pure black (#000000).
So according to that, the feedback hub is using its own dark theme.

The Store also uses a different colour - I suspect this is because it was a mistake having Black as a base in the first place - but that leads to the problem of the Store on Windows 10 Mobile now being in grey instead of Black.
If the Dark Theme is updated, those apps need to move to the new default.

At this point all of the Inbox apps have to be rethemed. Dark being black and all the apps having varing degrees of gray proves that they are all off template. And have been for a while.

[KyleNanakdewa]

It's possible that the developers of these apps preferred (for whatever reason) the grey (over black), and thus decided to create their own theme for it. Therefore, if such a theme was available in the OS, they might update their apps to remove the custom theme and revert to the standard/recommended theme resources.

Of course that's just speculation. We don't know why apps like the Store went with grey instead of black... but they (probably) wouldn't need to write their own theme if there was one built-in.

[shaheedmalik]

It's possible that the developers of these apps preferred (for whatever reason) the grey (over black), and thus decided to create their own theme for it. Therefore, if such a theme was available in the OS, they might update their apps to remove the custom theme and revert to the standard/recommended theme resources.

Of course that's just speculation. We don't know why apps like the Store went with grey instead of black... but they (probably) wouldn't need to write their own theme if there was one built-in.

The developers of those apps is Microsoft. Since there wasn't a universal theme for dark gray, it looks like each theme did a gray updated without talking with the other teams and making a new template.

[mdtauk]

Of course that's just speculation. We don't know why apps like the Store went with grey instead of black... but they (probably) wouldn't need to write their own theme if there was one built-in.

The developers of those apps is Microsoft. Since there wasn't a universal theme for dark gray, it looks like each theme did a gray updated without talking with the other teams and making a new template.

We can assume there was a dislike of the pure Black, and so it was changed. The Store also updated it's Light Theme to use a light grey to match their website colours.

Eitherway apps using default theming, would get the updated colours. This change should probably apply to WinUI 3.0 and beyond.

[Poopooracoocoo]

Speaking of, it would be neat if apps and websites tried to avoid pure white and pure black and reserved that for content.

[cherepets]

A lot of apps are currently providing own personalization options.
I think it indicates lack of the system options. 4 themes like "black", "dark", "light", "white" could cover most preferences.
I'd really welcome such change as a user and would be also happy as a developer because I won't need to implement it myself in my apps 😃

[Felix-Dev]

@cherepets
And that's the issue. Providing a small set of pre-defined themes perhaps won't be the solution as you might imagine it to be. To quote someone from twitter:

Before that, let's start simple: 171717, 1e1e1e, 262626, 000000, 363636. These are the hex codes for the "dark" background color in 5 Microsoft apps: News, windows settings, Visual Studio, Word, Edge/Chromium.

As you can see, 5 MS apps with 5 different dark theme base values. Now count in all the third-party apps as well where each app might want to use its own base theme value.
As I said above, the issue I see is that Windows does not know which color combination works best for apps. Hence adding specific themes, such as "black", "white",... might introduce UI options which won't get respected anyway. So, you will have an app where the developer says "black", "white",... are not desired because of how the app is designed. A user, however, sets that theme in Settings, then uses such apps and will start complaining why his preference won't get respected.

To put it differently: It's up to the developers, not Windows, to determine which themes an app will look good with and which it won't.

That's what I like about the current setting. All those 5 MS apps use their own dark theme, but it is still a "dark theme" nonetheless. Thus, the user preference gets respected by all those apps.

[cherepets]

@Felix-Dev Ok, 5 apps now have different themes. That means that at least 4 developers did create theme manually and that every user is unhappy about at least 4 apps. I wouldn't say it sounds good.
Personally I prefer #000000 and think that other apps look dirty so I rarely use apps like News of Xbox Companion.

[Felix-Dev]

@cherepets
Black does look nice in Settings/Security app. I'm also fine with the much lighter gray used in the MS ToDo app.
The problem is that to a great extent every developer picks his own dark theme which he thinks looks best for his app. That won't go away even if more theme options in the UI are introduced. Either you provide customization for developers or you have to make it "hardcoded". And with MS big on enabling easy branding of apps, you will never get consistency anyway. More options could instead make the current situation worse as seen with the example above - devs opting not to support some options, thus ignoring user preferences, which the user will never like to see.

Such as it is today with devs having to opt-into respecting theme preferences by the user (it can always be ignored) at best I feel app developers could be advised to provide more theme options, such as a black one, a lighter gray and a light one (or more). In the end it will be up to them how far they will go.

[KyleNanakdewa]

The reasoning for different apps using different shades of grey seems pretty obvious - there is no established standard whatsoever. They're using different shades because there's no guidance on what grey to use, not in spite of it.

The chosen shade of grey is rarely, if ever, a branding choice. I cant think of a single case where the specific shade of grey is relevant to an app's identity.

If a specific app cannot achieve necessary contrast using the existing theme resources, I would say that's a failing on the part of that app's developer - the app is already supposed to be designed to adapt to the theme resources, given that they change between light and dark themes. If it is truly necessary for a specific app or control, hard coded colours continue to work, or the theme resources can be overridden if such a specific change is needed on a larger scale. This is nothing new - it has been part of Windows 10 from the beginning.

Also worth noting that the suggested change (dark grey backgrounds) is not massively different than the existing black. If an app is negatively affected by having to adapt to both colours, it likely had poor contrast from the start. This isn't a drastic change in colours.

[shaheedmalik]

The reason the gray those apps are inconstent is because each team did those changes off template. And customers complained about it. (I know I did.)

It had nothing to do wanting a different choice.

[Felix-Dev]

@KyleNanakdewa
You say "there is no standard". Well, the thing with standards is that you reduce dev choice without having any idea about the branding/content of apps. The work done by the Windows Team (Fluent Xaml Theme Editor,...) is all about supporting dev customization so they can create their own themes. Windows shouldn't be in any position to dictate how apps will have to look like color-wise.

And we've just seen how that turns out because I'd argue there indeed is a standard: the default color black. As written above, out of the box, the base color for the "dark" theme is black! Yet we still have devs which went with it and others who went with a whole set of other base values.

So, perhaps to clarify your point: How would you think a standard should look like? What makes you think the standard will be followed by others? Why not using a lighter or darker gray? Why do I, as the dev/designer of an app, have to use that gray color? A standard only makes sense if it's broadly used and there should be made no such assumption in this case here.
Just to hammer it away again: In all those custom dark themes many different gray values were used. There seemingly is not a single gray color able to come even close to be used by a simple majority of apps.

The chosen shade of grey is rarely, if ever, a branding choice. I cant think of a single case where the specific shade of grey is relevant to an app's identity.

It's not about the base color but about the whole look of an app. Depending on the colors chosen to reflect a branding (such as foreground color), one kind of gray/black might be better suited than others. The base theme color might not be starting point of a custom theme design process but it certainly will play a role at some point. It's not up to Windows to decide which kind of gray works best with other app colors.

Also worth noting that the suggested change (dark grey backgrounds) is not massively different than the existing black.

That's true and I said previously, I'd be up to such a change. That hasn't been my issue here anyway. Changing the base color of the dark theme to a subtly lighter color won't address the issue above, you will still have devs who will think black/an even lighter gray is better suited for their apps and no one should tell them they can't chose their own app theme. The problem of different dark themes will still exist.

@shaheedmalik

It had nothing to do wanting a different choice.

Can you clarify which perspective you are describing here? The user perspective or the dev perspective?

So, to put it together:
At the end of the day, you will still have all kinds of different grays used in apps. It's not up to us to speculate the reasoning behind modified themes for apps. Fact of the matter is, we have all kinds of dark colors in use today and I fail to see why a small set of pre-defined theme values will make the situation any better (and as I argued above I think it will make it worse) The base color to use is dependent on many factors and some of those factors cannot be decided by Windows nor should they be.

[KyleNanakdewa]

Windows shouldn't be in any position to dictate how apps will have to look like color-wise.

This is literally the exact primary purpose of theme resources, which is what we're discussing here.
https://docs.microsoft.com/en-us/windows/uwp/design/style/color#using-theme-brushes

The whole idea of this proposal is to change the choice of colour, as it is made available to apps in the form of theme resources. I'm not sure what you're getting at when you say this should not be determined by Windows, because that doesn't fit the context of this proposal.

Furthermore, many apps already support multiple dark themes - Office and Adobe apps are big ones, plus many existing UWPs - I use Nextgen Reader, Ouga, Skype, Quarrel, all of which support both a black theme (normal dark theme), and a grey theme. Currently, apps must supply their own definition of the grey theme - it would make sense to add a standard, similar to how we already have Dark, Light, and High Contrast themes. This would reduce the work needed by developers.

[mdtauk]

As @KyleNanakdewa has said there is a difference between what colours an app chooses, and what Windows provides.

At present, Windows has a Dark and Light theme, which then tells the app which Theme Resources to apply when the app is running.

When designing an app, they are provided as two ResourceDictionary XAML files included in the SDK. But those same colours, values, and metrics are included in the framework in memory for apps running.

So for the avoidance of doubt, I am talking about the Light and Dark Theme Resources provided by default, and not about preventing developers from overriding those styles.

Many of the apps made by Microsoft are perfectly happy to use the default Light Theme, but feel the need to customise the Dark themes. _I believe this is to avoid the use of pure black as a base colour._

With WinUI 3.0 becoming decoupled from the OS, it will fall on the framework to provide those new default styles for controls and the themes, and so I am suggesting improvements to the Dark Theme in particular, but open to seeing the same changes come to the Light Theme too.

Improvements which other platforms have made to their Dark Theme implementations, based on best practices, and hoping that all those apps who have chosen to "do their own thing" with their Dark Themes - will choose to return to the defaults if they address those concerns.

Netflix, the BBC, and Facebook will be free to use their own brand colours, and their own control designs and colours - to match their cross platform apps.

[shaheedmalik]

@shaheedmalik

It had nothing to do wanting a different choice.

Can you clarify which perspective you are describing here? The user perspective or the dev perspective?

So, to put it together:
At the end of the day, you will still have all kinds of different grays used in apps. It's not up to us to speculate the reasoning behind modified themes for apps. Fact of the matter is, we have all kinds of dark colors in use today and I fail to see why a small set of pre-defined theme values will make the situation any better (and as I argued above I think it will make it worse) The base color to use is dependent on many factors and some of those factors cannot be decided by Windows nor should they be.

All the Dark Mode apps started off at #000000.

Feedback requested a lighter Dark Mode, each team made a different looking dark mode. They weren't consistent.

Feedback complained about app consistency specifically of MS apps.

Had all the apps had guidelines for the exact same lighter dark mode color, the apps would have looked more consistent thus less feedback on app consistency.

What should have been done was a new universal color should have been discussed among the teams and new template should have been made. Apps retemplated = Consistency.

Let's fix this problem.

[mdtauk]

What should have been done was a new universal color should have been discussed among the teams and new template should have been made. Apps retemplated = Consistency.

Let's fix this problem.

100% this - and while fixing the problem with pure black, let's consider these colour blends, to add a little polish to these themes!

[shaheedmalik]

There's a thread on Reddit talking about this very issue.

https://www.reddit.com/r/Windows10/comments/c0gewl/i_tinkered_with_the_colors_to_try_to_match/

[Felix-Dev]

I'm skeptical here, after all, that was my whole point. Deciding on a new standard value which at least all the different MS teams with their apps have to follow - not sure there will be a solution. Apps are different, and thus some might want to have a certain gray color which won't be the perfect choice for other apps (see ToDo app vs Settings app with a navigation view and content pane, for example). If you start with a base color several apps use today and then you change it slightly because of the request of other app teams, you might get new complaints from the teams responsible for the former apps.

From my point of view perfect color match trumps consistency. If there are (MS) apps for which a darker/lighter gray is better suited for the displayed content than the "new universal color", those apps should always ship with that base color. If consistency means negative impact on in-app contrasts, it's not the way to go in those cases.

I'm interested in seeing how the process of finding the "new universal color" will go and how it will look for a variety of apps.

[chigy]

This contains suggestions to move these discussions forward

Hello everyone,
Thank you so much for very active and engaging conversation that is taking place in this proposal!! I am very happy to see the community engaged to provide us with valuable feedback and proposals for making our UX/UI better.

Let me introduce myself first for those of you who don’t know me already from other WinUI proposals. I also want to make sure I am super crisp on what I can and I cannot do.

I’m a PM in WinUI team. Currently, I play a role sort of an “interpreter” who distills user, developer, and design requests around UX/UI into specific features and propose changes that WinUI would make. I also generalize very specific design changes into changes that we can systematically and coherently make with the set of controls we offer. You could also view me as one of developer advocates specifically in design decisions that are made.

While I work very closely with many different design teams, I am not in the position to change design decisions that have already been made by respective organization. However depending on issues/proposals being raised here, it is possible for me to help influence design teams to take the idea into design considerations and/or modify the design if the impact to developer is significant.

As you can see, better I understand your ideas and issues, better I can be your voices in design discussions that happen here for WinUI. In other words, help me help you. 😊

That being said, let me help this group make a better case for the ideas being discussed here. Here are things you should consider doing when making proposals and discussions for design. Again, this helps me take your ideas to the right people better so I appreciate your help!

1. State the problem(s) you are trying to solve clearly. Depending on the problem, the solution and approach can be vastly different.
   _HINT:_ Providing evidence of the problems you are observing in real-life is a plus.
2. Rather than creating one single big issue, break them down into small, independently actionable issues.
   _HINT:_ If multiple issues make up one big feature, you could create one “master” feature and refer to smaller items.
3. If proposing design change for a control design that’s already well established, explain what the problem current design impacting our users and how the new design help solve these specific problems.

I’ve noticed that there are multiple problems being discussed here in this thread but I wonder if we all have the same problem in mind. Let me try to list out the problems I think I hear following from the series of discussion here?

• There are not enough theme options for USERS.
• There are not enough theme options for DEVELOPERS.
• USERS have different opinions as in what color of gray is better.
• DEVELOPERS do not agree with what color of gray is better for their application.
• Gray colors being used by Microsoft products are not consistent.
• Gray colors being used by non-Microsoft products are not consistent.
• It appears MacOS has better solution compared with Microsoft?
• Maybe more?

It would be very helpful if the group could come to consensus as to what the problem we are trying to solve here. Perhaps we are trying to solve multiple problems and it is OK. I just want to make sure I am understanding the problems and why we need to solve these problems before we start discussing any specific solutions for them.

• @KyleNanakdewa, @Felix-Dev, @shaheedmalik, @cherepets – I believe you all suggested we introduce more themes. Are we trying to solve a problem for users or developers or both?
• @mdtauk – It appears you suggested a separate feature of blending background that could be a stand-alone proposal?
• Many of you expressed frustration with Microsoft products not being consistent. I hear you and design teams are working together to make our applications coherent (as you heard from our //Build talk). There is nothing I can share here right now. As far as I could tell, the solutions being discussed here in this proposal did not feel like a silver bullet to solve this once and for all?
• @KyleNanakdewa, @Felix-Dev, @shaheedmalik, @cherepets, @kmgallahan, @Poopooracoocoo are discussing @mdtauk’s original topic of OLED detection/support. Would you help distill key problems you are trying to solve with this solution?

I’m sorry for a very lengthy post. FWIW, this is how we design and discuss design changes at very high level and having the community follow this similar model will help us take your idea into next step faster and with greater impact.

Thanks! Looking forward to your inputs!

[mdtauk]

@chigy Thank you for such a detailed response. Would you prefer I close this issue, and make a new one with a more detailed proposal, breaking things down?

I would suggest those asking for more than the Light and Dark themes, should make their own separate proposal, as they are not part of what I am proposing.

[chigy]

@mdtauk ,

@chigy Thank you for such a detailed response. Would you prefer I close this issue, and make a new one with a more detailed proposal, breaking things down?

Since you are the one who made the proposal to the original request, I'll leave it up to you to keep it to discuss the OLED topic or close and open new one. Though, you will need to remind folks to keep the conversation on point as this contains many different topics. If this conversation results in something I feel I can pitch on our side, I may end up creating a new one just so it is cleaner but we can think about that when it is at that point.

[KyleNanakdewa]

Yeah, there's a couple things being discussed here. Might be better to split this up.

Dark Themes (adding an additional theme)

It's looking like three themes may be the way to go forward, for the following reasons:

• Provides the neutral grey theme for users (or developers) that prefer this look.
• Makes it easy for apps/controls to support a refined/additional theme with no additional work, if they are already using theme resources - same as already supporting both light and dark themes in an app/control.
• Maintains the black theme for users that prefer that look.
• Maintains the black theme for OLED screens.
• Does not affect existing apps by changing their colours, as the black theme is still present.
• Still allows developers to override the existing themes and provide their own replacements (such as by using the Fluent XAML Theme Editor app), though they may need to provide three replacement themes now, instead of two.

This proposal would involve adding a third theme, in addition to the existing Dark and Light. Not sure how it could be named, possibly "Neutral Dark", or maybe rename the existing dark theme to "Black".

The theme would be very similar to the existing dark theme, but avoiding pure black.

While themes can be changed within an app, as they can be now, it would be best to have an OS-level setting for users to change the setting across all apps. This is obviously outside the scope of WinUI, but given the response in Feedback Hub, I think it's safe to say there's a demand for an OS-level neutral dark theme.

Dark theme (replacing the existing theme)

An alternate proposal is to outright replace the existing dark theme with more neutral greys.

• Provides the neutral grey theme, as the only option.
• Does not add an additional theme, so apps/controls just have to support the new dark theme, and can ignore the old theme entirely.
• Does not keep the black theme for users that prefer that look.
• No way to detect OLED screens and adjust accordingly - unless the theme resource is determined at runtime, but that's essentially just adding a third theme that needs to be designed for.
• Makes it easier for developers to override the theme and provide their own, as it's one less theme to override. As far as I know, currently a developer would need to replace each theme separately, so this could be a benefit.

OLED detection

This is also an OS-level feature. If a third theme is added, the OS could set the user's default theme based on the device. With this approach, it is 100% outside the scope of WinUI - it would simply set the default theme (black vs. neutral dark vs. light).

Colour tinting/blending (like from MacOS)

I think this is a separate proposal entirely. It would affect all themes (whether that's just light and dark, or a proposed additional dark theme), and thus isn't really related to the addition or refinement of dark themes.

Consistency across apps

This is more of a guidelines change than anything else. However, providing a neutral dark theme may help consistency, as currently devs have to design their own, if they want to add it. There is no set guidelines right now.

[cherepets]

@chigy, you're right: providing extra themes and OLED screen detection are separate topics.
Extra themes could solve problems for both users and developers:

• Developers will not have to implement their own lighter version of dark theme anymore
• User will get the colors they prefer in more apps

Thanks again for the response 🙂