This component aims to streamline the process of making single and multiple selections in scenarios where options should all be exposed on the screen and may contain rich content. Unlike "Select" which seeks to condense the amount of screen real estate, this component is for cases where the controls are intended to have higher visual prominence.
The component enforces:
Keyboard interactions
hover/focus states
selection indication
container styles
The component does not tightly enforce content, allowing it to be flexible to a variety of use cases.
What are common use cases that Storybook examples should represent? What’s the 80% case? (Connect with Lucas)
Summary:
"Quick filtering"
"Choice" -- making a choice amongst options
Examples:
Data experiences: Users should be able to use the Selector component to efficiently filter and select items in data tables, improving the overall user experience in managing large sets of data. (quick filtering)
Onboarding, Wizard: The Selector component should provide a user-friendly and rapid selection process during onboarding and/or configuration stages, making it easier for users to navigate and choose preferences.
Inbox: Enhance case management usability by allowing users to efficiently filter through numerous cases/items, selecting multiple options at once. (quick filtering)
Checkout flows
~Support and Chat Interactions: Implement the Selector component to enhance the selection process during support and chat interactions, reducing the time required for users to make choices.~ Removed this use case based on user testing.
Component naming
Is there a native HTML element namespace to use?
Behaviorally, this is most similar to CheckBoxGroup/RadioButtonGroup and our new "ToggleGroup". However, behavior is that you can unselect single selection (which differs from native HTML).
Or, is there an industry standard term used by component libraries?
There isn't a clear component name.
API/Anatomy -- MVP requirements (Taylor)
Based on the 80% case for custom content, it makes most sense to approach this component from a "compositional" mindset, rather than just a "configurable" one. Additionally, it feels appropriate to have a "parent"/"child" component set -- similar to Tab/Tabs or Accordion/AccordionPanel.
"Parent" component (SelectorGroup, name TBD)
Styles:
direction
gap
SelectorGroup API
defaultValue?: string | string[] // the default selected, corresponds to child's title or some kind of key
value?: string | string[] // the selected children, corresponds to child's title or some kind of key
multiple?: boolean; // whether to allow multiple selection or not
onSelect?: (event) => {} // where event.value contains the next selected
~size?: string~ // just support "medium" default size, a bit early to introduce sizes, can support box props and people can pass whatever content which can be responsive,etc.
"Child" component (Selector, name TBD)
Styles:
border
padding -- do we want to support full-width content? if so think about where the pad goes.
round
Required anatomy:
Selection indicator (CheckBox when multiple, RadioButton when single)
From grommet side, don't always show selection indicator, but thing of a way to make it easy for HPE use cases to opt-in.
Question: What should the hover indication of the individual checkbox/radiobutton be? is the interaction clear enough that clicking anywhere will select?
Question: In general, how do content regions behave when they come into contact (selection indicator + title, if no title --> custom body + selection indicator, etc.)
Optional anatomy:
Selector API
title?: string;
description?: string; // also too opinionated
icon?: JSX.Element // this feels opinionated? Yes.
----- Review with Lucas and Matt before building -----
### Semantic structure (Brittany)
What is the proper HTML markup?
The options that were being assessed were RadioButtonGroup, CheckBoxGroup or use Buttons with `roles` similar to ToggleGroup
RadioButtonGroup
- Default behavior of RadioButtonGroup is displaying a set of mutually exclusive options from which a person may `select exactly one` The key behavior here is that the user can `select exactly one` no more or less. While reading guidance online for RadioButtonGroup if a user wanted to deselect an item, then it is recommended to add another option such as "none" or "other" within the Group.
In our `Selector` component we want to make it so the user can select only `one` item but also unselect this item. We should not use `radio` in this example, if we change the behavior it will introduce confusion since it diverges from everyone expected behavior of radio buttons.
### Accessibility (Brittany)
What is the desired keyboard behavior? Screen reader announcements/roles/etc.
- [ ] Consider if interactive elements should be allowed inside and how to build accordingly
-
Since this is a `group` of options for users to click for the single/multiple version of this the `role=group` to convey to screen readers that actions are part of a group.
We will not be using the `radio` role again because this does not follow the standard UI behavior of a traditional RadioButtonGroup.
Since we are putting these items into a `group` role they desired keyboard behavior is going to be `tab` to the group than use `arrow keys` to move inside the group and `space/enter` to select an item.
The Selector is similar to toggleButton in which the they have 2 states which is `true` or `false` We will need to add `aria-pressed` to our button element which turns the button to a toggle button. This will represent the buttons current "pressed" state.
[Toggle buttons require a full press-and-release cycle to change their value. Pressing and releasing it once changes the value to true. If it's pressed and released again, the value changes back to false.](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-pressed)
What are any additional accessibility requirements?
### Styling
What is the desired styling for base theme? For HPE theme?
Any theme enhancements?
### Testing
What should test cases cover?
### Other questions
- [ ] Should this be integrated with "Data+friends" out of the box?
- [ ] ...?
Deliverables:
- [ ] PR filed to Grommet
Create draft PR for "Selector" component.
Code prototype
Component building checklist: Grommet Component building checklist.docx
General
What is the purpose of this component?
This component aims to streamline the process of making single and multiple selections in scenarios where options should all be exposed on the screen and may contain rich content. Unlike "Select" which seeks to condense the amount of screen real estate, this component is for cases where the controls are intended to have higher visual prominence.
The component enforces:
The component does not tightly enforce content, allowing it to be flexible to a variety of use cases.
Design link?
Designs: https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/branch/QNzyc61prL0zNDyDPHLGz1/HPE-Design-System-Components?type=design&node-id=27691-1164&mode=design&t=bBqv3mOWEbQG0nz4-0
Use cases: https://www.figma.com/file/gEl7V4t4Dd1ZGOZy6EswmQ/Selector-component-%233729?type=design&node-id=1-532&mode=design&t=fzMFObky4yCxaYRy-0
What are common use cases that Storybook examples should represent? What’s the 80% case? (Connect with Lucas)
Summary:
Examples:
Component naming
Is there a native HTML element namespace to use?
Behaviorally, this is most similar to CheckBoxGroup/RadioButtonGroup and our new "ToggleGroup". However, behavior is that you can unselect single selection (which differs from native HTML).
HeadlessUI has their RadioGroup with more flexible styling (not exactly what we're doing): https://headlessui.com/react/radio-group
Explore AirBnb namespace potentially: https://airbnb.io/visx/gallery, https://www.figma.com/community/file/1206705782258966386 (not sure if this is official from Airbnb or just replica)
Or, is there an industry standard term used by component libraries?
There isn't a clear component name.
API/Anatomy -- MVP requirements (Taylor)
Based on the 80% case for custom content, it makes most sense to approach this component from a "compositional" mindset, rather than just a "configurable" one. Additionally, it feels appropriate to have a "parent"/"child" component set -- similar to Tab/Tabs or Accordion/AccordionPanel.
"Parent" component (SelectorGroup, name TBD)
"Child" component (Selector, name TBD)
title?: string; description?: string; // also too opinionated icon?: JSX.Element // this feels opinionated? Yes.
SelectorBody API
children?: JSX.Element | JSX.Element[];