digdir
Togglegroup improvements
Work in progress
Before we start. Togglebuttons have many names. I will in this article use the naming we have used for this component, Togglegroup Here are some other examples: SegmentedControl,SegmentedButton, togglebutton, ContentSwitcher and ours ToggleGroup. SegmentedControl is the most common. Probably stemming from Apple that I think is the one that introduced this component.
Tasks
Issue started with a comment that our new design did not work well when there are only two alternatives. But we saw that there where some other issues as well.
What should we call the ToggleGroup
Most used name is segmentedControl But I suggest we keep using Togglegroup to align with Aksel.
When should I use a Togglegroup
This component is used both as a filter or changing between similar views and as a form component. Most use is the filter version. We are looking into if we also should suggest using this as a form component. It is starting to become a normal pattern in services that a segmented control is used. If we want to suggest this we need clear guidelines for what use cases this should be used for.
- [ ] Decide if we should recommend togglegroup for specific form uses?
But there is one other usecase, that im not sure of. Versions of this component is often used for settings in a more complex UI. Like settings in Word. Where some are multiselects and other act as radios. (You can set text to be bold and italic, but you can only align text to one side) We need to figure out if our component could be used for this use case
- [ ] Should togglegroup be able to have radio and checkbox behavior?
How should it look?
Most versions of this component have a softer look then we have. We use primary buttons that take a lot of attention. I suggest we make a softer version or swap our primary version with the soft. If we decide to have both we need clear documentation for when they are used.
We also need to find out how to indicate what element is selected. For now we use border radius to indicate this. But remember that if we choose to go for only the filter version. The view also should be a part of the total indication of what is selected.
- [ ] Should we have a primary and softer version of the togglegroup?
How do we make it clearer what element is selected
In the softer version of the togglegroup we can use a border color that I think will make it clear what element is selected. But for our primary version it is harder. Our first suggestion was to have a forced border-radius, the inward border would indicate what element is selected. But this do not work well with our dynamic border-radius.
I would argue that when used as a filter/view this would not be as important as it is always connected to something that changes when you select something. But if we want this to be used as a selection component it must be very clear what component is selected.
- [ ] Find a way to signal what element is selected
This part is a summary of my findings looking into how other design systems have styled their togglegroups and how they are ment to be used
Lets look closer on the togglegroup component
Looking into this issue I got a little confused on what a ToogleGroup actually is and how it should be used. I went trough as many Togglegroup components as I could find in different designsystem and logged if they have "primary button" design or something softer. I also logged what their intended use was and names. In total I looked at 36 design systems. I also noticed that a lot of design systems dont have this component, Gov.uk for instance.
How do I use ToggleGroup correctly?
There is a lot of different ways designsystems intend this component to be used. Some are very strict like Vibe:
Button group is used to display the same content in different view, if you need to present different content, use Tabs.
Here is the total overview of the findings. I have divided usecases into three categories. This is a simplification as the select a view and value may be described differently on the different design systems
| Usecase | Description | Count |
|---|---|---|
| Select a view / filter | Change a small context on a page (Most of these make it clear that tabs are for navigation and togglebutton is for changing the view in smaller context. |
18 |
| Select a value | Some designsystem use toggle button to choose values. More like a form component | 4 |
| Both | none | 8 |
| None | none | 5 |
Most cases use it as a view/filter selector. But they are not consistent on how strict they are on what the difference between tabs and togglebuttons are. In one case Togglebutton was a variant of tabs.
I suggest that we continue using the "select a view / filter" use case. This is the most common and the one we were using. I also think we should create a overview on when to use the different "selection" components that we have.
Design
There are two different designs that I found used for this component. The first one I called primary because it use a primary button (or something similar) as the selected component. A heavy design that should be used as one of the primary tasks of the UI.
Soft is a milder version that often has low contrast visual cues to tell you what element is selected. They will fit better into UIs where there are other primary tasks and the Togglegroup is an extra filter. (In the example I have created I have used 3:1 contrast on the border. But not all designsystems do this. My guess is that the idea is that the combination of the component and the view that is changing is what indicates what element is active.
Here are the total overview of the findings:
| Design | Count |
|---|---|
| Primary | 13 |
| Soft | 20 |
| Both | 3 |
I think we need to offer a softer version of the toggleGroup. There are many cases where our current design take to much attention. We need decide if we should swap designs or offer two variants
Tasks
- [ ] Ask community for input
- [ ] Decide on design
- [ ] How to implement soft version. variant or replace?
- [ ] Decide on behavior (use cases)
Edit Moved this down as a comment. This is the background for why we started looking at the toggle group. I quicly saw a need to really dig down and understand how this component is meant to be used. The investigation will be documented in the issue text and should result in ned design handling issues mentioned beneath and how we should document when users should use this component.
We need to do a second look on our new Togglegroup design. We fixed the issue we have with focus, but we added an issue where its hard to spot what element is selected. This is extra clear when there only are two elements in a togglegroup
Summary
We need to fix
- It should be easy to see what element is selected even there are only two options
- We need a softer variant of toggleGroup
What happened?
We had issues with how our togglegroup acted when on small screens and made some changes to the design and component to fix this. The biggest design change was that we removed all the padding.
With inner focus and a cleaner design we thought we had fixed the issue, but we forgot to think about how it would look when there where only two elements in the togglegroup
With the new design it is harder to see which element is selected as there is only color that changes. With the padding you got a different indicator that one side was selected.
We also see that the design is pretty heavy. In many cases the toggle group is not the primary action of the service. In more complex applications you might want to have a toggle as a small functionality. But because it uses primary buttons it will steal a lot of attention from the user.