Revise Simple Dropdown ADR: no max limit on items

[lcjohnso]

The Simple Dropdown ADR states that the task should accept a min of 4 and max of 20 items. These limits are not currently enforced are enforced in the code (see #1861) and in order to make the Simple Dropdown task maximally compatible with current PFE-created dropdown item lists, I recommend the limits be revised in the ADR be loosened (specifically: max = 200) or removed.

An argument in favor -- while the current ADR questions the UX of scrolling through hundreds of options, for typical cases like a range of years and others, the scrolling is not necessarily time consuming and bad.

This decision impacts implementation of Simple Dropdown editor in FEM Lab (see zooniverse/Panoptes-Front-End#6765).

[eatyourgreens]

When the number of options is large, the preferred UX would be a combobox, where you type to filter the available options (#5130.)

The current limits are enforced in the code. A menu with more than 20 options will error as an invalid snapshot in the task model here.

front-end-monorepo/packages/lib-classifier/src/plugins/tasks/dropdown-simple/models/SimpleDropdownTask.js

Lines 10 to 16 in 71417d3

	const MIN_OPTIONS = 4
	const MAX_OPTIONS = 20
	const MenuOptions = types.refinement('MenuOptions',
	types.array(types.string),
	value => value.length >= MIN_OPTIONS && value.length <= MAX_OPTIONS
	)

[eatyourgreens]

the scrolling is not necessarily time consuming and bad

I suspect this may not be true for someone navigating the menu in a screen reader. We have a volunteer who uses NVDA, who might be willing to help us.

[eatyourgreens]

This is an excellent article about designing accessible menus. I didn't realise that Windows and MacOS fundamentally disagree on how select menus work. I imagine most of our volunteers are accustomed to Windows menus.

<select> your poison.

Part 2: test all the things tests menu usability with 12 participants.

[kieftrav]

@eatyourgreens @lcjohnso - following up on this thread with the intent to resolve both this issue and issue #5130.. Based on the above conversation the resolution to this issue is to perform the following:

• Increase the maximum number of options to 200 in the SimpleDropdownTask model
• Add the search capability to the SimpleDropdownTask component
• Enforce a strict maximum of 200 items in the PFE->FEMLab Workflow design
• Enforce a strict minimum of 4 items in the PFE->FEMLab Workflow design

[eatyourgreens]

Increase the maximum number of options to 200 in the SimpleDropdownTask model.

I'm still strongly opposed to this, which breaks number 3. (avoid long menus) in the Nielsen-Norman Group's design guidelines for dropdown menus. I actually came across an example of this on a recent beta test: the new sunspot counting project requires you to select a number, from 0 to 50, from a menu, rather than typing a value in. On a phone, this makes what should be a simple number input quite frustrating to use.

Add the search capability to the SimpleDropdownTask component.

👍 to this. Coordinate with Sam to make sure that you aren't altering the existing dropdown tasks for HMS NHS.

[snblickhan]

Thanks for flagging that project, Jim. HMS NHS is recently complete, so there's no risk of impacting that project. There may be one or two under development, but I wouldn't change any of our plans to account for those teams, since they're in the exploratory phase.

Regarding the point about the max number of options, this post is really helpful (& I'm glad to have it on my radar for future reference), but I think in this case we're an exception for a few reasons. When Cliff and I discussed this change, we felt justified in our decision because we're also adding the search capability, so scrolling isn't a requirement for use. The dropdown use case here is data quality, reducing the risk of typos in the resulting data by restricting input options, in a scenario where people are often transcribing messy or damaged text. They aren't inputting 'familiar' data (as it's called in point 5), users are working to interpret existing text and teams often need that data provided in a specific format for their research use cases.

Interestingly, I think our use case here addresses 3 and 4 simultaneously -- the blog post uses lists of states/countries as an example of when to avoid dropdowns, but we know from beta feedback across multiple projects that users prefer those categories to be presented as dropdowns rather than free-text entry. The post even acknowledges that free-form input requires data validation, and we know that free-text entry is difficult to aggregate, so we have to weigh that in our decision, too, because in a scenario where difficulty with aggregation leads to not using/publishing results we significantly increase the risk of wasting volunteers' time.

All of this is to say that building in this capability won't lead to every project having 200 dropdown options -- it's still our job during project review is to provide this type of guidance to balance UX and data needs and make sure teams are thinking carefully about their workflow & task design.

[eatyourgreens]

I think that's fine as long as we aren't rendering 200 items when the dropdown first mounts. In that case, we don't want a screenreader user to enter the component and have to listen to a list of 200 options before they can start typing. That might be a problem, depending on how the combobox is implemented.

[eatyourgreens]

A talk at State of the Browser today has reminded me that we can build this in modern browsers with the <datalist> element.

The advantage of this is using the native browser APIs. Here, the options are presented as native autosuggest options in iOS.

[kieftrav]

@eatyourgreens - the current SimpleDropdown is built on top of Grommet's Select element. Delilah pointed out to me that the CollectionsModal > SelectCollection element implements Grommet's select+search. From an initial glance, it seems like there are two paths forward:

1. Simplest is to extend the SimpleDropdown in the same way. From what I can tell, the implementation looks like it uses a shadow dom element and some non-standard nesting of buttons within a div to implement the select box. As far as I can tell, we've defaulted to using Grommet's elements everywhere.

2. Modify the SimpleDropdown component to use the <datalist> element. This will simplify the rendered html quite a bit yet will also incur a bit more dev time amount custom CSS development + testing changes.

My personal preference is option 2 yet happy to move forward with option 1 for consistency in using Grommet. Would appreciate your thoughts. The current draft PR does implement Search with the Grommet Select component.

[eatyourgreens]

React doesn't support the shadow DOM, so Grommet uses a bunch of hidden components to implement text search with listboxes. I wrote the ARIA code for the combobox search used by Grommet's TextInput, so that should be pretty accessible: grommet/grommet#6079

That uses the ARIA combobox pattern with a bunch of positioned DOM elements.

<datalist> would be less work, if the native autosuggest UI for the browser & OS works for the type of data that's being validated, since you don't have to reproduce the native keyboard behaviour and accessibility tree with JS.

I haven't looked at the Select component to see how it implements comboboxes, or to see how they work with the keyboard or a screenreader (or how they are represented in the accessibility tree.) I imagine it's probably good. They are commited to accessibility, and very open to receiving PRs too.

[kieftrav]

PR #5382 increases the max limit to 200 and closes this issue.