-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update ToggleGroupControl
design
#64439
Comments
Fully understanding that this is a difficult design exercise, I'll write down some requirements that ToggleGroupControl has in terms of component states:
I guess it's not off the table that we diverge the "standard" ToggleGroupControl from the "de-selectable" which is more like a button group. However, for overall consistency of look & feel, it may make sense to keep the selected item style in line with how we style |
Appreciate the exploration. The main item to solve here is that the dark toggled state can give prominence to the control itself, which in some cases is not desired. This one achieves contrast through the border, though marinating on this, it loses a little bit of the segmented feel, where each option is mutually exclusive to the others. This is a bit more visible in the icon example. There's something to the idea, though, so let's continue to think about how we might thread the needle, perhaps across all the componentry. Maybe it's not possible, that's fine too. |
Is this not solved in the mockups above? There may be other options to try – happy to continue exploring / create more mockups – but I don't know that we should let 'perfect' be a blocker to improvement here.
This sounds like a reasonable path forwards to me. |
It's solved, yes, but on reflection, one past instinct you shared (maybe in chat) was that this perhaps looked a bit too much like an input after all, making this specific issue not a clear win. I'm also thinking that this can be a low-boil set of explorations that consider not just this toggle, but several of them together, with no rush. What do you think? |
That kind of assumes other controls will be changing significantly which seems unlikely in the short term. So it seems a shame for this one detail to hold up any improvements, especially as it's not 100% clear it is actually an issue. I do agree this isn't high priority though. |
I noticed this bug #62981 which should be fixed sooner rather than later. We can fix the functionality part without a design change, but ideally we should have a design where a focus ring can be shown on a single option item without it being selected (like a radio group that doesn't have a selected item yet). |
Imagine having a mix of enabled and disabled option items — wouldn't it be weird if the focus rings moved between the whole group (when an enabled option is focused) and a single option (when it's a disabled option?) I wonder if we could keep the design proposed above, and show a focus ring also on "enabled" tabs: We also have a dedicated issue for this specific aspect: #63612 |
Yes, I think we're going to need to drop idea of the entire control having a focus ring. When there are no options selected and there's only a focus ring on the entire component, there's not enough affordance for the user to understand what the control does. The first option should get the focus ring, much like a radio group or any other Composite-based control. |
So how would the keyboard interaction work for an instance with no active selection? If the first item receives focus, how would users select it? What happens if they arrowkey right without making a selection – currently this would auto-select the newly 'focused' item, wouldn't that be a bit inconsistent, especially if arrowkey left returns them to the original state and selects. |
Continuing the analogy with a radio group:
Kapture.2024-09-16.at.16.25.38.mp4With this in mind, here is how
By pressing spacebar, clicking it, or moving the selection back and forth with arrow keys
If the next item is not disabled, pressing the right arrow key would move focus AND select that item. If the next item is disabled, pressing the right arrow key would move focus to that item, but without making it the new selected item (since it's disabled).
Not sure I follow entirely this last point, but I think that my replied above should have clarified the behaviour anyway. In short, it would be very similar (if not identical) to how tab selection works in @mirka what do you think about this proposed behaviour? |
@ciampo I think that makes sense. In the past, I felt strongly that there should be a clear visual distinction between the deselectable and non-deselectable variants, thus showing a focus ring on the entire component when non-deselectable. But I no longer think that's possible 😕 |
It would be a bit of a weird state, but technically yes — i'd expect each disabled item to be focussable, but not selectable.
I would probably also allow for the whole item to be disabled, as a conceptually separate thing. I guess that a disabled |
I like this one, but there are some details about it I'd love to tinker with to get it just right. I think it's mainly the gray backdrop that isn't fully gelling quite yet. Perhaps after the beta period we can seek out the way to thread the needle fully? |
Please go ahead and tinker! Here's the Figma. |
When multiple instances of this component appear in quick succession the heavy active state add's a lot of noise and can be overwhelming. Let's explore ways to remedy this in an updated design.
The text was updated successfully, but these errors were encountered: