WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 weeks ago

#31696 new enhancement

Better select, multi-select, and autocomplete/suggestion inputs in the admin

Reported by: section214 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch dev-feedback
Focuses: ui, javascript, administration, performance Cc:

Description

I know this has been brought up before, but can't find the original ticket. That said, a few months ago Helen brought up a potential integration of the Select2 library but, due to licensing issues, we were unable to proceed with it at the time (GH issue). The licensing issue has now been resolved and, since I've been unable to find the original ticket, I'm opening a new one along with a preliminary patch to add Select2 to core.

At the moment, this patch is based on a new CSS class (select2) being added to any select field that should implement the Select2 library. I've added it to the select fields on the Settings->General page as an example, but didn't want to implement it system-wide until the community had a chance to speak up RE: where does/doesn't Select2 belong, or should it actually be implemented everywhere. The language and timezone fields seemed an obvious choice given their inherent size, but things like the emoji field under Settings->Reading that have a finite number of options seem less obvious.

Discuss!

Attachments (1)

issue-31696-select2.patch (264.7 KB) - added by section214 3 years ago.
Initial patch

Download all attachments as: .zip

Change History (26)

@section214
3 years ago

Initial patch

#1 @afercia
3 years ago

  • Focuses accessibility added

#2 @section214
3 years ago

  • Keywords has-patch added

#3 @helen
3 years ago

  • Keywords has-patch removed
  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Select2 integration in core to Better select, multi-select, and autocomplete/suggestion inputs in the admin
  • Version changed from trunk to 4.1

Going to reframe this ticket a little bit to look at the problem instead of the solution, since it's new. Long select lists are difficult to use, particularly on mobile, and multiple select is even worse on desktop. Short of changing the browsers themselves, we should try to provide a better experience for our users.


I am in favor of making those better in specific places in the admin, which then plugin/theme authors could utilize. Originally, we were considering choosing a library alongside bigger work on #19867 and #9864, but I think at this point we've done enough background research on existing libraries to introduce one now for existing use cases, and continue working on those other tickets assuming a given implementation.

Here is a summary of past discussions and thoughts:

  • Conceptually, suggestions and selections are quite different, and we don't always do this well in core. In multisite, where jQuery UI Autocomplete is currently in place, we abuse it a little bit to handle scaling concerns and it ends up doing both. The admin email address for a new site suggests possible existing user emails but still allows arbitrary input, which is correct behavior, but so does adding an existing user to a site, which by definition should not accept arbitrary input. The former would be an example of suggestion, while the latter is an example of selection as enabled by autocomplete. Ideally, a solution here could handle both cases with appropriate UI for each, as well as things like multi-select and tag-type input.
  • Given the feature set that we need and the details of licensing, we are essentially left with one choice in the current landscape: Select2, which in v2 (in RC as of this writing) has been entirely re-licensed under MIT. Two other libraries were looked at in some detail - Chosen, which has a fairly limited feature set, and Selectize, which is not license-compatible. Creating and maintaining our own solution is not a great idea.
  • Given experiences in the past with external JS libraries and changes that break back-compat, as well as the potential need to someday change libraries or otherwise make some larger underlying change, we need to create our own JS wrapper with instantiation.
  • Anything we adopt needs thorough vetting, particularly in terms of mobile/touch handling and varying accessibility methods. The last time I checked Select2 v2, keyboard accessibility was not the most pleasant experience. This may mean upstream contributions, which is great. I have found the maintainers to be friendly, reasonable, and responsive.
  • Places that would be served better include: timezone dropdown, pages dropdown (with #9864 for scaling issues that we could address using Ajax searching), users dropdown (#19867 for those scaling issues), and tags/non-hierarchical taxonomy input. Each of these flexes different features: option groups, templating (so that hierarchy can be displayed in some fashion), and tag-style input, respectively. We should start with the simplest case and then iterate from there.
  • We should look at implementing testing for every portion we can, whether that's QUnit or otherwise.

I wonder if all of this could be done within a plugin right now, rather than iterating on monster patches which can be quite frustrating and leave untracked files lying around. We were able to do this within a testing plugin, so I imagine it can be done targeting specific items, with a test page for a possible more generic class-based magic instantiation case.

Specific to the proposed patch/approach, and as general advice: class names should be semantic and not tied to the technical implementation, so something like .wp-select would be preferable to .select2. I am not completely sure we should implement this in the end; my instinct is that this should still be chosen deliberately and with thought put into the options to be set, as I am not convinced that all select elements need to be replaced across the board. I would be interested in thoughts on whether it would be inconsistent and confusing to users to keep some native select elements alongside enhanced UI, as well as all of the rest of the above.

#4 @section214
3 years ago

Thanks for jumping in on this Helen! I struggled with where it should be implemented too... that's a big part of why I left it as simplistic as I did. I'm trying to jumpstart the discussion on making this happen, not actually provide the 'perfect' solution.

This ticket was mentioned in Slack in #design by helen. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


3 years ago

#7 @chriscct7
3 years ago

  • Focuses performance added; accessibility removed
  • Keywords has-patch dev-feedback ui-feedback added

This ticket was mentioned in Slack in #design by helen. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #design by ericnkatz. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by helen. View the logs.


3 years ago

#13 @chriscct7
3 years ago

  • Version 4.1 deleted

This ticket was mentioned in Slack in #design by helen. View the logs.


3 years ago

#15 @wonderboymusic
3 years ago

  • Milestone changed from Future Release to 4.4

let's talk about Select2 in 4.4

#16 @rianrietveld
3 years ago

FYI: Accessibility test of Select2: https://make.wordpress.org/accessibility/2015/09/07/accessibility-usertest-select2/

The main problems are:

  • No or not enough feedback for screen readers on what is selected or what can be selected (list items are announced as “blank”.)
  • No feedback about how many search results.
  • The select dropdown does not behave like a user expects
  • Select2 has at the moment too many accessibility issues to be included into WordPress core

We opened an issue on the Select2 GitHub: https://github.com/select2/select2/issues/3744

This ticket was mentioned in Slack in #core by sergey. View the logs.


3 years ago

#18 @wonderboymusic
3 years ago

  • Milestone changed from 4.4 to Future Release

If there's movement, move it back

#19 @westonruter
3 years ago

Just wanted to note here that along with improving the scalability of the dropdowns for users (#19867) and (#9864) this is also keenly needed for categories (wp_dropdown_categories()) and any such taxonomy term listing. I've been working on a site with thousands of categories, and because the number is so large it is very difficult to navigate the dropdown. But the even worse thing is that the large category list started killing the PHP process due to the memory limit overrunning. So I implemented an Ajax lazy-loading of the entire category list to solve this later problem, but the better solution would be to combine it with Select2 and provide an autocomplete UI. I'm sure this has all been discussed before :-)

This ticket was mentioned in Slack in #themereview by celloexpressions. View the logs.


2 years ago

This ticket was mentioned in Slack in #accessibility by poena. View the logs.


2 years ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


13 months ago

#23 @karmatosed
13 months ago

  • Keywords ui-feedback removed

As discussed in #design triage this isn't needing ui-feedback yet.

This ticket was mentioned in Slack in #core-privacy by azaozz. View the logs.


2 weeks ago

#25 @desrosj
2 weeks ago

Noting that the Privacy Policy dropdown on the Settings > Privacy page introduced in 4.9.6 would also benefit from some type of autocomplete field.

Note: See TracTickets for help on using tickets.