Shiny Updates: "Installed Plugin" shiny search issues

[afercia]

In the Installed Plugins screen, the search is now a "live" search, meaning the results will be updated live as you type.
I'm all for improvements like this one, however I've noticed some issues. I'm sorry for being a bit late but to be honest I've missed the "Shiny Updates" was going to be also a "Shiny Search". I've quickly discussed this with @swissspidy at WCEU in Vienna and hopefully there's still time to address the main issues.

When a functionality changes behaviour, the interface should preferably reflect the change to inform users that something works in a different way now. By the way, there are no visual UI changes or any instructions to inform users about this new behaviour. WordPress is already using "live" searches, for example in the Themes screen and in the Customizer, and the new Plugin search should follow the previous implementations, also for better consistency.

Some points:

1. When JavaScript is on and the live search works, the submit button "Search Installed Plugins" is useless and maybe even confusing for users. The interface should suggest users this is a "live" search. Maybe consider to hide the button when JS is on. When JS is off, the search works with a traditional page reload and needs a submit button.

2. The "Live" search field should be visually clearly distinguished from "standard" search fields, this is material for designers :) wondering if any design feedback has been asked for the new search?

3. For accessibility there's the need to inform users using an aria-describedby attribute on the search field, as already done for example for the Themes search, that points to an element with a description, preferably using the same text: "The search results will be updated as you type." By the way, when JS is off this aria-describeby attribute should not be used.

4. For accessibility, there's the need to announce the number of search results otherwise users will experience a total lack of feedback. This should be done also for consistency with the Themes live search: all the "live" searches should work consistently across WordPress.

5. The live search doesn't work in IE 8 and gives a JS error (IE 8 doesn't know what history is...), I guess this is the same for IE 9.

[FolioVision]

These are great points Andrea.

1. It's essential to have an attractive search button appear when js is turned off.
2. The language for the live search field could say inside the search box "Type a plugin name here" for the first couple of releases with new live search. It's a bit mundane but better to make it easy for the user. I'm not sure we need additional visual accent for live search as as soon as you type, you'll discover the live part.
3. As IE 8 is a dying beast, perhaps we could give IE8 the non-live search normally reserved for non-javascript users.

Alec

[swissspidy]

37230.diff​ is a first pass at a patch to address the concerns raised above.

1. Hides the submit button when JS is enabled and changes the search input styling to match other live searches (e.g. on the Add Plugins and Manage Themes screens). This includes a placeholder text
2. Adds an aria-describedby attribute to the search input when JS is enabled, including the appropriate help tab content.
3. Announces the number of search results, like on the Manage Themes screen.
4. Adds if ( history.pushState ) { … } checks for IE9 and older.

[swissspidy]

The input field with the patch applied

[afercia]

Tested and works great. Just a couple of things as for now:

• not sure about the search event because it's not standard and because in many other places in WordPress there's an ongoing effort to standardise on using input and keyup events. input will work also when pasting a search term with a right click. keyup just needed to support IE8 and to filter keys, if necessary. Would appreciate @azaozz thoughts on this :)
• just on Safari, noticed a small visual glitch related to the -webkit-search-cancel-button. Seems this happens also on other input fields, for example on the Themes screen and maybe related to the font-size: 16px` set on the search field, see screenshot below

[swissspidy]

37230.2.diff​ changes the events to keyup and input as search is non-standard.

It also adds the possibility to clear the search field using the esc key, like on the themes page.

I couldn't reproduce the Safari glitch, though I'm currently using Safari 10.0 Beta.

No feedback received from the design team yet, but I think we could commit this already and adjust styling later if needed. Opinions on that?

[swissspidy]

Removes some files that made it into the previous patch by accident

[ocean90]

In 38033:

Plugins: Improve Ajax search of installed plugins.

Fixes a few accessibility issues, tweaks the design of the search form to match other Ajax search fields and improves compatibility with older browsers.

See #37230.

[mapk]

I think the search is looking really good design-wise. I have a design improvement for the search keyword display.

Let's add a colon after the word 'for'. Then also remove the quotes from around the keyword term and make the keyword bold and black. Like this:

So now if I include quotation marks in my search term, it will make more sense. Let's also make sure to have this reflected in the 'no results found' msg in the table too as I've mocked up below.

Outside of this, everything looks great!

[mapk]

Oh, and can we drop the ellipses (...) from the placeholder text in the search input field? Those drive me nuts. AND it looks like we're using Sentence Case (only capitalizing the first word) in the input field's placeholder text too, which is good, but let's have that reflect on the plugin-install.php page as well. Right now the plugin-install.php page is using Title Case.

plugins.php

plugin-install.php

[afercia]

+1 for standardising ellipses and sentence/title case on all the search fields across the admin screens :) looking for example at the inconsistencies on some screens:

themes.php
theme-install.php
plugins.php
plugin-install.php
upload.php (list and grid)
Customizer > search menu items
Customizer > search widgets

this would probably need its own ticket.

[swissspidy]

Thanks a lot for your feedback!

Since the search keyword display and the placeholder text haven't changed as part of Shiny Updates, I'd really optimize those in a separate ticket.

For example, edit.php and comments.php display the search keyword the same way as plugins.php. These should all be looked at at the same time.

I opened #37353 for this purpose.

Closing this one as fixed. Thanks all for your help!

[ocean90]

In 38141:

Plugins: Make search field placeholder translatable.

See #37230.

[ocean90]

In 38146:

List Table: Improve WP_Plugins_List_Table::search_box() which was added in [38033].

• Update DocBlock to use third-person singular verb and to include a period at the end.
• Use submit_button() for the submit button.
• Escape the ID attribute.
• Apply the same to WP_List_Table::search_box().

See #37230.