You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
"Child" subcomponent (SelectorBody, name TBD)
Required anatomy:
N/A
Optional anatomy:
SelectorBody API
children?: JSX.Element | JSX.Element[];
----- 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.
At this point in time we've decided not to move forward with this as a grommet component (too early and too opinionated) and will instead house as a code template on Design System repo. The Draft is posted, closing this issue.
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:
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).
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)
"Child" subcomponent (SelectorBody, name TBD)
----- 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 ToggleGroupRadioButtonGroup
select exactly one
The key behavior here is that the user canselect 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 onlyone
item but also unselect this item. We should not useradio
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.
Since this is a
group
of options for users to click for the single/multiple version of this therole=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 betab
to the group than usearrow keys
to move inside the group andspace/enter
to select an item.The Selector is similar to toggleButton in which the they have 2 states which is
true
orfalse
We will need to addaria-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.
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
Deliverables:
The text was updated successfully, but these errors were encountered: