Microsoft-ui-xaml: Proposal: Support badging on NavigationViewItems

[joshkoon]

Proposal: Support badging on NavigationViewItems

Summary

NavigationViewItems should support badging, to allow for indication of new content or to call a user's attention to the control.

Rationale

• Badges are a common way to indicate new content to users, and are commonly found across all major platforms.
• Displaying badges informs and guides users to new content within the app.

Scope

| Capability | Priority |
| :---------- | :------- |
| This proposal will allow developers to notify users of new/unread items related to a NavViewItem | Must |
| This proposal will allow developers to display a count of new items | Should |
| This proposal will allow end users to quickly see whether there are new items | Must |

Important Notes

Open Questions

[shaheedmalik]

Good idea.

[mdtauk]

Mail does this...

Your Phone could benefit from this

Would the badge be visible on the collapsed sidebar? As an option, or displayed within a Tooltip?

Would the Badge be included in the NavigationViewItem, or its own template as part of the NavigationView itself?

[chingucoding]

I think it would make more sense for the badge to be part of the NavigationViewItem. However instead of adding this property to the NavigationViewItem, it might be better to introduce a new control e.g. NavigationViewStatusItem or NavigationViewBadgeItem (naming is definitely to be improven here).

Something that is also worth noting is how this should go with Hierarchical NavigationView. Should the badge only be shown on the top element? Should it be summarised for its children?

Edit: Fix typo

[StephenLPeters]

@ojhad fyi

[mdtauk]

It could conflict with whatever indicator glyph is used to denote a NavigationViewItem which contains child items. This should be included in the design scoping of this control.

[anawishnoff]

Hey @joshkoon, @mdtauk and @chingucoding, bringing this issue back to life!

I really like this idea and see how lots of apps could benefit from it.

@chingucoding as for the implementation details, you raise a good point about this being a separate control or built into NavigationViewItem. As @mdtauk pointed out, compact mode poses a difficulty for these badges. The icons used for NavigationViewItems are either font-icons or from the Symbol enum.

I would think that some kind of overlay would be required to display badges over these icons in compact mode. Not sure how a new control built for NavigationViewItemBadges would work with the icons, unless we remove the icons entirely. The other option would to not show badges in compact mode. Thoughts?

As for regular, non-compact mode, I like the standardized look of having a right-aligned number with the NavigationViewItem. I think that this could reasonably be built into the NavigationViewItem structure. But that also raises another question of what if a developer only wants to display a dot or other symbol to attract the eye to a certain NavViewItem, rather than a number? Perhaps there should be a BadgeMode property (takes from an enum of symbol or number) along with a ShowBadge property to start out.

Let me know your thoughts. This is a fun and exciting issue I'd like to discuss more!

[mdtauk]

I think with compact mode, it should be possible to display the badge in the tooltip, or/and add a dot to the Icon, to indicate it needs attention like Your Phone.

[chingucoding]

I think the idea of a "badging mode" seems good. So you can either just have a dot or display a number. In compact, should we also display a number is the question. Probably displaying a number at the bottom right of an icon might be problematic based on the icon the developer has specified.

Something we also need to consider is that we can't make the number indicator to small otherwise, it might become to difficult to read.

I totally agree with you @anawishnoff on the normal mode. In that case it should be put to the right edge of the element, neatly aligned with other badging indicators of adjacent NavigationViewItems.
One question we need to answer is how to handle hierarchical NavView. Should those support it? And should the parent be a sum of its children notifications?

Regarding the visuals for that, I think it might be best to have the visual structure of a h-NavViewItem be the following:

```
// Single item
|-----------------------------|
| 😎 Cool 1 ▼ |
|-----------------------------|

// Nested items
|-----------------------------|
| 😉 Important 3 ▼ |
|-----------------------------|
|-----------------------------|
| 🦙 LLama 2 ▼ |
|-----------------------------|
|-----------------------------|
| ✨ Spark 2 ▼ |
|-----------------------------|
|-----------------------------|
| ✔ Check 1 ▼ |
|-----------------------------|

````

What are your thoughts on this?

[mdtauk]

I think the idea of a "badging mode" seems good. So you can either just have a dot or display a number. In compact, should we also display a number is the question. Probably displaying a number at the bottom right of an icon might be problematic based on the icon the developer has specified.

Something we also need to consider is that we can't make the number indicator to small otherwise, it might become to difficult to read.

I totally agree with you @anawishnoff on the normal mode. In that case it should be put to the right edge of the element, neatly aligned with other badging indicators of adjacent NavigationViewItems.
One question we need to answer is how to handle hierarchical NavView. Should those support it? And should the parent be a sum of its children notifications?

Regarding the visuals for that, I think it might be best to have the visual structure of a h-NavViewItem be the following:

// Single item
|-----------------------------|
| 😎  Cool              1  ▼ |
|-----------------------------|

// Nested items
|-----------------------------|
| 😉  Important        3  ▼  |
|-----------------------------|
|-----------------------------|
|     🦙  LLama        2  ▼   |
|-----------------------------|
|-----------------------------|
|         ✨  Spark    2  ▼  |
|-----------------------------|
|-----------------------------|
|     ✔  Check         1  ▼  |
|-----------------------------|

What are your thoughts on this?

I think there is a problem with the badge number and Nested Navigation Items. The badge could be confused for the amount of items nested within.

What guidance should there be for when badge numbers should be used, with the heirachy?

[shaheedmalik]

In compact Mode, it should still show a number.

[Felix-Dev]

Agree with @shaheedmalik:

UWP shows badges in the taskbar app buttons - with all sorts of app icons used - just fine:

I currently don't see a reason why an overlay badge wouldn't work when the NavigationView is in LeftCompact mode with pane collapsed. As such, I prefer badges to be overlayed - if badges are to be shown - when in LeftCompact mode with pane collapsed.
When the pane is opened (expanded), the badge should be displayed the same for either NavigationView Left mode or LeftMinimal/LeftCompact mode. The difference here is really only whether the expanded pane overlays other app content or if the pane "pushes" other app content to make room for itself. This should be of no consideration as to where to display the badge.

As for nested navigation items: If we decide to display numbers aligned to the right when the pane is fully shown, we shouldn't deviate too much from this for nested navigation. Otherwise, we would potentially add unnecessary complexity by having multiple positions of the badge (overlay mode when pane closed in LeftCompact, right-aligned when opened, ?-position when used on a nav item with children). So, in order to resemble the right-alignment, we could add some more padding between the badge/number and the expand/collapse chevron. This would create a visual separation between these two UI elements and would help in not confusing the badge number with the number of children.

[mdtauk]

This is how I see it @Felix-Dev

The number badges could appear on the icon, with the collapsed state, but appear on the right for the expanded state.

There could be an option for an indicator icon, when a number does not make sense, or the developer does not wish to display it.

Status Icons could also be covered by this, for something like a profile failing to load, or a connection disconnect.

[Felix-Dev]

@mdtauk Looks good to me.

[mdtauk]

Another example of a similar idea...

[Pinox]

plse consider also a badge icon , badge icon with text

[mdtauk]

plse consider also a badge icon , badge icon with text

There is some guidance on these icons from Microsoft
https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/badges

All of these should be included in some kind of badge control. Not sure about including icons with numbers - not sure the space is available for that in the NavigationView control

[Pinox]

Not sure about including icons with numbers - not sure the space is available for that in the NavigationView control

agree, personally i would prefer using just an icon or badge number in compact mode , but icon with text in expanded mode.

[anawishnoff]

This is such great feedback, thanks everyone!

@chingucoding:

I think the idea of a "badging mode" seems good. So you can either just have a dot or display a number. In compact, should we also display a number is the question. Probably displaying a number at the bottom right of an icon might be problematic based on the icon the developer has specified.

Something we also need to consider is that we can't make the number indicator to small otherwise, it might become to difficult to read.

I totally agree with you @anawishnoff on the normal mode. In that case it should be put to the right edge of the element, neatly aligned with other badging indicators of adjacent NavigationViewItems.
One question we need to answer is how to handle hierarchical NavView. Should those support it? And should the parent be a sum of its children notifications?

Regarding the visuals for that, I think it might be best to have the visual structure of a h-NavViewItem be the following:

// Single item
|-----------------------------|
| 😎  Cool              1  ▼  |
|-----------------------------|

// Nested items
|-----------------------------|
| 😉  Important        3  ▼   |
|-----------------------------|
|-----------------------------|
|     🦙  LLama        2  ▼   |
|-----------------------------|
|-----------------------------|
|         ✨  Spark    2  ▼   |
|-----------------------------|
|-----------------------------|
|     ✔  Check         1  ▼   |
|-----------------------------|

What are your thoughts on this?

This is an issue I'm concerned about - the numbers being too small/unreadable if shown in compact mode. But that's something we may be able to discuss and work around. I think this is how I see the badge numbers working with HierarchicalNavView as well, although @mdtauk brings up a good point about these numbers maybe being confused as representing the # of children items. Maybe this could be resolved by using one accent color for badge numbers/badge dots?

@mdtauk:

This is how I see it @Felix-Dev

The number badges could appear on the icon, with the collapsed state, but appear on the right for the expanded state.

There could be an option for an indicator icon, when a number does not make sense, or the developer does not wish to display it.

Status Icons could also be covered by this, for something like a profile failing to load, or a connection disconnect.

Thank you for building these mockups @mdtauk! It's awesome to see this in action and make critiques based on that. I see there's quite a few people that like the overlaid number badges and feel that the number being displayed, even in compact mode, is a priority. I think this mockup does a nice job of incorporating that and I really like it so far. Some questions:

• Could we see how it would look with Left-Compact mode, for a NavViewItem that doesn't have children but has a numerical badge?
• I'm not a designer by trade, so correct me if I'm wrong - isn't it visually distracting to have the blue dot badge in the upper right hand corner but the number in the lower right hand corner, while the items are so close together like this? Would it make sense to have all badges in the same spot?

plse consider also a badge icon , badge icon with text

Not sure about including icons with numbers - not sure the space is available for that in the NavigationView control

agree, personally i would prefer using just an icon or badge number in compact mode , but icon with text in expanded mode.

I think maybe there's a possibility to use icons with text in expanded mode, but definitely not in compact mode as you noted above. The icons that @mdtauk also posted above seem to have been created for the purpose of getting a message across without using text. It might be safer to stick to these types of icons rather than putting more text in an already-crowded area.

Let's also talk about the implementation of the overlay badges (whether number or dot). Should there be an Icon overlayed on an Icon? Should we create new versions of each icon that have the blue dot badge? What are all of your thoughts?

[chingucoding]

This is an issue I'm concerned about - the numbers being too small/unreadable if shown in compact mode. But that's something we may be able to discuss and work around. I think this is how I see the badge numbers working with HierarchicalNavView as well, although @mdtauk brings up a good point about these numbers maybe being confused as representing the # of children items. Maybe this could be resolved by using one accent color for badge numbers/badge dots?

Good idea, using the Accent color for the badge number could potentially create a separation between "child items (with black/white chevron)" and the badge number in accent color (which is also present for selection and in compact on items with badge).

I'm not a designer by trade, so correct me if I'm wrong - isn't it visually distracting to have the blue dot badge in the upper right hand corner but the number in the lower right hand corner, while the items are so close together like this? Would it make sense to have all badges in the same spot?

Yes, that is indeed a problematic situation. I think the main problem is that in a lot of scenarios, the number is in the bottom right, and in a lot of scenarios where a dot is used, its mostly in the top right. Maybe having it always in the top right is the best way here, but this is also something that comes down to personal preference I think. But I am sure @mdtauk has a better perspective on this than I have.

I think icons with text as the badge indicator is problematic. You could result in a NavigationViewItem that has 3 icons (the one at the front, the badge icon and the hnav chevron) and 2 texts. That seem just to much for a NavigationItem which even in expanded mode might not have a lot of space.

Regarding the overlay badges for compact, I think the only option we have is to overlay. Of course, overlaying to icons is problematic and showing a number there is even more problematic.

[Felix-Dev]

Regarding the overlay badges for compact, I think the only option we have is to overlay. Of course, overlaying to icons is problematic and showing a number there is even more problematic.

Why not then make the navigationview "strip" in closed compact mode wider a few pixels? Say, 4 px, which will mitigate this concern. After all, and I'm saying it again, overlaying an icon with an icon is not per se problematic. It works just fine with the taskbar app buttons. They are a bit wider than the navview strip though which likely comes into favour here. Hence the suggestion about increasing the width slightly.

[chingucoding]

What if users decide to change it back to the standard 40px? The bigger problem I see is that you would have a rectangle for the icons and not a square anymore which is a bit visually unpleasing (at least in my opinion) since all Segoe MDL2 icons are designed to work in a square.

[mdtauk]

I can try placing the notification icon and numeric badge in the same place. I don't think you would ever get a numeric and icon badge at the same time. In fact it should probably be implemented in a way where it is an either/or property.

For the badge number size, I based it on the taskbar badge text - so it appears to be an OS wide design.

The notification dot, was again styled after the existing implementation from Your Phone but if a unified badge placement is decided on, maybe they will switch to match.

All of this is based on preserving the 40px width. If that width were to be widened, more options could be considered, but that may be too big a change to consider!

[Felix-Dev]

Tbh, for the navview items themselves this looks pretty fine to me.

<x:Double x:Key="NavigationViewCompactPaneLength">44</x:Double>
<Thickness x:Key="NavigationViewItemOnLeftIconBoxMargin">14,0,14,0</Thickness>

(We would have to adjust the other buttons, like the pane toggle button, too to now match the updated design. This shouldn't be a hurdle though.
And as always, a designer might see some additional issues I'm not seeing here immediately.)

As for going back to 40px...currently, you can just set the pane length resource above to a value of 30, for example. Why isn't that done? Because the resulting UI looks really bad. Same here. If the developer/designer thinks 40px is great UI even with badges, they can set that by all means. If not, I'm sure they will quickly go back to a value which works for badges shown in the strip.

I would keep changing the navview strip width update in mind, after all, we are now introducing additional features which previously weren't of consideration when Design settled on 40px width. This seems like an easy solution to mitigate some of the concerns raised by @chingucoding (and which become especially noticeable when we have a two-digit number displayed in the bagde).

[mdtauk]

I will make a mock up of how a wider width could be used with badges and numbers, but it would need to be wider than 44epx

[Felix-Dev]

@mdtauk You could also experiment with changed height values for each navitem. Why should we only update the width alone? It might not look good to make the height the same as the width again (in compact mode, pane closed), but if the updated width > 40px seems too rectangle now for your taste, you could also change the height a bit to come closer to the current square look again.

Btw, what is the size of a taskbar app button (not small button mode)? 48px * 48px?

[shaheedmalik]

I would keep it at 40px, just make the number smaller.

[mdtauk]

With a 60epx width, you have just enough space to display the badge numbers at the same size as they appear in the expanded view. As the pane transitions in and out, the badge numbers could be fixed to the right hand size as the pane size animates - giving a smooth transition for the items.

I think I prefer the badge overlaid on the icon, to match the TaskBar UX, and keeping a consistent design.

---

I would keep it at 40px, just make the number smaller.

The number in my mockups, is 11pt, which is slightly above the 9pt absolute minimum font size used in the OS, and the 14pt standard font size used by WinUI and UWP Xaml.

@mdtauk You could also experiment with changed _height_ values for each navitem. Why should we only update the width alone? It might not look good to make the height the same as the width again (in compact mode, pane closed), but if the updated width > 40px seems _too_ rectangle now for your taste, you could also change the height a bit to come closer to the current square look again.

The height of elements in UWP Xaml used to be 48epx height, but when the values for touch targets and fonts were re-evaluated, 40epx is now the height of most touch targets.

Also Windows 10X's TaskBar is very different to Windows 10's - so its probably not wise to try to match those. Also the TaskBar button size changes based on small icons, large icons, and the label visibility.

Btw, what is the size of a taskbar app button (not small button mode)? 48px * 48px?

Large TaskBar buttons are 48 x 40px

[Felix-Dev]

Yes, in small button mode, no badges are shown (even though I personally think it would still look acceptable).

I think it's fine if there is some overlap between badge and the underlying navviewitem icon. Experimenting with the width (i.e. 44px) thus was meant to make that overlapping area a bit smaller to make the underlying icon more easily identifiable if deemed necessary.

Either way, I would be fine with current 40px settings and badge overlay though a two-digit number inside a badge might cause the badge to overlay the icon a bit too much depending on the icon, making it challenging to identify it.

[mdtauk]

Might be worth looking at this issue, and see how badging may be affected by it. #2051

[anawishnoff]

@mdtauk I agree and think that the badge should be overlayed in compact mode, rather than displayed next to it like in your last mockup.

@Felix-Dev I agree - I think that the 40px settings and badge overlay would be ideal, and we'll have to experiment with the font size a bit to make sure that double digits don't overwhelm the icon itself.

As for API/implementation details, I'm trying to conceptualize which properties we'd need to add onto NavigationViewItem to represent badging. The developer will need to declare a badge type (number vs. dot vs. icon), and then set the custom value, i.e. the number to display. Thoughts on how to take this further, anyone?

In addition to that, does anyone have history on icon overlays in other Windows app models or external implementations? Want to know the most pain-free way of going about this part.

[mdtauk]

FWIW I would say there should be a Badge primitive control.
<Badge></Badge>

---

The Badge could append to a UI element with offset Placement position?
<Badge Placement="BottomRight" />

BadgePlacement.BottomRight
BadgePlacement.Bottom
BadgePlacement.BottomLeft
BadgePlacement.Left
BadgePlacement.TopLeft
BadgePlacement.Top
BadgePlacement.TopRight
BadgePlacement.Right

---

There could be a BadgeType property
<Badge Type="Numeric" />

BadgeType.None
BadgeType.Numeric
BadgeType.Generic
BadgeType.Icon_______

If the BadgeType is set to Numeric then there would be a Value property
<Badge Value="102" />

(value of 0 would not display a badge - values above 99 would be 99+)

The BadgeType.Icon________ would have a set of basic icons to represent various states - I do not think this should be a Glyph or FontIcon - as the glyphs would need to be designed for small sizes.

There is a page that details Notification and Tile badges - so maybe these should be implemented?
https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/badges

[mdtauk]

This Badge would be added to the NavigationViewItem's Icon, and the BadgeValue, BadgeType, exposed to the NavigationViewItem - the placement doesn't need to be passed on, but there is nothing to stop it from being there.

The BadgeValue would be used when the NavigationView's Pane is expanded, to display on the right.

[anawishnoff]

@mdtauk I like this idea - it does seem natural to have a badge control with properties exposed to the NavigationViewItem, and it also makes it easier to attach important properties that you mentioned above like placement, type, etc.

However, I'm trying to visualize the markup for the badge control. Take some standard NavigationView markup:

<muxc:NavigationView>
    <muxc:NavigationView.MenuItems>
        <muxc:NavigationViewItem Content="Home" Icon="Home" ToolTipService.ToolTip="Home"/>
        <muxc:NavigationViewItem Content="Collections" Icon="Keyboard" ToolTipService.ToolTip="Collections"/>
<muxc:NavigationViewItem Content="Notes" Icon="Page" ToolTipService.ToolTip="Notes"/>
    </muxc:NavigationView.MenuItems>
</muxc:NavigationView>

I think that if Badge was a separate control, you'd have to write out your icon property in explicit markup and wrap it in a Badge control like so:

<muxc:NavigationViewItem Content="Home" ToolTipService.ToolTip="Home">
    <Badge Type="Numeric" Value="{x:Bind value}">
        <muxc:NavigationViewItem.Icon>
            <FontIcon FontFamily="Segoe MDL2 Assets" Glyph="&#xEB3C;"/>
        </muxc:NavigationViewItem.Icon>
    </Badge>
</muxc:NavigationViewItem>

Or, you'd have to bind the property to a badge object already created in your code-behind and set the properties in the code-behind as well:

<muxc:NavigationView>
    <muxc:NavigationView.MenuItems>
        <muxc:NavigationViewItem Content="Home" Icon="Home" Badge="{x:Bind MyBadgeObject}" ToolTipService.ToolTip="Home"/>
        <muxc:NavigationViewItem Content="Collections" Icon="Keyboard" ToolTipService.ToolTip="Collections"/>
<muxc:NavigationViewItem Content="Notes" Icon="Page" ToolTipService.ToolTip="Notes"/>
    </muxc:NavigationView.MenuItems>
</muxc:NavigationView>

Not totally convinced that it's the easiest way to implement a badge, but it does seem relatively intuitive. Open to other ideas or responses to this :)

[chingucoding]

@anawishnoff Something that I think might be a suitable API could be:
```







````

Where BadgeNavigationViewItem is a subclass of NavigationViewItem. That way, we don't have to push the overhead on every NavigationViewItem and just have the additional overhead on items that will have that. Since devs will know which category will have badges, they can use the type for them. In the worst case, they make every entry a BadgeNavigationViewItem.

[mdtauk]

I like @chingucoding 's suggestion of having a BadgeNavigationViewItem so it improves performance of only using that template sparingly.

I was suggesting it be added to all NavigationViewItems, but even with the badge hidden by default, it could make the control templates too heavy.

---

An alternative would be to have a badge content presenter on all NavigationViewItems - then allow any Xaml element to be placed, recommended to be a Badge element.

This would then handle placement of the Xaml element in collapsed and expanded States.

[anawishnoff]

@chingucoding I like the idea of not putting extra overhead on NavigationViewItem, but creating a Badge subclass from it makes it so that badges can only be used with NavigationView. Something that I've been thinking about is that in the future, developers may want to use badges on other parts of their app - take the XAML Controls Gallery for example. They might want to use a badge on the items on their category pages to show that new samples have been created.

For that reason, I'm thinking it might be better to stick with a more flexible approach that focuses on NavigationView for conception purposes but keeps an "open mind" in its ability to expand to other controls.

[mdtauk]

I think if the Badge was it's own primitive control, the BadgeNavigationViewItem could use that Badge control, and pass through the properties to that TemplatePart.

That way the Badge could be used on ApplicationBar Buttons, or for any other control or element in Xaml.

[chingucoding]

@mdtauk idea is what I thought we would do with that. Having it also have a Badge property and pass through properties would be the best way to do this in my opinion.

[anawishnoff]

So, the idea is to have a Badge control and a BadgeNavigationViewItem that includes that control in its control template? This does allow the badge to be more flexible for use in other controls, although I feel like there should be a way to use the Badge on a NavigationViewItem with less overhead. Correct me if I'm misinterpreting your idea!

[chingucoding]

It kinda feels like it should, agreed. But the problem I see is just, how many more things are we gonna add to a NavigationViewItem?

But yes, you are interpreting the idea correctly :)

[anawishnoff]

After doing some thinking on this and talking to some other UI teams, it seems like having the separate badge control, and implementing that control in the template of specific controls (i.e. NavigationView) is a common method of implementing badging. I think this is a good, flexible solution although it adds a bit onto NavigationViewItem.

With a Badge control, I think it would be easy enough for developers to add badges to the controls of their choice by editing controls' templates. For controls that will come with built-in badging (likely only NavigationView at this point), the Badge can be a part of the control template with a visual state that depends on a badge property that can be easily set on the NavigationView.

The next part of this investigation would be how to handle the different types of badges. As discussed above, I think that there should be three distinct types of badges one can implement: dot, numeric, or symbol. The options for a symbol badge would have to come from a built-in enum, similar to the one that @mdtauk mentioned that lives here. The badge control could handle these different types through properties (type, value), or it can be a ContentControl that wraps its content, i.e.

<Badge>
    <TextBlock Text="{x:Bind numNotifications}"/>
</Badge>

The second option is more flexible, but the first option may be more intuitive and lead to less errors (i.e. putting in content that won't render/work).

[anawishnoff]

Hi again everyone,

I've created a detailed feature proposal that I'll be directly editing and pitching to our internal team. The proposal was based off of this discussion, so thank you all for your input!

I'd love for the discussion to continue - feel free to leave more thoughts on the new proposal. Thanks!