Grouped selection support

[LucaLindholm]

Proposal: Grouped selection support

Summary

Support for Fluent styling for grouped selection between choices. This type of control could be used in combination with others to display different views of the same or similar data, such as in map interfaces to switch between driving/walking/biking options. This lets a user pick from multiple choices, similar to Segmented Control in iOS.

Rationale

• provide a standardized horizontal selection UX
• in combination with FlipView or other controls, provide support for scenarios that were previously using Pivot

Scope

Capability	Priority
Horizontal selection of multiple options	Must
Support horizontal orientation	Must
Support vertical orientation	Should
Support styling for a Pivot-like header	Could

|
| Support styling for a group of buttons | Could |
| Multiple choice | Could |
| Every segment shall adapt to content width | Could |
| Limit the width of an item | Could |
| Respond to swipe on the control surface | Could |
| Overflow items into a dropdown menu | Could |
| Carousel items when resized | Could |
| Provide an area for content in the control itself | Won't |
| Take in data and display it differently based on selection | Won't |

Important Notes

@mdtauk created this mockup:

Mockups

Open Questions

• In what scenarios would a user need to (and be able to tell from the control's design) that they can select multiple items?
• Should each 'segment' adapt to content width, or all segments be limited to some default or developer-defined width?
• How should resizing be handled: in a dropdown menu (like NavView) or carouseling (like Pivot)?
• Could this be a restyle of RadioButtons? Likely not if we want to support multiple selection, swipe, carouseling, or other more complicated functionality

[robloo]

[mdtauk]

WinUI has the Pivot control that does this

[robloo]

The pivot is more like a tab view. This control would be a multi-toggle button. It wouldn't necessarily be used to switch views.

[mdtauk]

The pivot is more like a tab view. This control would be a multi-toggle button. It wouldn't necessarily be used to switch views.

Are there any other examples of a segmented control being multi-select?

I see macOS supports it, and it is like a list of filters applied to a view. (iOS does not seem to support it)

The Segmented control is not really a concept in Windows UI, either Xaml or Win32. If you can find existing windows apps that would benefit from this kind of control, it would be helpful to judge how necessary this suggestion would be to the community.

---

If it were to be implemented, the Pivot control could be given a multi-select behaviour, and the Pivot could be moved from a view switcher, to allow for a filtering situation (which is part of what it was originally envisaged to be)

[mdtauk]

Windows fluent UIs tend to use this method for filtering UX

[weltkante]

Its not about filtering.

I see this regularly in applications with complex UI, especially if they are visual editing tools. I've even seen it in Microsoft products like the Expression Blend/Design tools, though the edges aren't always rounded. Blender had this kind of visual grouping of controls for a very long time.

Its basically about grouping checkboxes and radiobuttons together visually, like you used to do on a classic Windows toolbar with seperators, except that it is a more modern style. Note that they don't have to be restricted to horizontal stack, vertical makes just as much sense (and are also used in practice).

I also used it a few times myself in WPF, using existing checkbox/radiobutton controls and adjusting their frames to visualize that they belong together. Obviously its very tedious to achieve manually, especially when UI is dynamic and its not fixed which control is the last in the list and needs its edges rounded.

I understand the visual style is something to argue about, but what I think is missing is an easy way to group checkbox / radio buttons together so they can be restyled as one unit. You can do it but its a lot of work. What you want is something as easy as restyling a listbox, except that you can't use a listbox because it changes selection with focus. You could think about it as a restyled listbox-like control with single/multi selection where you have to explicitly confirm that you change selection.

[mdtauk]

Its not about filtering.

Well the control is used for filtering as well as applying multiple attributes to a selection, and any number of other uses.

I see this regularly in applications with complex UI, especially if they are visual editing tools. I've even seen it in Microsoft products like the Expression Blend/Design tools, though the edges aren't always rounded. Blender had this kind of visual grouping of controls for a very long time.

I encounter it a lot too, but it is still useful to gather any uses that Microsoft have had for such a control UX - to convince the WinUI team of the need for this kind of control. My linking it to the Pivot, was attempting to make it easier to sell.

Its basically about grouping checkboxes and radiobuttons together visually, like you used to do on a classic Windows toolbar with seperators, except that it is a more modern style. Note that they don't have to be restricted to horizontal stack, vertical makes just as much sense (and are also used in practice).

The control would need to work as Icons, Text, and combinations of the two - and would need to visually align to the Fluent design. The RadioButtons control came about out of a need, and this control would be a similar group, with a shared item template, and support both single select and multi-select behaviour.

I also used it a few times myself in WPF, using existing checkbox/radiobutton controls and adjusting their frames to visualize that they belong together. Obviously its very tedious to achieve manually, especially when UI is dynamic and its not fixed which control is the last in the list and needs its edges rounded.

I understand the visual style is something to argue about, but what I think is missing is an easy way to group checkbox / radio buttons together so they can be restyled as one unit. You can do it but its a lot of work. What you want is something as easy as restyling a listbox, except that you can't use a listbox because it changes selection with focus. You could think about it as a restyled listbox-like control with single/multi selection where you have to explicitly confirm that you change selection.

The list of Musts on the original issue, could be finessed to the point where visually it can be made to fit the Fluent design language. I would imagine this control would use an ItemRepeater, as most of these ListView based controls are moving to use it.

I would like to see this control exist, but it would need to visually align to the design language - and be flexible enough to cover most scenarios.

[weltkante]

I see where you are going. From a quick check all examples I find in the fluent design language are using separators and not framing to group buttons that belong together. (Context menus like you've shown, Ribbons use grouping but with seperators, etc.) Since there's no common frame they are not running into the problem of not having a control for this kind of grouping.

[mdtauk]

Some quick ideas

[StephenLPeters]

What would the accessibility story look like here? would it report as a collection of items, would it report out selection states?

@kikisaints This looks pretty similar to radio buttons, but maybe with multi select. @chigy has some ideas.

[weltkante]

Trying to draw parallels to existing controls behavior:

• I would expect the control to have an accesibility name so it can report the same grouping that is implied visually. How do Ribbon groups report themselves to accesibility?
• Individual items in a group can either behave as single select (radio buttons) or multi select (checkboxes) depending on control configuration. I don't know how radio buttons usually report themselves to be differentiable to checkboxes, but in single select mode it should behave similarly here.

[mdtauk]

This control would appear to be an amalgamation of various alternative UX approaches, except contained within a single control.

When considering how behaviours should be handled, we can look to these and see how they are handled there. If this control were to be added, it should cover most of these scenarios below.

• AppBar / CommandBar with Toggle buttons (multi-select)
  

• RadioButtons (single select)
  

• The Pivot (detached from the pivot view switching for single select)
  

• ToggleMenuFlyout (for multi-select)
  

[Poopooracoocoo]

btw if anyone is here thinking of pivots (this proposal is not about navigation), please vote for #940

[mdtauk]

Pivots are the most lightweight visually for this purpose. Perhaps they need to be separated from their view changing?

Pivot becomes just the selection of headings, and a PivotView uses the Pivot with PivotItemViews containing content?

[robloo]

I found a good example of where this is needed. In a color picker it is necessary to switch between RGB/HSV color representation. In the in-box ColorPicker this is done with a ComboBox. However, in the ColorPickerButton that ComboBox would need to be in a flyout. A ComboBox within a flyout is bad UI-design and it also has UWP bugs (#1467).

To fix this I thought to switch to RadioButton. However, then I ran accross more UWP bugs that don't allow this to work (#1299 and #2081). So finally, I had to switch to ToggleButton. ToggleButton actually visually look the best -- the only problem is it's not really the intended use case.

I also realize: RadioButtons are good for vertically stacked elements only. Horizontally stacked elements really could use this segmented control.

[mdtauk]

Could you turn those scrollbar thumbs into circles? They kind of look weird as capsules

Segmented control seems like a good choice there, at least until ComboBoxes work within flyouts.

I would suggest you figure out the design of it, as it looks weird as two separated buttons. Pivot would work there, but only without the view area

[robloo]

Could you turn those scrollbar thumbs into circles? They kind of look weird as capsules

We should probably discuss that over on the toolkit. I asked for some opinions over there on that but didn't get any feedback. I'm trying not to make it look too much like iOS although circles entirely within the track did cross my mind. This is more of a blend with the Windows style right now.

I would suggest you figure out the design of it, as it looks weird as two separated buttons. Pivot would work there, but only without the view area

Design wasn't done at all and I just made it functional. I do plan to make it look more like a segmented control which is why I had the thought to post the example here.

Segmented control seems like a good choice there, at least until ComboBoxes work within flyouts.

The problem with ComboBoxes is, as you've said in the past, they shouldn't really go inside a flyout. Nested flyouts aren't ideal. Additionally, a ComboBox doesn't show all information -- it only shows what is selected. In this use case that is also not ideal.

Edit: Here is what I'm going with for now. The segmented control might be good to add to the community toolkit first as well. I might take a look at that myself.

[mdtauk]

Could you turn those scrollbar thumbs into circles? They kind of look weird as capsules

We should probably discuss that over on the toolkit. I asked for some opinions over there on that but didn't get any feedback. I'm trying not to make it look too much like iOS although circles entirely within the track did cross my mind. This is more of a blend with the Windows style right now.

Some ideas for the pivot/segmented control

(Fluent UI)

(Fluent UI iOS)

(Fast Design - default look)

(Bootstrap Button Group)

Thinking about it, ButtonGroup seems like a good solution, in the same way you have the RadioButtons control

Creates a list of Buttons or ToggleButtons, connected together, with just strings, icons or strings with icons.

(Solid by Buzzfeed)

[robloo]

@mdtauk Good examples. I do think it's important that this 'ButtonGroup' or 'SegmentedControl' is differentiated from a TabView or Pivot. A TabView/Pivot is fundamentally for switching between views. This 'ButtonGroup' is for switching between settings. Conceptually they are two different things and used in different cases.

[robloo]

It also came to my attention that HandyControls already has an example of this control for WPF.

https://github.com/HandyOrg/HandyControl#buttongroup

[WashingtonARamos]

Is this being worked on? I think the library would great benefit from a control like this but it's been months without any update.

[MartinZikmund]

Agreed, I would also appreciate such control

[mdtauk]

The primary issue with using this ButtonGroup control as a replacement for Pivot/TabControl is that it doesn't support 'tab content'. It is basically only a tab header for the examples given. This is certainly very useful for a number of scenarios but as a full replacement for Pivot it is insufficient.

I've added yet another issue #4555 proposing a real TabControl to cover these deficiencies. It would manage showing/hiding of content based on the selected header automatically.

My idea would be using a button group as a TemplatePart for the replacement control, and possibly a FlipView or other kind of carouselling view control, with a two-way binding to display the content. So the new control would have a ContentView property and a ContentHeader property - that content gets placed into the template part controls.

[Jay-o-Way]

@BreeceW Good, very good examples. Do think the comment belongs to #4492, in stead of this one, though.

[robloo]

@kat-y can you clarify why you changed the title of this proposal from Proposal: Add a SegmentedControl, like the one in iOS to Proposal: Lightweight radiobuttons in horizontal layout? I think the old title is better until we decide on the control name. Also keep in mind a 'radiobuttons'-similar usage is only half of it. There is also the togglebuttons (multi-selection) scenario. Keeping the term radiobuttons in also provides a misconception for how this control should look.

[mdtauk]

A Single-Select ButtonGroup, would have to use a restyled RadioButton to get the correct behaviour. However...

A Multi-Select ButtonGroup, would need to use ToggleButtons/AppBarToggleButtons, rather than RadioButtons.

[robloo]

A Single-Select ButtonGroup, would have to use a restyled RadioButton to get the correct behaviour. However...

A Multi-Select ButtonGroup, would need to use ToggleButtons/AppBarToggleButtons, rather than RadioButtons.

This would still work with the ItemsRepeater design mentioned above. The ItemsRepeater would host restyled RadioButtons and less-restyled ToggleButtons.

[mdtauk]

A Single-Select ButtonGroup, would have to use a restyled RadioButton to get the correct behaviour. However...
A Multi-Select ButtonGroup, would need to use ToggleButtons/AppBarToggleButtons, rather than RadioButtons.

This would still work with the ItemsRepeater design mentioned above. The ItemsRepeater would host restyled RadioButtons and less-restyled ToggleButtons.

ItemsRepeater is better than list controls. The control would need its own button/radiobutton style.
CommandBar seems to be the go to for the old Toolbar type control.

CommandBar has a subtle button style, and has it's own padding considerations. So in my examples I made, I tried to keep that in mind. It also offers more options for Icons and Labels, and would also help any Ribbon implementations, where resizing could collapse labels or move them below the icons etc.

These of course would be styles you can override if you want to customise the look of your button groups.

An example of Default Button Styling, CommandBar Styling, and unstyled

[mdtauk]

As for an API, how about something like:

<ButtonGroup Name="fontButtonGroup">
    <ButtonGroup.Multi>
        
        <ButtonGroupItem Icon="textBold" Label="Bold" Click="bold_click" />
        <ButtonGroupItem Icon="textItalic" Label="Italic" Click="italic_click" />
        <ButtonGroupItem Icon="textUnderline" Label="Underline" Click="underline_click" />
        
    </ButtonGroup.Multi>

    <ButtonGroup.Single>
        
        <ButtonGroupItem Icon="alignTextLeft" Label="Align Left" Click="a_L_click" />
        <ButtonGroupItem Icon="alignTextCenter" Label="Align Centre" Click="a_C_click" />
        <ButtonGroupItem Icon="alignTextRight" Label="Align Right" Click="a_R_click" />
        <ButtonGroupItem Icon="alignTextJustify" Label="Justify" Click="a_J_click" />
        
    </ButtonGroup.Single>
</ButtonGroup>

This is more verbose and it is more of a Group within a Button Group, so semantically not as clean, but something like this:

<ButtonGroup Name="fontButtonGroup" SelectionMode="Multiple">        
    <ButtonGroupItem Icon="textBold" Label="Bold" Click="bold_click" />
    <ButtonGroupItem Icon="textItalic" Label="Italic" Click="italic_click" />
    <ButtonGroupItem Icon="textUnderline" Label="Underline" Click="underline_click" />        
</ButtonGroup>


<ButtonGroup Name="alignmentButtonGroup" SelectionMode="Single">        
    <ButtonGroupItem Icon="alignTextLeft" Label="Align Left" Click="a_L_click" />
    <ButtonGroupItem Icon="alignTextCenter" Label="Align Centre" Click="a_C_click" />
    <ButtonGroupItem Icon="alignTextRight" Label="Align Right" Click="a_R_click" />
    <ButtonGroupItem Icon="alignTextJustify" Label="Justify" Click="a_J_click" />
</ButtonGroup>

This is semantically better, but you lose the ability to group sets of buttons within a single control, with separators between items.

If this ButtonGroup is used as is, it could display the items as Buttons and ToggleButtons - but maybe when the control is used within a CommandBar it could automatically apply the AppBar styles to the controls - and then you could manually put in Separators?

<CommandBar Name="textCmdBar">

    <ButtonGroup SelectionMode="Multiple">
        <ButtonGroupItem Icon="textBold" Label="Bold" Click="bold_click" />
        <ButtonGroupItem Icon="textItalic" Label="Italic" Click="italic_click" />
        <ButtonGroupItem Icon="textUnderline" Label="Underline" Click="underline_click" />        
    </ButtonGroup>

    <AppBarSeparator/>

    <ButtonGroup SelectionMode="Single">
        <ButtonGroupItem Icon="alignTextLeft" Label="Align Left" Click="a_L_click" />
        <ButtonGroupItem Icon="alignTextCenter" Label="Align Centre" Click="a_C_click" />
        <ButtonGroupItem Icon="alignTextRight" Label="Align Right" Click="a_R_click" />
        <ButtonGroupItem Icon="alignTextJustify" Label="Justify" Click="a_J_click" />      
    </ButtonGroup>

    <AppBarSeparator/>

    <CommandBar.SecondaryItems>
        <AppBarButton Icon="url" Label="View document in the browser" />
    </CommandBar.SecondaryItems>

</CommandBar>

I know the RadioButtons control can take in strings, but it displays those as RadioButtons which usually do not have Icons and only Text beside the check mark, so maybe we need an Item control?

[kat-y]

Thanks everyone for your great comments! Sorry for the delay here - to give some explanation, we heard the community's frustration at Pivot's removal from WinUI 3 and we've been discussing if, where, and how any work done to 'fill the gap' could be delivered in WinUI.

I'm hoping to understand your needs and the scope involved for 1) supporting a horizontal selection pattern (this issue) and 2) building a control that takes in inline XAML content like Pivot (see #4555 ) - please take any conversation about that control to that issue! 😄

I've updated the scope for this proposal and added an open question:

Capability	Priority
Horizontal selection of multiple options	Must
Support styling for a Pivot-like header	Could
Support styling for a group of buttons	Could
Multiple choice	Could
Every segment shall adapt to content width	Could
Limit the width of an item	Could
Respond to swipe on the control surface	Could
Overflow items into a dropdown menu	Could
Carousel items when resized	Could
Provide an area for content in the control itself	Won't
Take in data and display it differently based on selection	Won't

• Could this be a restyle of RadioButtons? Likely not if we want to support multiple selection, swipe, carouseling, or other more complicated functionality

@robloo

@kat-y Kat Yang FTE can you clarify why you changed the title of this proposal from Proposal: Add a SegmentedControl, like the one in iOS to Proposal: Lightweight radiobuttons in horizontal layout? I think the old title is better until we decide on the control name. Also keep in mind a 'radiobuttons'-similar usage is only half of it. There is also the togglebuttons (multi-selection) scenario. Keeping the term radiobuttons in also provides a misconception for how this control should look.

Good point! I've updated the title of the proposal to be less specific to radioing behavior.

The primary issue with using this ButtonGroup control as a replacement for Pivot/TabControl is that it doesn't support 'tab content'. It is basically only a tab header for the examples given. This is certainly very useful for a number of scenarios but as a full replacement for Pivot it is insufficient.

I don't know if any one control (other than a Pivot rewrite, which could be #4555 ) could be a full replacement for Pivot, since Pivot has been used for a variety of scenarios. If this ButtonsGroup control were to exist, I would see the following Pivot-replacement landscape:

• For scenarios that previously used Pivot for top-level Navigation, use top NavView instead (or TabView if appropriate)
• For lower-level Navigation, view-switching/filtering, and basic input (where the input group is related such as in the great examples @mdtauk shared), use BreadcrumbBar for hierarchical navigation and/or ButtonsGroup tied to a view control where appropriate.

I see that this landscape wouldn't have the convenience factor of Pivot supporting inline content, but please let me know if there is any gap in functionality I haven't captured here. 😃

[yaira2]

@kat-y I noticed that this proposal is for a horizontal selection control, what about expanding it to include a vertical option as well?

[kat-y]

@kat-y I noticed that this proposal is for a horizontal selection control, what about expanding it to include a vertical option as well?

@yaichenbaum That's a good point! I changed the name to Grouped selection support this time 😄. I've also added the orientation functionality to the scope table. I see horizontal as in-scope for a v1 and see vertical as important, but not critical for a v1 ButtonsGroup. Let me know if you think otherwise!

Capability	Priority
Support horizontal orientation	Must
Support vertical orientation	Should

[WashingtonARamos]

I suspect someone in the future will recreate an issue asking for a "Segmented control (just like in iOS)" because that's where everyone is used to seeing it and how they're used to call it, not to mention this issue is already more than 1 year old and probably a few people had been following it as it was called and kept checking for updates.

[mdtauk]

Here is a little something from Flutter for Google's Material You update to their Design system.
flutter/flutter#83047

NavigationBar

(with labels always visible)

(with only selected label visible)

(with labels hidden but visible with tooltips)

[ghost]

I see two use cases discussed here: one for selecting from a couple of options like in the Office apps, and another one for navigation. While they may look similar in other operating systems, they are pretty different and I think they should stay separate.

For navigation specifically I have a proposal in #5223.

I think this one should be restricted to selecting items only.

[mdtauk]

I see two use cases discussed here: one for selecting from a couple of options like in the Office apps, and another one for navigation. While they may look similar in other operating systems, they are pretty different and I think they should stay separate.

I think this one should be restricted to selecting items only.

This proposal is specifically for selecting items within a group, either as Single Selection or Multi Selection.

The extended idea is that this control could be used as a primitive for a Pivot replacement, or could group button items for use on a toolbar.

For navigation specifically I have a proposal in #5223.

Tab Item and Tab Group seems like it should be worked into the TabView control. Navigation should use the NavigationView control in its Left or Top orientations.

Pivot has been used for navigation in the past, but should only be used for switching out views within a single page context. With Pivot being removed eventually, there will need to be a suitable replacement for those non-navigation contexts (or non top-level control contexts).

[ghost]

I might have misunderstood how navigation works in WinUI. Couldn't a single control be used for both switching views in a single page and for switching between pages?

TabGroup was intended as a primitive for TabView, and possibly even NavigationView. It could also directly replace Pivot.

[mdtauk]

I might have misunderstood how navigation works in WinUI. Couldn't a single control be used for both switching views in a single page and for switching between pages?

TabGroup was intended as a primitive for TabView, and possibly even NavigationView. It could also directly replace Pivot.

NavigationView has a sidebar you can show and hide with a "Hamburger Button", and has NavigationViewItems for the various entries which when tapped can trigger a frame to navigate and show different pages. This sidebar can be a top bar if you choose, and the items are displayed differently as you switch the orientation mode.


NavigationView also has support for nested navigation items

TabView is similar except for how it displays it's TabViewItems, and can be used to enable adding new tabs, dragging tabs out, and re-arranging.

Both display the navigated content page in a frame.

Both controls are designed for filling a whole window or screen, and loading/navigating between Pages in a Frame. So are Top Level controls in that sense.

The Pivot has PivotViewItems which are panels which hold XAML content, and transitions between these as you tap or swipe on the control.

Pivot is being removed because the WinUI Team wants developers to use the NavigationView with Top orientation instead for navigation. But it also is a bad idea to put a NavigationView inside another NavigationView - so for other uses of the Pivot, there is currently no alternative.

TabGroup if it does not manage the Xaml content being brought in and out of view, is not a replacement. And a control named TabControl or TabGroup would be confusing alongside the TabView Control.

[ghost]

I guess I didn't make it clear, but it was intended that TabGroup did hold its content, just like the other controls. So you could have both an entire page and a smaller section in the page using two TabGroups.

I don't think the names would necessarily be confusing. There are already similarly named controls like Grid/GridView, RadioButton/RadioButtons.
Ideally TabViewItem would be renamed into TabItem because it's more generic. TabView would contain a default TabGroup, and you could add more inside that one for grouping/nesting.

---

It might be better to move these comments into #5223

[niels9001]

We have recently published the new Segmented control and TokenView controls as part of the Windows Community Toolkit Labs. I think these controls are very much in line what is discussed here.

Segmented control

• Supports single and multi selection.
• Comes with 3 different styles (default, Pivot-like style and button style).

More info here: CommunityToolkit/Labs-Windows#392

TokenView

• Supports single and multi selection
• Allows for wrapping TokenItems
• Items can be removed as well

More info here: CommunityToolkit/Labs-Windows#427

[mdtauk]

Is there any worth in creating a SegmentedView control or updating the Pivot Control to combine a Segmented control with a view/frame control?