Microsoft-ui-xaml: Proposal: Change color for MenuFlyout cascading menu

[sravya03]

Proposal: Change color for MenuFlyout cascading menu

Summary

Update the color when MenuFlyout opens the sub-menu to more subtle gray rather than accent color.

Rationale

• Bringing consistency to WinUI with what the Shell is already doing.

Scope

| Capability| Priority |
|:--|:-|
| Developers are able to use WinUI2.2* package and without any work, get the new Windows visual style. | Must |
| Developers and end users experience control update that feel coherent with the same controls used by Fabric, Edge, and Xbox. | Should |

*Timing here is not a commitment, but to follow the release cycle. Just using the next version #.

Design details and visuals

This impacts only ContextMenu's cascading state.
Visual Comp

Important Notes

Open Questions

• Does this require OS level changes or can we do this in WinUI?

[mdtauk]

I believe the top most flyout gets the accent colour, as it is currently selected and actionable.

The lower menu levels are just selected but not active.

[chigy]

I believe the top most flyout gets the accent colour, as it is currently selected and actionable.

The lower menu levels are just selected but not active.

@mdtauk , I do not understand what you mean? Please elaborate. Are you just describing what happens today or are you suggesting something different?

[mdtauk]

I believe the top most flyout gets the accent colour, as it is currently selected and actionable.
The lower menu levels are just selected but not active.

@mdtauk , I do not understand what you mean? Please elaborate. Are you just describing what happens today or are you suggesting something different?

I actually got it the wrong way around. Hover on the current menu flyout is grey, but the colour of the selected flyout on the previous menu flyout changes to the Accent colour.

[shaheedmalik]

I believe the top most flyout gets the accent colour, as it is currently selected and actionable.
The lower menu levels are just selected but not active.

@mdtauk , I do not understand what you mean? Please elaborate. Are you just describing what happens today or are you suggesting something different?

I actually got it the wrong way around. Hover on the current menu flyout is grey, but the colour of the selected flyout on the previous menu flyout changes to the Accent colour.

So the accent color should be on the top most menu and the lower ones grey.

Or even better have the lower menus a darker accent color and the top most the accent color.

For example:

[mdtauk]

I would personally only use the Accent colour for the top most menu, and the grey for lower menus - it clearly shows what is "currently" selected, compared to what was "previously" selected.

I think I noticed something from @chigy that suggests this may be changing so all menu selections are grey.

[shaheedmalik]

The accent color should be used for the active selection. Gray is a natural color. It would work for both light and dark modes.

[chigy]

Added an open issue.

[chigy]

Status update: Reviewed with WinUI team and there was no immediate concern with the design's plan here.

[chigy]

@shaheedmalik and @mdtauk , do I hear an agreement with the plan here?
Trying to celebrate a small win if so. :)

[mdtauk]

Accent for the top most hover
Grey for the lower menu level selected

:)

[chigy]

Accent for the top most hover
Grey for the lower menu level selected

:)

@mdtauk , darn! Then we are not in agreement. The proposal is gray overall.
See the menu behavior already implemented in Windows OS.

@shaheedmalik , I misunderstood your "active selection" comment. Since cascading selection is really not a "selection" we are considering not using accent color because user didn't select that item. It is just indication of where the cascading menu comes from...

[mdtauk]

Not using the Accent colour at all would be ok, as long as it is consistent with other flyout menus across WinUI.

My main install is in Release Preview, but I have the Insider Fast build on my Surface Go and on another hard drive.

Of course there is always Reveal styles for the flyouts to consider too

[Felix-Dev]

Yeah, not sure what to make of @chigy's comment about the behavior in Win OS, Right now, I'm seeing Accent Color for top-level selected MenuFlyout items. Depending on the actual accent color this current design can look quite nice 😉

@chigy Is there still room to keep the current solution (accent color for top-level selected items) or is it already a done deal for the windows design team?

[chigy]

@mdtauk and @Felix-Dev , thank you for pointing that out. I was testing against light theme which is the visual I copied that does not make use of accent color (@shaheedmalik FYI).

@chigy Is there still room to keep the current solution (accent color for top-level selected items) or is it already a done deal for the windows design team?

Ones that were added recently are not something we have firm plans yet. So I guess I could say they are not "done deal." However if it comes to a subjective choice (when either choice is equally acceptable), I'd have to say our design team has a strong say in the product they are responsible for unless it breaks a developer story or flat out doesn't work for our controls... That's where I come in. (Just to set expectations and roles played here clearly...)

I'm going back to design on the dark theme design now.

[Felix-Dev]

@chigy Ah, I see! I'm only using Dark Theme for the Windows Shell here so I didn't see that the Light Theme uses a different styling here. That said, no matter how the the final decision will look like, it should be consistent across the different themes as much as possible.

[Poopooracoocoo]

Not using the Accent colour at all would be ok, as long as it is consistent with other flyout menus across WinUI.

My main install is in Release Preview, but I have the Insider Fast build on my Surface Go and on another hard drive.
Of course there is always Reveal styles for the flyouts to consider too

Oof. Just noticed a bug with the reveal effect and menus. The torch/light is stuck on the left and doesn't follow your cursor although the outline effect is normal.

[Poopooracoocoo]

menus in control panel and the menu of the power icon have a blue hover and the parent item of the cascading menu remains the same colour as the hover.

menus in winui use the accent colour for the parent item of the cascading menu but the hover colour is grey. As we found out above, Windows doesn't use the accent colour for the cascading menu with the light theme.

menus in file explorer, the taskbar, the desktop and many other places have a grey hover and use grey for the parent item of the cascading menu.

consistency is what we really need. >.>

[chigy]

@Poopooracoocoo , unfortunately, UI that you mention are created by multiple teams that are not from my team. They do use our control as the base but sometimes they customize on their own for one reason or another that we often don't fully understand.

That said, the consistent design their collective design team want now is not to use accent color here, so WinUI, who is supplying the base here, is proposing to change the design to accommodate/support this move to achieve consistency. That said, this change does not ensure consistency by itself. However, us not doing work will definitely not help with this situation to go the consistent direction because our design are the base and base design need to move toward the right direction.

I wonder if this makes sense to you?

[Poopooracoocoo]

I understand. 😊

I don't know how Microsoft works as a company but I thought that there was a design team who worked on things like consistency beyond just UWP things which was why I mentioned File Explorer and other things. I also thought that UWP Windows UI would use unchanged controls like iOS.

[chigy]

I don't know how Microsoft works as a company but I thought that there was a design team who worked on things like consistency _beyond_ just UWP things which was why I mentioned File Explorer and other things.

@Poopooracoocoo , yes we do and that is the team I'm working with on the series of UI changes that are being proposed like this one.

I also thought that UWP Windows UI would use unchanged controls like iOS.

I'm not quite sure what you mean by this?

[Poopooracoocoo]

@chigy Cool!

When I said that I was thinking of how the start menu doesn't have a backplate for it's hover/reveal effect.

[chigy]

@chigy Cool!

When I said that I was thinking of how the start menu doesn't have a backplate for it's hover/reveal effect.

@Poopooracoocoo , I still am not sure. This is referring to my question about the comment you made for iOS? I didn't post the question right so my question was showing up as quoting you. I fixed it... Can you verify?

[mdtauk]

@chigy I think what @Poopooracoocoo was saying was that they didn't think the Windows shell would have a need or want to alter any of the templates or styles of the XAML controls it would use. And that for the sake of consistency, Microsoft's inbox apps and shell, should use the controls without alterations.

[chigy]

@chigy I think what @Poopooracoocoo was saying was that they didn't think the Windows shell would have a need or want to alter any of the templates or styles of the XAML controls it would use. And that for the sake of consistency, Microsoft's inbox apps and shell, should use the controls without alterations.

@mdtauk , it would be ideal but it is not how it is today. So those who decided to customize for one reason or another would have to remove their custom code.