Page MenuHomePhabricator

Consider enhancements for Selects and other menus with many items
Closed, DuplicatePublic

Assigned To
None
Authored By
Catrope
Mar 17 2022, 5:36 AM
Referenced Files
F35009591: Screenshot from 2022-03-16 22-04-54.png
Mar 17 2022, 5:36 AM
F35009571: Screenshot from 2022-03-16 21-58-36.png
Mar 17 2022, 5:36 AM
F35009589: Screenshot from 2022-03-16 22-04-40.png
Mar 17 2022, 5:36 AM
F35009587: Screenshot from 2022-03-16 22-04-24.png
Mar 17 2022, 5:36 AM
F35009577: Screenshot from 2022-03-16 22-03-09.png
Mar 17 2022, 5:36 AM
F35009569: Screenshot from 2022-03-16 21-58-22.png
Mar 17 2022, 5:36 AM

Description

I accidentally created a Select component with 217 menu items here (click "Select an icon"). I noticed that a Select with that many items (or, generally, more items than fit on the screen) causes problems.

In this case, the Select is inside a container with limited height that becomes scrollable when it's too tall, so it looks like this:

Screenshot from 2022-03-16 21-58-22.png (772×429 px, 27 KB)
Screenshot from 2022-03-16 21-58-36.png (763×440 px, 27 KB)
Screenshot from 2022-03-16 22-03-09.png (761×431 px, 23 KB)

If it's not inside such a container, it instead expands over the rest of the page endlessly, and you have to scroll down the page to get to the item you're looking for (and then back up, because you're left at the bottom of the page).

Screenshot from 2022-03-16 22-04-24.png (804×990 px, 87 KB)
Screenshot from 2022-03-16 22-04-40.png (428×726 px, 59 KB)
Screenshot from 2022-03-16 22-04-54.png (313×629 px, 41 KB)

The native HTML <select> lets you start typing the name of the item and will navigate to it, but our Select doesn't do that. You can use the arrow keys to navigate, but the highlighted item isn't scrolled into view automatically.

We could consider enhancements to make this work better. Here are some ideas (some of which contradict each other):

  • Clipping the dropdown menu to the edge of the page (or the scrollable container), and making it scrollable (this is what OOUI does)
  • Making the menu scroll in a way where it moves but the rest of the page stays in the same place (like the Mac OS behavior for <select>)
  • Scrolling the menu to make the highlighted option visible when keyboard navigation (arrow up/down) is used
  • Responding to more navigation keys (like Home and End)
  • Scrolling the selected option into view when the dropdown is opened
  • Allowing the user to search for an item by typing the first few letters of it; when the user types a letter, highlight the first item that starts with that letter and scroll it into view

For use cases with hundreds of possible choices, perhaps we should recommend a different component, like a Lookup, a Combobox, or some sort of cross between the two (a Combobox that filters as you type). However, most of these issues would be good to solve regardless, because they also affect Selects with a less absurd number of items (e.g. 20), or Selects in certain situations (e.g. close to the bottom of the screen/page).

Event Timeline

Here's that same icon picker but as a Lookup instead of a Select: https://771505--wikimedia-codex.netlify.app/components/button.html . It's probably a better UI for this purpose (although it doesn't let you browse all icons easily), but it still suffers from some of the same issues when you start typing. There are 127 icons whose name contains a for example. A language picker component would have similar scale issues too.

Hey @Catrope 👋🏻 I've been forgetting to ask: do you agree that the implementation of a scroll functionality in the Menu component could be a potential solution for this issue? Copying the main functional requirements from that task (T306932) here for visibility:

  1. The Menu component should display and accommodate (in terms of height) a number of items that is set by default. The number should of course be overridden in case that the available number of options < default number of displayed items. This number should be based on current patterns and probably be between 6 and 8 (to be validated with the rest of the PatternLab team).
  1. Implementers of the component should be able to define that default number of items. Recommendations regarding the minimum (3) and the maximum (10) number of options will be provided.
  1. Implementers of the component should be able to enable (or disable – depending on what we consider to be the default) the scroll functionality