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
Draft PR for Selector component #3840
Comments
3 tasks
3 tasks
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: