search

microsoft / microsoft-ui-xaml

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

Proposal: Add Background Acrylic back to left NavigationView #761

Closed carmellolb closed 5 years ago

carmellolb commented 5 years ago

Proposal: Add Background Acrylic back to left NavigationView

Summary

Background Acrylic provides context, by showing that the NavigationView is the focus. It also provides a beautiful design. Please add it back to NavigationView, I'm not sure why you ever removed it.

Rationale

Scope

Capability Priority
This proposal will allow developers to draw users attention to the left NavigationView pane Must
This proposal will allow end users to experience a beautiful design, and a consistent, connected experience. Must
This proposal will allow developers to allow their NavigationView panes switch between Background Acrylic and In-App Acrylic based on the window size. Could
This proposal will allow end users to see Reveal effects easier. Could

Open Questions

Part of Acrylic's purpose is to provide context, and a beautiful design. Why remove those two things and therefore ruin the flow, look, and ease-to-use of the app by removing a stable Acrylic material on the left NavigationView?

YuliKl commented 5 years ago

@carmellolb - Thank you for your feedback. We'll work with the Fluent design team to define the right color or material for the expanded pane. As I mentioned in another issue, the use of background acrylic in this state does not fit into the overall Fluent Design System.

mdtauk commented 5 years ago

Does the overlay pane not use In App Acrylic? It used to.

Felix-Dev commented 5 years ago

@mdtauk Based on the XAML Controls Gallery, InApp Acrylic is still used for the overlay pane, as far as I can tell.

YuliKl commented 5 years ago

Yes, @Felix-Dev is correct. When NavigationView's pane is open as an overlay on top of content, the default control style still uses in-app acrylic. The issue that @carmellolb opened is talking about the mode when the pane is open side-by-side with content - in this state, the pane does not use any type of acrylic. We've outlined the rationale for these choices in the Acrylic documentation.

carmellolb commented 5 years ago

Does the overlay pane not use In App Acrylic? It used to.

Yes, it does, but I am saying why not Background Acrylic? It only uses In App Acrylic when the window is small and you expand the hamburger menu. But the Background Acrylic when the window is big is gone.

carmellolb commented 5 years ago

Yes, @Felix-Dev is correct. When NavigationView's pane is open as an overlay on top of content, the default control style still uses in-app acrylic. The issue that @carmellolb opened is talking about the mode when the pane is open side-by-side with content - in this state, the pane does not use any type of acrylic. We've outlined the rationale for these choices in the Acrylic documentation.

I really hope you will reconsider, as I think it was not a smart idea to remove it. I know I've said this many times, I'm very sorry if I seem persistent, but your explanation of why you removed it basically makes all transparency irrelevant, because all transparency "shows what's behind it" and if that is the case then all transparency must be "distracting". I highly recommend with the support of many others that you re-add Background Acrylic to NavigationView.

YuliKl commented 5 years ago

@carmellolb - I definitely appreciate your passion about this subject. Opening an issue in this GitHub repo is the most effect way to drive changes into Xaml controls, so you've found the right place to make your voice heard. Thank you for sharing your thoughts and please encourage others to react to this issue by up-voting.

mdtauk commented 5 years ago

... in this state, the pane does not use any type of acrylic. We've outlined the rationale for these choices in the Acrylic documentation

Does this mean that the Settings App and other apps are going to lose their Acrylic NavigationView Panes? That would be a serious aesthetic regression.

carmellolb commented 5 years ago

... in this state, the pane does not use any type of acrylic. We've outlined the rationale for these choices in the Acrylic documentation

Does this mean that the Settings App and other apps are going to lose their Acrylic NavigationView Panes? That would be a serious aesthetic regression.

Agree. I hope they never remove it from there, but also I think they should add it back to everything. It seems they are caring less and less about aesthetic which, unlike what they seem to be showing, is a huge component of the system.

Felix-Dev commented 5 years ago

@mdtauk @carmellolb @duke7553 @YuliKl

What can we do to try to revert this change? Would that even still be possible or is Acrylic Background for the NavigationView (except for InApp acrylic) now done for good?

lukeblevins commented 5 years ago

@Felix-Dev Upon giving this issue greater thought, I realize it doesn't make much sense to include Acrylic by default on the NavigationView Pane background. From what I've gathered Fluent Design isn't merely about looks, but also just as much about function. Acrylic in its previous form was greatly overused, shoving this unnecessary, distracting material towards users in the name of "context". We have learned that context can be better provided via Z-depth, etc. Because of this, Acrylic should be reserved for temporary surfaces. If you need Acrylic on this surface that much, you can apply an AcrylicBrush to the following keys:

x:Key="NavigationViewDefaultPaneBackground"
x:Key="NavigationViewTopPaneBackground"
x:Key="NavigationViewExpandedPaneBackground"

I hope this makes sense, as I don't work for Microsoft, but I'm just a passionate user like yourselves.

lukeblevins commented 5 years ago

I do think Microsoft should provide guidelines for the background color of this now-opaque pane. IMO, the current color choice (which appears to be a fallback color) contrasts too much with the rest of the app's UI. It should match the application's background color more, but that needs to be a separate proposal.

YuliKl commented 5 years ago

I agree with everything @duke7553 said, both about the (over)use of acrylic and the need to update NavigationView's pane color.

@duke7553, would you like to open a separate proposal as you suggested?

phorks commented 5 years ago

To my eyes, the only situation that using background (as opposed to in-app) acrylic seems correct, is in navigation panes. I think background acrylic in the navigation pane of Settings app was a great improvement in terms of aesthetics. I just can't figure it out, if using background acrylic in navigation panes is discouraged, then what was the purpose of background acrylics in the first place?

Felix-Dev commented 5 years ago

@PharazFadaei

Background Acrylic might be pretty much dead now. In another issue (linked here in the thread), @YuliKl says:

When NavigationView’s pane is placed side-by-side with the app content, this visual bridge is unnecessary and is in fact distracting because the acrylic invites unrelated content to shine through.

"[...]because the acrylic invites unrelated content to shine through"

That's just how background acrylic works (although I'd say because the background content is so heavily blurred it really doesn't distract) and that seemingly is a problem for the MS teams when applied in apps. Whether it's the titlebar, navigation pane, or other app regions, "unrelated content [will always] shine though".

It's really unfortunate, because I never found it to be distracting, it was beautiful and - coming from it - the current solution is huge step back visually, without even providing any improvement IMO. I also haven't seen any complaints about background acrylic used in apps like Settings on the usual sites such as reddit (though I'm not claiming there are none) but perhaps MS has internal data showing otherwise.

carmellolb commented 5 years ago

@PharazFadaei

Background Acrylic might be pretty much dead now. In another issue (linked here in the thread), @YuliKl says:

When NavigationView’s pane is placed side-by-side with the app content, this visual bridge is unnecessary and is in fact distracting because the acrylic invites unrelated content to shine through.

"[...]because the acrylic invites unrelated content to shine through"

That's just how background acrylic works (although I'd say because the background content is so heavily blurred it really doesn't distract) and that seemingly is a problem for the MS teams when applied in apps. Whether it's the titlebar, navigation pane, or other app regions, "unrelated content [will always] shine though".

It's really unfortunate, because I never found it to be distracting, it was beautiful and - coming from it - the current solution is huge step back visually, without even providing any improvement IMO. I also haven't seen any complaints about background acrylic used in apps like Settings on the usual sites, such as reddit (though I'm not claiming there are none) but perhaps MS has internal data showing otherwise.

It's really a matter of how transparent it is. If it is heavily blurred, like in the Settings app, there should be no problem. Microsoft seems to not realize that, and is taking the dreaded all or nothing approach. It's really a shame, because as you said, it is a HUGE visual step back.

Felix-Dev commented 5 years ago

Just look at this beauty: image

It provided beautiful context, every navigation view item is still clearly visible, background is blurred so much that it doesn't distract.

Too bad such a visual masterpiece will be removed in the near future 😥

YuliKl commented 5 years ago

@Chigy, as the WinUI representative working with Fluent designers, do you anticipate that having NavigationView draw background acrylic on its Pane in Expanded mode will support the evolution of the Fluent Design System?

chigy commented 5 years ago

@YuliKl , I cannot say never because I am not the driver of the conversation, however as far as I am aware of the activities going on with Fluent, there is no plan to re-introduce acrylic on the surface we purposefully removed from.

As @carmellolb states in the original proposal, use of acrylic draws attention to this surface (NavView) which is reverse of what we want happen. We want user to be able to focus on the content, not draw unnecessary attention to what's not important. And that is part of the reason why it was removed and we are adding it to transient UI that does need attention when it does appear on screen.

carmellolb commented 5 years ago

@YuliKl , I cannot say never because I am not the driver of the conversation, however as far as I am aware of the activities going on with Fluent, there is no plan to re-introduce acrylic on the surface we purposefully removed from.

As @carmellolb states in the original proposal, use of acrylic draws attention to this surface (NavView) which is reverse of what we want happen. We want user to be able to focus on the content, not draw unnecessary attention to what's not important. And that is part of the reason why it was removed and we are adding it to transient UI that does need attention when it does appear on screen.

I think a better approach than just not adding it back would be to add it in a less transparent form, kind of like on the Windows Shell. I think that would not draw users' attention as much if any. I think the current solid grey background definitely draws a lot of attention, maybe even more than the Acrylic, because of its contrast with the white background. I hope you reconsider.

YuliKl commented 5 years ago

Unfortunately this proposal doesn't move NavigationView's visual design in the direction that we see the Fluent Design System heading.

I do believe that we need to revisit the current grey that has replaced acrylic in the Pane. While it doesn't appear that putting back acrylic will be the right solution, the current grey also doesn't feel like the right long-term design.

Would one of you be willing to open a new proposal to update NavigationView's Pane with some (non-Acrylic) material or color? While I can open the issue myself, it carries more weight coming from the community.

msft-github-bot commented 5 years ago

We appreciate the feedback, however this doesn’t currently align to the project’s goals and roadmap and so will be automatically closed. Thank you for your contributions to WinUI!

carmellolb commented 5 years ago

Unfortunately this proposal doesn't move NavigationView's visual design in the direction that we see the Fluent Design System heading.

I do believe that we need to revisit the current grey that has replaced acrylic in the Pane. While it doesn't appear that putting back acrylic will be the right solution, the current grey also doesn't feel like the right long-term design.

Would one of you be willing to open a new proposal to update NavigationView's Pane with some (non-Acrylic) material or color? While I can open the issue myself, it carries more weight coming from the community.

I just opened one. If Background Acrylic cannot be added, I definitely think another color or material would be a lot better. Link: https://github.com/microsoft/microsoft-ui-xaml/issues/947

mdtauk commented 5 years ago

Rather than remove Acrylic altogether, why not implement a less Transparent opacity version by default?

chigy commented 5 years ago

Rather than remove Acrylic altogether, why not implement a less Transparent opacity version by default?

@mdtauk , Acrylic has a performance implications, thus we recommend do not use on a larger surface. It is partly due to the transparency as well as use of blur. Without blur, text cannot be made legible. If we make it opaque background, then gray is the best option there is.

mdtauk commented 5 years ago

Rather than remove Acrylic altogether, why not implement a less Transparent opacity version by default?

@mdtauk , Acrylic has a performance implications, thus we recommend do not use on a larger surface. It is partly due to the transparency as well as use of blur. Without blur, text cannot be made legible. If we make it opaque background, then gray is the best option there is.

Acrylic performance would be device dependent - but it is true that Acrylic has more to it than the plain Gaussian blur of Aero Glass. There should be better fallbacks for things like Tablet Mode, where it pre-blurs the Background Wallpaper, and uses that on those surfaces - but I don't want to stray from the topic.

For legibility an 80-90% opacity will assuage the legibility concerns.

It would be interesting to learn some of the performance analysis, and whether device type was considered. There could be a case to be made of having Acrylic active in unfocused windows, as well as the active window, if the PC is capable, to avoid the distraction of the colour shifting when moving between windows.

YuliKl commented 5 years ago

@mdtauk, your point about distracting colour shifts when moving between windows is one more reason why we recommend not using acrylic on long-lived, non-transient surfaces like NavigationView's expanded left pane.

mdtauk commented 5 years ago

@mdtauk, your point about distracting colour shifts when moving between windows is one more reason why we recommend not using acrylic on long-lived, non-transient surfaces like NavigationView's expanded left pane.

I can see that, but the Acrylic sidebar is (I would argue) a quintessential paradigm for Modern Windows app design - along with extending into the TitleBar.

Apps like Your Phone look "uncomfortable" and not as elegant with the opaque titlebar, and the grey sidebar. Acrylic looses it's impact when it is reserved for small overlayed elements.

Settings is also one of the better looking UI surfaces, and other Navigation Views don't look so good in comparison to it.

Poopooracoocoo commented 5 years ago

On the performance of acrylic: does this have anything to do with why opening the input indicator flyout is faster than flyouts like the clock (or even the start menu and action centre)?

adrianghc commented 5 years ago

On the performance of acrylic: does this have anything to do with why opening the input indicator flyout is faster than flyouts like the clock (or even the start menu and action centre)?

That was the case even when they all had the same old transparency effect, so I'm pretty sure it doesn't. Rather I'd guess it's because the input indication flyout is not part of the Shell Experience Host or Start Menu Experience Host apps.

chigy commented 5 years ago

On the performance of acrylic: does this have anything to do with why opening the input indicator flyout is faster than flyouts like the clock (or even the start menu and action centre)?

That was the case even when they all had the same old transparency effect, so I'm pretty sure it doesn't. Rather I'd guess it's because the input indication flyout is not part of the Shell Experience Host or Start Menu Experience Host apps.

@Poopooracoocoo , @adrianghc is right. Performance issue is more of a battery usage and as far as I am aware, should not have any launch speed implication. That said, flyouts like clock and action center has so much more contents than other flyouts that are simply a list of texts. Performance of the controls can only be guaranteed by the apps who use it properly. As a team who make controls cannot make all the scenario great (as app can do whatever they want with them), but we have to be careful not to start them on the wrong path. That's why we are very careful not to introduce controls with default behavior that would not be helpful for the Windows ecosystem.

carmellolb commented 5 years ago

On the performance of acrylic: does this have anything to do with why opening the input indicator flyout is faster than flyouts like the clock (or even the start menu and action centre)?

That was the case even when they all had the same old transparency effect, so I'm pretty sure it doesn't. Rather I'd guess it's because the input indication flyout is not part of the Shell Experience Host or Start Menu Experience Host apps.

@Poopooracoocoo , @adrianghc is right. Performance issue is more of a battery usage and as far as I am aware, should not have any launch speed implication. That said, flyouts like clock and action center has so much more contents than other flyouts that are simply a list of texts. Performance of the controls can only be guaranteed by the apps who use it properly. As a team who make controls cannot make all the scenario great (as app can do whatever they want with them), but we have to be careful not to start them on the wrong path. That's why we are very careful not to introduce controls with default behavior that would not be helpful for the Windows ecosystem.

Yes but if our computer is completely capable of handling it (and what if it’s a desktop), then Acrylic should stay on the sidebar!

chigy commented 5 years ago

Yes but if our computer is completely capable of handling it (and what if it’s a desktop), then Acrylic should stay on the sidebar!

@carmellolb , but performance is not the only reason for not using it.

carmellolb commented 5 years ago

Yes but if our computer is completely capable of handling it (and what if it’s a desktop), then Acrylic should stay on the sidebar!

@carmellolb , but performance is not the only reason for not using it.

There are many reasons to place Acrylic back.

  1. Depth.
  2. Beauty.
  3. Visual hierarchy.
  4. Contrast.
  5. Familiarity from older versions of Windows and other operating systems.

Plus more.

mdtauk commented 5 years ago

I mentioned this in another thread, but as a counter to the argument of the Acrylic sidebar being "distracting" (which doesn't seem to be an issue where it is used on macOS or other platforms)

I believe Settings uses a 60% value, but changing it to 80% would preserve the transparency, but make it less "distracting".

So why not update the AcrylicBrush theme resources used by the controls, to use a different percentage opacity?

mdtauk commented 5 years ago

Here is an illustration of the before and after, with 80% acrylic image

YuliKl commented 4 years ago

@mdtauk, would you mind filing this feedback through the Feedback Hub? Your proposal to change Settings to use 80% acrylic feels good, and isn't up to the WinUI team to implement. We already provide a variety of AcrylicBrush resources, including SystemControlAcrylicWindowBrush. The Settings app would need to make a change in their code to use a different resource. The WinUI team can't make the change for the Settings app.

mdtauk commented 4 years ago

@YuliKl I created the image to try to illustrate the difference. I have no problem with the 60% Acrylic - but would rather see it change to 80% than have the Acrylic removed all together, if that is seriously being proposed on the grounds of it being distracting.

I'd also prefer the NavigationView to have its acrylic restored, with either 60% or 80% Acrylic - but I suspect that "battle" has been lost, and more and more apps will now look more like Your Phone and less like Settings

carmellolb commented 4 years ago

@YuliKl I created the image to try to illustrate the difference. I have no problem with the 60% Acrylic - but would rather see it change to 80% than have the Acrylic removed all together, if that is seriously being proposed on the grounds of it being distracting.

I'd also prefer the NavigationView to have its acrylic restored, with either 60% or 80% Acrylic - but I suspect that "battle" has been lost, and more and more apps will now look more like Your Phone and less like Settings

It’s really a shame too, because it was one of the best features of fluent design, and one of the most well known. Also, NavigationView was one of the most prominent areas. Maybe one day they will come to their senses, change their mind, and reapply it.

carmellolb commented 4 years ago

Updates on this issue? Any news? Still no plans to re-add? @YuliKl @chigy

Felix-Dev commented 4 years ago

@carmellolb Last info we got was:

All the tools for customization are in place. I just don't have the blessing of the Fluent design team to change NavigationView's default appearance.

(https://github.com/microsoft/microsoft-ui-xaml/issues/1523#issuecomment-549564417)

So for this specific request you would have to talk to the Fluent Design team directly. This repository here, I'm afraid, is unfortunately not the right place for that.