Evolved Fluent Design for controls - Autumn 2018 update onwards

[mdtauk]

I'm submitting a...

Question

Will controls be updated with respect to the new guidance suggested at Build 2018, in the addition and use of shadows and depth, as well as Acrylic materials for light dismiss content? I am thinking that DropShadowPanel, Menu, and InAppNotification will need updating.

• DropShadowPanel perhaps with a Depth value, so shadows by default can be consistent with the system.
• Menu will likely be subsumed by the System Control and WinUI library

[nmetulev]

Great question. I think they should. @JustinXinLiu, thoughts on this?

[JustinXinLiu]

I'd love to get some help from you on this one @mdtauk. But keep in mind that some of the stuff here (e.g. the new Shadow API on UIElement) are still in preview for RS5.

[mdtauk]

I kind of assumed that ThemeShadow would be in RS5 release. Also the MainMenu would probably move to the Windows UI Library. As would Hamburger Menu to NavigationView.

What kind of help were you wanting @JustinXinLiu

[JustinXinLiu]

We are thinking to refine and standardize the look of feel of all our controls, taking into account the new fluent design features. It will be a long process but we can start with some key controls first and the rest will just follow. I saw your design mockups from the past and thought maybe we can work together on this. :)

[mdtauk]

Ah ok sure, is be happy to help and contribute.

If ThemeShadow makes it to RS5, then the blade view will need to use it with a Z translation to bring the blades forward and overlapping. In App Notification should also use depth and shadow, but I guess you'll have to be guided by Edge's design thoughts.

Office seems to be contributing a great deal to fluent, so finding out what the shared approach is by those maintaining the Fluent design effort should lead your efforts in bringing the community controls into visual alignment

[mdtauk]

DockPanel, Master Detail View, ScrollHeader should probably all use ThemeShadow as well - they all involve multiple panes or layered UI.

Carousel and RadialGauge, are two controls that really feel out of place on an initial view. RadialGuage feels like a Windows 7/Metro/Silverlight control, and the 3D angle on Carousel as a default doesn't really fit either.

[mdtauk]

A quick initial idea for refreshing the BladeView...

[nmetulev]

This is really cool.

The panels on the left look like they are above the panels on the right, is that intentional (feels a bit odd)?

[skendrot]

I've wanted to use the layout transformer to rotate the title of items when collapsed. These mockups are great

[Odonno]

@nmetulev Yeah. I think too. My opinion on this is that the shadow should be managed by the user by letting him decide which blade has the focus and then apply a Z-index value on each blade, the shadow starts from the focused blade.

• In default mode, I think the last opened one has the focus (or the one which received an event like Click)
• In overlay mode, the latest has the focus
• In fullscreen, well I suppose there should be only one blade opened/focused

[mdtauk]

@Odonno @nmetulev The idea is just an initial one, to serve as an initial proposal. As each blade is sequential, and the first blade is set to not collapse, it felt right that each goes below the other in the "stack". but that is just as a default.

It would/could be possible to set a Vector3 Translate value on each blade manually, if you wanted them to be above others. (Z-index does not control the ThemeShadow, that relies on Translating the UIElement on it's Z axis)

AFAIK the control does not have the concept of an "active or focused" blade. I could be wrong of course. If it does, then changing the Translate value of the active blade to be higher would give it a more pronounced shadow.

With an "Active Blade", the Translate Z value could decrease by a pixel amount both forward, and back to the other blades, to ensure the shadows appear correctly.

@skendrot The Xbox 360 blades had rotated headers, and I think it is a better use of space, especially as a blade's contents hides when it is collapsed, but depending on the length of the header, it may not be obvious it has collapsed. Using the rotated text, and 40px width of the close and expand buttons, makes it much clearer IMO.

[nmetulev]

IMO, we should try to keep things simple and avoid adding new properties. I like what you have right now and it's a very good improvement over the current implementation. The shadow should be standardized and if someone wants to change it they can modify the template. My comments was mostly about the stacking order - it feels a bit more natural if new blades are on top

[mdtauk]

@nmetulev Normally adding a blade would place it above - but I am thinking of the uses for this control. I think having the first blade non-collapsible is very common. And if that is the case, having it be above the subsequent blades makes sense.

Other than the Xbox One blades, and the older Xbox One friends UI, I don't see all that many examples of this UI out there to base these on.

[nmetulev]

Yeah, I guess it depends on the usage. Another scenario is the Azure portal blades which work a bit differently and act almost as page navigation

[mdtauk]

Not an Azure user, but I tried looking at demos in some Build videos. Does Azure still use that blades interface?

[mdtauk]

@JustinXinLiu That makes sense, if we are just talking about visuals, however logically there is a hierarchy at work. You choose navigation on the left most pane, which opens the Master View, and selecting an item from there, goes into the Detail View.

Also the Acrylic values increase in opacity as you move up through the workflow, leading to an opaque value for the Detail View.

If the Titlebar is the lowest element, at 60% Acrylic, and the current tab and top bar are 90% - that implies the current tab is higher in depth value, and so the 70% NavigationPane, and the 80% Master View implies the depth also.

Acrylic is about layers, so as it becomes less translucent, that logically places the element higher in z order.

Having the shadows appearing on the right would make sense if the panels were using In-Window Acrylic, and the opacity and depth for the NavigationPane was higher than the MasterView.

MY THINKING:
The Current Tab/Top Bar is above
The Details View is above;
The Master View, which is above;
The Navigation Pane, which is above;
The Titlebar/Window.

When not using Sets, the Title Bar would be part of the Top Bar which would contain primary commands or a Main Menu etc.

[JustinXinLiu]

I don't mind if we reverse the shadow depth if we are going to do desktop Acrylic, but then we need to rethink how the in/out animation works as they cannot slide from underneath their parent.

In your case though, to me the only scenario that the yellow Current Tab being the highest layer is for it to contain primary commands. But it could get a little bit confusing as the Tab is on top of everything so it's not obvious which area the commands are for.

[mdtauk]

@JustinXinLiu With Sets in a weird limbo for now, and no change likely coming to the default Title Bar commenting on it for now is a little academic. Essentially the Current tab would contain the App's UI, so it would logically come after the Window and Titlebar in terms of depth order. But it needs to stand out in terms of Acrylic tinting, and for apps like Office, would use the app's brand colour.

I've been exploring ideas for trying to make Sets fit in to UI patterns, but am waiting for First Party guidance when Sets becomes the default in future updates.

So even if it goes below the App's UI in terms of ordering, it still needs to use a strong Acrylic contrast from the Titlebar.

As for Animations, tapping the hamburger menu would open the Navigation Pane, shifting the Master View to the right (unless the Navigation View is set to Overlay of course) Which would probably resize the Detail View.

[JustinXinLiu]

One thing to keep in mind is that, we don't really need depth for every single layer we have in an app. Having a top bar, left bar, middle pane and content doesn't mean we need 4 layers with different depth to make them stand out. Theme shadows are more likely to be placed on popups and windows.

Take your light themed Groove Music Design for example, I'd try removing the middle vertical shadow to reduce one level of complexity.

Also, maybe try soften and spread out the shadow too?

But overall they are looking really good.

[mdtauk]

Those ideas are just Photoshop mockups, and so when it comes to shadows, I would of course defer to using ThemeShadow to produce them, and until there are Design Toolkits, I am just kind of winging it. So consider the shadows just indicating depth, while not perfectly showing the look of the shadow 👍

For the Groove mockups, yea without a toggle for the sidebar, it doesn't need any depth, and its a good suggestion.

Getting back on topic though, do you believe the Master/Detail control does not need a differing of depth? I know when the window is narrow, it switches to a full screen navigation on pressing an item. So in that circumstance, no depth is required. But when side by side, and where a developer chooses the same background for each view, the shadow depth will still offer a good separation.

EDIT: OneNote is an example of the Master (Master) Detail pattern, with depth, and is used as an example of best practice discussing depth in UI from Build 2018

[JustinXinLiu]

In the OneNote case, everything is white so I guess it makes sense to add a little bit shadow to separate things. In the new NavigationView control though, the menu part has a slightly darker background, so generally I would avoid using shadow there.

However, it would be nice to have shadow support and just turn it off by default or vice versa.

[mdtauk]

I am no expert, but if the elements are given a Vector3 translation on the Z axis, and then the developer either adds a to the Shadow property. That determines if the shadow shows or not.

When looking over the default templates for a future version, then you should test with and without a ThemeShadow and see what makes sense in terms of implementing it as a default.

If applying it to the control allows for shadows within the control, or only for the entire control when placed onto the page. That will need to be tested - but for it to work, the template needs code to add a Translate value to the elements to give it the depth that the control needs. Translating on the Z axis can't be done in XAML sadly

[goranalkovic]

@mdtauk that's exactly how it works, you assign the Z translation

Here's an example how it's rendered in the actual app:

[mdtauk]

@goranalkovic That is how I understood it yea. There are a set of depth values which are recommended/suggested/implied at - but there is no definitive documentation on what controls/flyouts are at which depth value.

And in build 17728 they have started fixing some controls which were not handling the layered depth properly.

[goranalkovic]

@mdtauk Interestingly, that was already fixed in 18204

[mdtauk]

I had 18204 installed for a few hours before my install corrupted, now I am back on RS5 builds.

And the CommandBarFlyout is gone from Cortana's Search Box.

Do you have that shadow tool posted anywhere like GitHub @goranalkovic ?

[goranalkovic]

@mdtauk Not posted yet, created it just to see how it all works. I guess I could push it to GitHub.

[mdtauk]

In build 17730, the settings app is using 12pt text instead of the current default 15pt text. I wonder if this is part of the new UWP standard, like 40 x 40 epx for buttons instead of 48 x 48 epx

Left = Current ||||||||||||||||||||||||||||||||||||||||||||||||| Right = 17730

[michael-hawker]

This is a great thread!

@mdtauk I love the new mock-ups for the BladeView. I think my only sticking point would be about the title presence of the First BladeViewItem changing the behavior. Almost feels like we need a IsSticky property or something and then determine what that means if it's not the first one in the other scenarios.

[mdtauk]

@michael-hawker I am going by the sample app which says "The first blade has a hidden TitleBar, so you can't close it." And it doesn't seem to minimise like the other blades do. I assume it is the Titlebar property which defines this behaviour. But I am focusing on the Aesthetics mainly, bringing them into a Fluent design style. And proposed a new mode based on how the Xbox One handles it's "blade" UI