-
Notifications
You must be signed in to change notification settings - Fork 678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Refine Light and Dark ThemeResources - Use Pure Black for OLED only #807
Comments
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 |
Regarding dark theme color shades, the Material Design docs have the right idea (as mentioned by @mdtauk):
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:
|
@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
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.
|
@mdtauk Looks like a perfect color compromise to me! |
Care to elaborate on your down vote/confusing reaction? |
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. |
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.
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. This may be a more global option if it is felt that the light theme would benefit from this colour blending also.
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.
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.
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.
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
|
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) |
Having a choice for options for Light, Dark, and Black would be the easiest. Light (Currently) When it comes to OLED screens, having Black as a choice is a must. |
@shaheedmalik |
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. |
Something to add to the idea of having two dark modes in the system: 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. |
@shaheedmalik 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. |
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.
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. |
@KyleNanakdewa 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. -- |
I am going off around what the actual apps are using.
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. |
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. |
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. |
Speaking of, it would be neat if apps and websites tried to avoid pure white and pure black and reserved that for content. |
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. |
@KyleNanakdewa 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.
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.
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.
Can you clarify which perspective you are describing here? The user perspective or the dev perspective? So, to put it together: |
This is literally the exact primary purpose of theme resources, which is what we're discussing here. 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. |
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. |
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. |
100% this - and while fixing the problem with pure black, let's consider these colour blends, to add a little polish to these themes! |
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/ |
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. |
This contains suggestions to move these discussions forwardHello everyone, 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!
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?
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.
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! |
@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. |
@mdtauk ,
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. |
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:
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.
OLED detectionThis 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 appsThis 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. |
@chigy, you're right: providing extra themes and OLED screen detection are separate topics.
Thanks again for the response 🙂 |
Is there any progress/direction on this? I've been messing around with WinUI 3.0, and by default dark mode is jet black, which is hugely different from everything else in the OS now that Windows 11 has released. I was under the impression that the goal of WinUI/UWP is to get developers creating applications that fit the OS visual design, but it seems at the moment that it does the opposite. |
@JamesLear92 , yes as a matter of fact, we updated colors of WinUI controls. We made the change to WinUI 2.6 and this change is going to be available to WinUI 3 soon. Due to schedule coordination, we haven't had chance to introduce this in WinUI 3 yet but is coming. Please see the change from design perspective: |
@chigy |
@JamesLear92 , actually, it is already available in the latest preview build. There are some bug fixes that are coming with 1.0 GA which is just around the corner. |
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
Scope
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
The text was updated successfully, but these errors were encountered: