Microsoft-ui-xaml: Add a new light weight style to navigation view to customize the item chevron font size.

[tharun916]

how can change navigationviewitem chevron size by markup . i need an example

[Felix-Dev]

Do you mean the font size of the chevron or the space it takes in the NavigationViewItem (which is currently 40px as the hittest area for touch screen devices)?

Right now, you only have some theme resources to control the margins of the chevron and the ContentPresenter to its left:

For other properties, like the font size of the chevron, you will need to create a copy of the NavigationViewItemPresenter styles (to be found here) and modify them or set your desidred chevron sizes in code by walking the visual tree.

[StephenLPeters]

@tharun916 can I ask why you want to change the size of the Chevron? I'm curious about your scenario :)

[Felix-Dev]

@StephenLPeters See for example the new Amazon Prime Video For Windows app which appears to use the following design (might not necessarily be the WinUI 2.4 hierarchical NavView but a custom solution):

Observe that the expand/collapse chevron used there looks quite different compared to the WinUI chevron. As such, there might be demand to make styling the WinUI NavView expand/collapse chevron easier to achieve designs like this.

[tharun916]

@StephenLPeters I am using small font size in my navigationview , so i need to reduce the size of the chevron looks like in the image.

[Felix-Dev]

We could make the FontSize of the chevron configurable via theme resources - though we would also have to update the height and width of the chevron textblock then (especially when FontSize is increased). We don't even have to change the width of the chevron UI then (needed for touchscreens) as we have quite soom room right now to increase/decrease the font size. For example, the chevron font size can be set just fine to 20px (with Width and Height adjusted) with the current chevron XAML. I'd think most of the time the customer demand would be to make the chevron smaller than it currently is (see the two cases above).

TreeViewItem has a GlyphSize API for example to set the font size of the expand/collapse chevron so I think we should also make the NavigationViewItem's chevron's font size configurable. At least as a theme resource for now (the actual chevron character for the NavViewItem is also setable via a theme resource only currently - NavigationViewItemExpandedGlyph - so we would be consistent here within the NavigationViewItem).

[StephenLPeters]

@YuliKl and/or @anawishnoff do you have thoughts on if we want to enable this scenario without forcing a retemplate (by adding a new theme resource). I think the chevron size was chosen deliberately for touch considerations so me might not want to encourage changing it. @chigy FYI.

[anawishnoff]

Thanks for looping me in. I worry about the possibility of making dramatic changes to the size of the chevron - are we able to set a min/max value if the font size becomes configurable? Or maybe it's better to have a set of possible values, along with the correctly-changed text box size?

[Felix-Dev]

I think the chevron size was chosen deliberately for touch considerations so me might not want to encourage changing it.

@StephenLPeters @anawishnoff
I was under the impression that the width of the Grid (40px) the chevron TextBlock is placed in was chosen like that for touch screens as it is the hit target of the chevron. See this comment by @ojhad: https://github.com/microsoft/microsoft-ui-xaml/issues/2287#issuecomment-617476996
Based on my understanding then, changing the FontSize of the chevron won't in fact touch the hit target of it (it would still be 40px wide). We thus have at least some range of possible FontSize values for the chevron to play with without actuall having to adjust the hit target width of 40px. And seeing as both cases above use smaller chevron font sizes, the 40px width should still work just fine.

Suppose we do provide a FontSize theme resource for the chevron, a developer could indeed set the FontSize large enough so that the chevron will no longer fit in parent Grid with width 40px. For such a huge chevron to be displayed correctly then the developer would have to retemplate the control currently, but I don't think that's a realistic use case (could be wrong on this though). Adding a FontSize theme resource here would at least make it rather easy to reduce the FontSize of the chevron (something for which there seems to be some demand) while keeping its hit target area intact.

Edit: I created some test images. The red background you'll see is the hit target of the chevron and that remains the same, even though the FontSize changes.

Chevron FontSize 20px

Chevron FontSize 8px

[YuliKl]

My preferred philosophy is to allow app developers to customize controls easily, preferably without the need to retemplate. No, the control won't be able to guard against all bad configurations. Which is ok as long as the default sizes and hit targets that controls ship with are good. So I would support @Felix-Dev's suggestion of a new theme resource.

[StephenLPeters]

Awesome, sounds like we are in agreement that a new light weight styling resource is warranted here. @Felix-Dev any chance you want to take this on? :D

[Felix-Dev]

@StephenLPeters Yes, I can tackle this (need to first bring some other PRs over the finishing line though :))

[Felix-Dev]

I've noticed that the hit target area of the chevron in Top mode is only 24px wide, instead of the 40px we see in left mode:
https://github.com/microsoft/microsoft-ui-xaml/blob/3834f4d238b98abf5857120387eee3a2e3da0aa4/dev/NavigationView/NavigationView_rs1_themeresources.xaml#L1165

The hit target area visualized (in red):

The reasoning for the 40px wide hit target area for the chevron in Left mode is that touch users have enough room to expand/collapse a NavigationViewItem without accidentally selecting it too. Doesn't the same reasoning apply here in Top mode as well? With the current hit target width of 24px (and looking at the image above visualizing it) it seems quite challenging to me right now for the average touch display user to expand/collapse a NavViewItem without also selecting it.

I've prepared a few images how an updated hit target area with width 40px (same as in Left mode) would look like:

Hit test area visualized

In addition to updating the hit target width, we could also then think about matching the expand/collapse chevron font size with the font size in Left mode. Currently, it's 8px in Top mode but with the increased width of the hit target area, we can also set it to 12px. See the following image how that could look:

This is also relevant for this PR (which is why I am mentioning the smaller hit target area in Top mode here) because right now I would have to introduce two theme resources for the chevron font size just because the font size differs depending on the pane display mode. The two theme resources would be

<x:Double x:Key="NavigationViewItemExpandedGlyphFontSize">12.0</x:Double>
<x:Double x:Key="TopNavigationViewItemExpandedGlyphFontSize">8.0</x:Double>

However, if we decide to align the font sizes here to improve the touch display user experience, I think we could also just use one theme resource then (NavigationViewItemExpandedGlyphFontSize) without having to offer a separate one for Top mode. Thoughts on this?

With that said, notice the selection indicator in the images above showing the proposed width increase of the hit target area. See that it covers plenty of area next to the ContentPresenter of the item on the right. How do you view adjusting the indicator margins here so that it will only cover the actual content of the item describing its topic (icon and ContentPresenter)? It kinda looks weird to me if the selection indicator also covers the chevron. See the following image for a proposed look:

Note that this would match the design for NavigationViewItems which do not have children (and thus no chevron):

[ranjeshj]

Thanks @Felix-Dev. These pictures are really helpful. I'll let @YuliKl and @chigy weigh in on the sizes. The proposed changes looks better in my opinion. I assume the More button and chevron would also follow the same to be consistent.

[Felix-Dev]

@ranjeshj I will add a couple of images for the More button as well.

[Felix-Dev]

First of all, the More button has no issue with the hit target area being too small as its entire surface (as expected from being a button) is the hit target area. The minimum width of 40px is always met.

Note that in the picture above, the More button's chevron symbol used here is Segoe MDL2's Chevron Down Small symbol with Unicode U+E96E and FontSize 8px. The expand/collapse chevron for NavigationViewItems uses the Chevron Down symbol with Unicode U+E70D. (In the image above, the above proposed changes to the font size and hit target area of the NavViewItem chevron are already applied.)

More button design in OverflowLabelMode.MoreLabel

In my proposal above, I spoke about updating the FontSize of the expand/collapse chevron to 12px (from the current 8px). Here is how that would look applied to the More button's chevron:

(The proposed font size and hit target improvements to the NavViewItem's expand/collapse chevron is already applied in this image).

Note that the current margin for the More button chevron uses an additional -4px its bottom side which is not used for the NavViewItem expand/collapse chevron, hence why you are probably noticing these chevrons aren't on the exact same height:
https://github.com/microsoft/microsoft-ui-xaml/blob/e4712e8fb3232a60663c816bdb7075b70f3f3867/dev/NavigationView/NavigationView_rs1_themeresources.xaml#L446

We can decide to remove that 4px negative to align all the chevrons on the same hight:

Also note that the padding between the ContentPresenter and the expand/collapse chevron for NavigationViewItems is 16px, whereas it's 8px for the More button (as you can see above). Independently of whether we decide to visually align the More button chevron with the NaViewItem chevrons regarding their height, I think it would be helpful to keep intact that unique 8px padding here because we should have some sort of visual separation between a NavigationViewItem and the More button.

More button design in OverflowLabelMode.NoLabel

If we set the OverflowLabelMode of the NavigationView to NavigationViewOverflowLabelMode.NoLabel the More button's chevron symbol is changed to Chevron Down with FontSize 16px:

With the proposed changes to the NavViewItem chevron applied, this would give us the following design:

I think there's not much to say here other than I'd keep this as it currently is. Yes, the Mor ebutton chevron has a FontSize of 16px vs 12px for the NavViewItem chevron but I believe that is useful here to visually separate these different chevron UI elements. Its hit target area is also 40px wide, so no issues here: https://github.com/microsoft/microsoft-ui-xaml/blob/e4712e8fb3232a60663c816bdb7075b70f3f3867/dev/NavigationView/NavigationView_rs1_themeresources.xaml#L464

[StephenLPeters]

First off, personally I think this looks a lot, lot better, having missmatched cheverons looks terrible.

Visually, in the Heirarchical navigation scenario, the More button behaves like any other Heirarchical Nav View item, expect that it itself is not selectable, and that its children get moved into the main list and main list children can get moved into it... I wonder if we should have a different design for the more button given that it doesn't behave the same way, maybe there is some other glyph we could use.

Without a better design idea though I think the proposal makes sense. @chigy FYI

[Felix-Dev]

@StephenLPeters I just thought about the following icon to use for the More button:

That would indicate to me that the More Button potentially holds a collection of top-level items and their children. Whereas the single chevron just symbolizes a single parent item has some children.

That said though, I was kinda expecting such an icon in the Segoe MDL2 font... yet haven't found one.

Edit: I guess this can be re-created by simply using two chevrons each in its own TextBlock and use appropriate margins.

[Felix-Dev]

Using two chevrons to create the icon above, it could look like this:

OverflowLabelMode = NoLabel

(Left More button is current design, right More button would be updated design)

And below an image with the updated NavViewItem chevron design and without the current More button design:

Compared to the current implementation here
https://github.com/microsoft/microsoft-ui-xaml/blob/45e6a3f90918f66c6b5330c9d69134322c0b5ae4/dev/NavigationView/NavigationView_rs1_themeresources.xaml#L505

a possible implementation could look like this:

<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">
    <FontIcon
        x:Name="Icon"
        AutomationProperties.AccessibilityView="Raw"
        FontFamily="{ThemeResource SymbolThemeFontFamily}"
        FontSize="16"
        Glyph="&#xE70D;"
        Foreground="{TemplateBinding Foreground}"
        IsHitTestVisible="False" />
    <FontIcon
        x:Name="Icon2"
        AutomationProperties.AccessibilityView="Raw"
        FontFamily="{ThemeResource SymbolThemeFontFamily}"
        FontSize="16"
        Glyph="&#xE70D;"
        Foreground="{TemplateBinding Foreground}"
        IsHitTestVisible="False"
        Margin="0,-10,0,0"/>
</StackPanel>

OverflowLabelMode = MoreLabel

With the proposed updates to the NavigationViewItem's expand/collapse chevron, the updated design could look like this:

(Again, left More button is current design, right More button would uses the new icon)

And the same image but without the current More button:

(The height of the More button chevron icon could be adjusted.)

Compared to the current implementation here
https://github.com/microsoft/microsoft-ui-xaml/blob/45e6a3f90918f66c6b5330c9d69134322c0b5ae4/dev/NavigationView/NavigationView_rs1_themeresources.xaml#L444

a possible implementation could look like this:

<Grid Margin="8,0,0,0">
    <FontIcon
        x:Name="Icon"
        VerticalAlignment="Center"
        AutomationProperties.AccessibilityView="Raw"
        FontFamily="{ThemeResource SymbolThemeFontFamily}"
        FontSize="12"
        Glyph="&#xE70D;"
        Foreground="{TemplateBinding Foreground}"
        IsHitTestVisible="False" />
    <FontIcon
        x:Name="Icon2"
        Margin="0,0,0,-10"
        VerticalAlignment="Center"
        AutomationProperties.AccessibilityView="Raw"
        FontFamily="{ThemeResource SymbolThemeFontFamily}"
        FontSize="12"
        Glyph="&#xE70D;"
        Foreground="{TemplateBinding Foreground}"
        IsHitTestVisible="False" />
</Grid>

(Note that the implementations are currently just for demo purposes and could have room for some improvements.)

If that is something the team can get behind with as an updated icon for the More button then we should ideally log a request to the MS Design team to create such an icon (and perhaps the matching left/top/right variants of it) for the Segoe MDL2 font as an official version for us to use. In the meantime, we could use a temporary solution like the ones above.

[Felix-Dev]

@StephenLPeters An update on this?

[StephenLPeters]

@Felix-Dev How does this implementation work with the Font Scaling setting in the settings app? I think this would cause the icons to scale up which would cause the hard coded negative margin to be incorrect?

[YuliKl]

We'll need to run the double-chevron icon idea by our internal design team. If they approve, it should be pretty straight-forward to have a new icon added to the font and eliminate the need for negative margins and overlapping glyphs.

[YuliKl]

@Felix-Dev, I'm looking at one of your earlier comments highlighting the -4 bottom margin on the More button's chevron. While I'm not a fan of negative margins, there is a nice visual alignment between that glyph and the height of the font. This alignment is a bit off on the NVIs, with the chevron sitting visually a bit too high.

Looking at the code, in addition to the negative margin, the vertical alignment is set to Center.
https://github.com/microsoft/microsoft-ui-xaml/blob/e4712e8fb3232a60663c816bdb7075b70f3f3867/dev/NavigationView/NavigationView_rs1_themeresources.xaml#L447
This may be the right approach when users scale their fonts to be bigger, but I'm wondering if it would be productive to experiment with different verticalAlightment and margin combinations. Something that would keep the relationship between the More text and its chevron glyph while allowing the same margin value to be reused.

What do you think?

[YuliKl]

@Felix-Dev, the recommendation from our design team is to replace the More button and its chevron with an ellipsis glyph. The same metaphor and visual treatment that CommandBar's overflow button has today.

[Felix-Dev]

@YuliKl I haven't yet read through your previous comment (have been busy here the past days, sorry) but about your newest comment: What does that mean for the NavigationView.OverflowLabelMode API? As far as I can tell, that is only used to control whether the "More" label is shown as part of the More button or not.

If I read the suggestion correctly, it seems to me this API would basically become obsolete (as there wouldn't be a "More" label any longer). Is that correct?

I have no problem using the suggested icon here and would add it as part of a PR.

[YuliKl]

What does that mean for the NavigationView.OverflowLabelMode API? As far as I can tell, that is only used to control whether the "More" label is shown as part of the More button or not.

If I read the suggestion correctly, it seems to me this API would basically become obsolete (as there wouldn't be a "More" label any longer). Is that correct?

That's correct. @ranjeshj, @MikeHillberg can we deprecate OverflowLabelMode as part of this change? Or would it be better to keep a no-op property and avoid a breaking change?

[Felix-Dev]

If we stick to semver we should keep that API but we should add a comment to its documentation stating it is now obsolete and will be removed in a future WinUI version (which would presumably bet either WinUI 3.0 or WinUI 4.0, depending on when the team feels comfortable to remove it. WinUI 3.0 would be fine with semver but the team wants to limit breaking changes to a minimum for it coming from WinUI 2 so that might push the actual removal of it to WinUI 4.0)

[StephenLPeters]

I don't think we want to deprecate or remove the API. Currently the only thing setting this api does is call GoToState on OverflowButtonWithLabel or OverflowButtonNoLabel. Thus if we leave the code behind as is and just change the template to either remove these states, or remove the setters in the visual states, we could retain the ability for customers to retemplate back to the old style, or update those visual states to add something. This has the obvious added benefit of not being a breaking change for anyone who took a copy of the template any time before this change.

[Felix-Dev]

@StephenLPeters If we don't find another use case for this API, I do think we should consider removing it as part of, say WinUI 4.0. I don't like the idea of "dead" public APIs which just "pollute" the API surface and don't have any effect when using the default control. If developers really want to get the old look back, even with this API removed, they can always re-template the control or even sublass it and add back this API. I strongly believe we should use the power of semver here and remove deprecated/obsolete APIs to keep the public API surface tidy and relevant.

We should keep the API for now but add a remark to its documentation stating this API is obsolete (has no effect for the NavView using the default control template) starting with WinUI 2.5.

@YuliKl I think as part of the glyph change we should consider adding a tooltip to the More button. Probably saying "More" as that is the current text used here.

Edit: Actually, "See more" would be better because that's the tooltip text shown for the CommandBar's More button:

[Felix-Dev]

the recommendation from our design team is to replace the More button and its chevron with an ellipsis glyph. The same metaphor and visual treatment that CommandBar's overflow button has today.

@YuliKl Just to clarify: The Overflow button of the CommandBar has a reveal background and a reveal border:

The NavigationView Oveflow button has neither of them (and is also a bit smaller in terms of width):

(The NavView Overflow button with updated glyph.)

I think you are saying here (and I would agree) that the NavView's Overflow button should visually match the CommandBar's overflow button. This means it should use border and background reveal and increase its current width (40px) to match the width of CommandBar's Overflow button (48px). Is that correct?

(The width of a NavigationViewItem with just an icon and no chevron/content is also 48px so we would be consistent here if if we increase the NavView Overflow button with by 8px.)

[Felix-Dev]

Should we also look at the selection indicator and update its margin/width? Below is a gif which shows the selection indicator in Top mode for NavigationView items with icon + content/icon only/content only + with/without expand/collapse chevron:

[StephenLPeters]

The Gif you attached looks pretty good to me, is there something you are trying to call out as a point which could be fixed by adding that customization knob?

[Felix-Dev]

@StephenLPeters I was wondering if it is desired that the selection indicator also covers (parts of) the expand/collapse chevron and not just the icon and/or content string.

[msftbot[bot]]

:tada:This issue was addressed in #3063, which has now been successfully released as Microsoft.UI.Xaml v2.5.0-prerelease.200923002.:tada:

Handy links:

• Release Notes
• Official Nuget Release