Design Multiselect Menu

[gabew1984]

Multiselect component in Figma needs a visual design to show how it works with the select menu. The menu should stay open to make multiple selections, and it should show checkboxes next to each menu item.

https://www.figma.com/file/eGmDp94FlqEr4iSqy1Uc1K/Paragon-Design-System?node-id=14061%3A18

Currently the Multiselect Figma alludes to using the select menu as the default, but is not shown there.

https://paragon-openedx.netlify.app/components/menu/select-menu/

Additionally, is there a need for menu variants for the multiselect? Learner dashboard has a large menu that could be part of this component: https://www.figma.com/file/dic277HU1JQv3fcisgQF4o/Learner-dashboard?node-id=1657%3A15611

Task: Design a state for the Figma Multiselect component that shows the open menu, with checkboxes next to each menu item. Explore variants for the menu, such as side by side lists.

Write documentation for best practice.

[b7s9]

[comments originally posted in #1420 ]

Notes from today's WG meeting:

• select (or multiselect) should only be used when the list of values has been defined. dynamically accessed (API call) or user/locally generated content is more appropriate for autocomplete
• a checkbox-like experience may be preferred
• dropdown should remain open following a selection
• Do we need the clearing options in the closed state? Design systems globally do not agree on this. This includes clear buttons on each option, and for the whole box. Do we parameterize both of those features or should we have an opinion on them?

---

Inspiration from other Design system's Multiselect solutions

• Zendesk — Garden
• Ant Design
• Material UI
• IBM — Carbon
• Twilio — Paste

I'll write up later what i like and don't like about them

Note that both Adobe and US Gov have decided not to create mutliselect comboboxes due to usability concerns. I'm not sure what their preferred patterns are if there are too many options to use checkboxes listed on the page. I guess they do ad-hoc solutions like a text field search that populates a list of clear-able chips or checkboxes above the text input.

[b7s9]

some decisions to make:

Selected options as values held in the combobox? or should we suggest a pattern of them being reflected elsewhere? The chips outside the box version feels stronger to me from a more global accessibility/usability perspective. The other upside of that method is it's easier on the eyes when you need to wrap lines for mobile. But alas it is becoming a modern convention to do chips in the box. We could also split the difference and say that a "chips in the box" method is recommended for an expected x characters or less, otherwise display selections elsewhere.

If doing the chips in the box strategy, do we need the all clear button? I think the loss of this function is a worthy tradeoff for the reduction of clutter in the box. Especially If there is a dropdown icon as well, then I'd recommend not having both icons.

For the dropdown menu itself, if we are recommending a chips below the box strategy, then I'd definitely recommend showing user selections at the top of the menu, because otherwise selections are at risk of being obscured while the menu is open. Even with chips inside the box, still might be worth doing

[b7s9]

decisions:

• chips in the box
• selections at the top of the dropdown menu
• variant for user generated options (?)
• no all clear icon button
• yes dropdown icon button

notes:

• use MenuItem sub component https://paragon-openedx.netlify.app/components/menu/
• use chips component https://paragon-openedx.netlify.app/components/chip/
• (etc. reuse when possible)

todo:

• Figma hi fi

[bradenmacdonald]

FWIW, we implemented a multi-select with chips using react-select in Course Authoring

Even using React-select to do most of the work, it got pretty complex: https://github.com/openedx/frontend-app-course-authoring/blob/80bf86992dac2271133e4bdb95cced2e3c0b0719/src/content-tags-drawer/ContentTagsCollapsible.jsx#L374-L417