Uniform Search Form Display/Experience

[Cheffheid]

In our recent testing of the search functionality we've found that there are currently five different search types across the admin.

A full description of what the tests entailed, their results, and a link to the Slack discussion can be found here: ​https://make.wordpress.org/accessibility/2015/03/30/usertest-the-search-functions-in-the-admin/

To summarise, these are the five that we've found:

• Search input without submit button, no live search (need to press Enter)
  • e.g. Media Library list mode
• Search input without submit button, live search fires “as you type”
  • e.g. Media Library grid mode, Themes (add new, wp.org API), Network Themes (add new, wp.org API)
• Search input no submit button, live search fires “as you type” (more a “filter current collection” than a search)
  • e.g. Themes (installed themes), Customizer add widget, Plugins (installed plugins)
• Search input with hidden submit button, press Enter or tab and submit the hidden button (after the search, the “typeselector” select appears)
  • e.g. Plugins (add new), Network Plugins (add new)
• “Classic” search: search input with submit button, press Enter or submit button
  • e.g. Posts, Categories, Tags, Pages, Comments, Users, Network index: search users, Network index: search sites, Network Sites, Network Users, Network Themes (installed), Network Plugins (installed)

What we'd like to propose is to bring this down to two and ensure they work well. This could then be used as a launchpad to further unify the search experience and use a single type across the board.

The lucky two would be:

• the classic one, the same for every search, with visible submit button (already commonly used)
• the dynamic one, with some improvements like adding wp.a11y.speak to show the results count, and making sure focus doesn’t change dynamically

[afercia]

Related: #25103

[afercia]

Related: #27304

[afercia]

See the idea for Twenty Sixteen about search fields with no visible submit button: ​https://github.com/WordPress/twentysixteen/issues/279

[afercia]

Some resources to start with, mostly about placeholders:

​http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute
The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format ... The placeholder attribute should not be used as a replacement for a label.

​http://www.w3.org/WAI/tutorials/forms/instructions/#placeholder-text
Placeholder text provides instructions or an example of the required data format inside form fields that have not yet been edited by the user.

​http://www.w3.org/WAI/GL/wiki/Using_@placeholder_on_input
The objective of this technique is to use the placeholder attribute to assist users with data entry ... must have a value that is a short hint, word or phrase ... is not a substitute for the label element. Placeholder text can help people with cognitive disabilities see an example of the type of data they can enter.

=====

HTML5 Accessibility Chops: the placeholder attribute
​http://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/

Creating Accessible Forms
​http://webaim.org/techniques/forms/advanced#invisible
Placeholder text (e.g., <input type="text" placeholder="Search WebAIM">) is not a suitable label and should never be used in place of the above techniques.

Using the HTML5 placeholder attribute
​http://tink.uk/using-the-html5-placeholder-attribute/

The HTML5 placeholder attribute is not a substitute for the label element
​http://www.456bereastreet.com/archive/201204/the_html5_placeholder_attribute_is_not_a_substitute_for_the_label_element/

Placeholders in Form Fields Are Harmful
​http://www.nngroup.com/articles/form-design-placeholders/

Don’t Put Labels Inside Text Boxes (Unless You’re Luke W)
​http://www.uxmatters.com/mt/archives/2013/02/dont-put-labels-inside-text-boxes-unless-youre-luke-w.php

Mobile Form Usability: Never Use Inline Labels
​https://baymard.com/blog/mobile-forms-avoid-inline-labels
(see the paragraph about "Exceptions")

[afercia]

Related: #35121.

[afercia]

Related: #37353.

[afercia]

Related: #38211

[afercia]

Related: ticket:37233#comment:21

ideally it should trigger after 2 ASCII chars or one high UTF-8 char. We can standardize this for all similar cases in core, there are at least 6-7 other places.

[afercia]

About the "live search" used here and there in the admin, one more thing to address is the delay after which the search gets triggered. In some places it's set to 500ms in other places to a different value, for example 300ms, see [40060].

Ideally, since users have different needs and each one has a favorite typing speed, this should probably be a user option to set for all the live searches in the admin. Cons: yet another option...

[lukecavanagh]

@afercia

Maybe the delay options, could just be shown just for admin users only.

[rianrietveld]

I wonder if many users know what a delay is and search for an option to change it if they think it's too short.

[afercia]

We should probably consider this:

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes ...

​https://www.w3.org/TR/WCAG20/#keyboard-operation

[ocean90]

#40222 was marked as a duplicate.

[afercia]

Note: on #40222 (closed as duplicate) there are some useful screenshots.

[Travel_girl]

Replying to afercia:

About the "live search" used here and there in the admin, one more thing to address is the delay after which the search gets triggered. In some places it's set to 500ms in other places to a different value, for example 300ms, see [40060].

Ideally, since users have different needs and each one has a favorite typing speed, this should probably be a user option to set for all the live searches in the admin. Cons: yet another option...

I'm not sure, if users could make this decision, as I guess the most people don't know what their should set.

I think my favorite is an Action button with "Search Plugin" or "Search Themes". Even if this is one more click, its quite of an clear action.

[Travel_girl]

At the moment we have two different kind of an search. I think the main question is, which version we should use for all of those search-fields.

1. with Button like in "Search Posts"

or

2. without Button like in "Search Plugins"

[Travel_girl]

plugin search

[Travel_girl]

Search Posts

[afercia]

Replying to Travel_girl:

Replying to afercia:

About the "live search" used here and there in the admin, one more thing to address is the delay after which the search gets triggered.

I'm not sure, if users could make this decision, as I guess the most people don't know what their should set.

Many people can't use a standard keyboard or mouse and when using alternate input and pointing devices, on-screen keyboards, etc. the typing speed is very different. To get an idea of how some of these devices work and how people uses them, this video is great:
​https://www.washington.edu/doit/videos/index.php?vid=30
I guess these users would know how to set their favorite typing speed.

At the moment we have two different kind of an search.

I think there are at least 5 different patterns, as mentioned in the ticket description :) It would be great to reduce them at least to two and make them as accessible as possible.

[Travel_girl]

@afercia what is more accessibly? A search-field where the search starts while typing (like in plugins)? or a button after the search field like "search posts"?

about the setting of the favorite typing speed:

there is a ticket #37934 to seperate the account and profile settings into two pages. Maybe we could include this settings in the profile pages?

[afercia]

Replying to Travel_girl:

@afercia what is more accessibly? A search-field where the search starts while typing (like in plugins)? or a button after the search field like "search posts"?

The latter, of course. An ideal search field would be:

• visible label, correctly associated to the input field with a for attribute
• input field with no placeholder (unfortunately, many designers like to use placeholders in a way that's against the specification)
• visible button to trigger the search

Not to mention that also the search results should be presented in an accessible way.

However, over time, several "live searches" or "search as you type" or whatever we want to call them, have been introduced in the admin. They're tightly coupled with the underlying JavaScript based functionalities. They're often integrated into the design, see for example in the Customizer. Personally, I'd really like to change all of them and add a label and a button. And remove the placeholder. I'm afraid this would not gather so much consensus though.

[afercia]

Punting as we're running out of time for the 4.8 release.

[afercia]

#40391 was marked as a duplicate.

[afercia]

In the "live search", when user start typing the search should be debounced. Quoting from @swissspidy suggestion on #40391:

What I mentioned before is that we could pass this timeout to the live search JavaScript using wp_localize_script(), thus making it possible for plugin authors to filter that value.

[paaljoachim]

I think we should have one search bar up in the top admin toolbar.
As one begins to write suggestions show up with a clear distinction if it is within the posts, plugins, pages or anywhere else inside the backend. (If one is on the frontend. Results would show up from what is on the page on is currently on.)
It would create a much cleaner and easier search for anything we are looking for.

[Mista-Flo]

It would be nice to get some Design guidance to uniform all the search boxes inside the admin. That way a developer could start working on a patch and get some a11y feedback.

[afercia]

Thanks @Mista-Flo. I'd say in this specific case, since this is mainly an accessibility issue and the ticket was created by the accessibility team and marked sn an a11y-task, it would be best to inverse the process and get first some well defined accessibility requirements and then design feedback :)

[Mista-Flo]

Sure, sorry for my lack of knowledge about the process. It definitely makes sense.