Make WordPress Core

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#36908 closed defect (bug) (fixed)

Customizer menus and widgets "search" usability and visual improvements

Reported by: afercia's profile afercia Owned by: afercia's profile afercia
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: has-screenshots has-patch commit
Focuses: ui, accessibility Cc:

Description

The search fields for available menu items and available widgets look similar, even if behind the scenes they do very different things. But from a user perspective they are very similar.

I'd propose to improve a bit the UI. In the Menus, the search field has a type=text attribute while in the widgets has a type=search attribute. This introduces some inconsistency, both from a visual and functional perspective.

Worth reminding not all browsers display a control to clear the input field when it has a type=search attribute. See in the screenshots below:

https://cldup.com/dhC-gbR15a.png

At the very least, I'd propose for the Menu items search:

  • increase the "Clear results" clickable area
  • use some right padding on the input field since when the search terms are very long, the text goes behind the spinner and the "Clear Results" control
  • IE11 and Edge display a native "clear" control also for type=text input fields that should be removed, see screenshot below

https://cldup.com/niQbmZlYq5.png

Not sure about the widgets search field, ideally it would be great to pair it with the menu items search and implement the same custom control to clear the field.

See also #36903 which proposes to use a button element for the Menus search field.

Attachments (1)

36908.diff (15.5 KB) - added by afercia 8 years ago.

Download all attachments as: .zip

Change History (17)

#1 @melchoyce
9 years ago

That proposal looks good.

Would it be possible to sneak another design enhancement into here? I keep seeing in user tests that folks are trying to use the search field to create new menus. I think adding a "search" icon into the fields could help clarify the purpose of the search fields more clearly than just the placeholder text:

https://cldup.com/5kCBqFhMsg.jpg

We could do the same thing for the widgets search field as well.

Last edited 9 years ago by melchoyce (previous) (diff)

#2 @celloexpressions
9 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version set to 4.3

Looks good to me as well, and +1 for adding a search icon to both.

#3 follow-up: @lukecavanagh
9 years ago

Seems like a solid idea. What is the real world use like for using widgets in the customizer vs using widgets in Appearance > Widgets?

#4 in reply to: ↑ 3 @melchoyce
9 years ago

Replying to lukecavanagh:

Seems like a solid idea. What is the real world use like for using widgets in the customizer vs using widgets in Appearance > Widgets?

I've used Appearance > Widgets to fix typos, but to be honest, aside from that use case I'm not sure I've even touched the admin widgets screen since widgets debuted in the Customizer. Being able to see the widget when you add it has made a nice impact on the site setup experience, IMO.

#5 @lukecavanagh
9 years ago

I guess it would depend on if a user had a lot of different widget areas they needed setup for a site. Had a similar case where there where almost 15 different sidebars, then each sidebar had 4-5 widgets on it. So in that case using Widgets in Appearance made more sense. But it is very handy to have the widgets within the customizer.

#6 @ryankienstra
8 years ago

Pull Request
Request For Review

Could you please review this GitHub pull request? Here's a screenshot of the search field that appears on clicking a menu's "Add Items" button.

One open question is whether the "widgets search field" should have the "same custom control" (red "x" button). So far, this only appears in the menu search field.

This ticket's description states:
Not sure about the widgets search field, ideally it would be great to pair it with the menu items search and implement the same custom control to clear the field

Last edited 8 years ago by ryankienstra (previous) (diff)

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


8 years ago

#9 @westonruter
8 years ago

  • Owner set to afercia
  • Status changed from new to reviewing

#10 follow-up: @celloexpressions
8 years ago

  • Milestone changed from Future Release to 4.7

Tested and the patch works well. @ryankienstra I think the widget search should also have the close icon that's now in menus. The search icon color might be a bit too dark and there might be a bit too much padding-right on it, what do you think @melchoyce? This should be close to if not ready for commit though.

#11 in reply to: ↑ 10 @melchoyce
8 years ago

Replying to celloexpressions:

Tested and the patch works well. @ryankienstra I think the widget search should also have the close icon that's now in menus. The search icon color might be a bit too dark and there might be a bit too much padding-right on it, what do you think @melchoyce? This should be close to if not ready for commit though.

From the screenshot: I think even padding (equal on left and right) works well around icons. It does look like there's a little more padding on the right. I also agree the search icon's a little too dark — I'd try either #72777c1, or even #b4b9be if we want to go really light.

#12 @afercia
8 years ago

Some screenshots with the patch applied (didn't apply cleanly) where I've added a background just to clearly see the icon positioning:

Menus: needs improvements for the responsive view

desktop:
https://cldup.com/qBwmRKIqfF.png

responsive:
https://cldup.com/blS0UlhIs2.png

Widgets (the "x" icon is the Chrome native thing for search fields.):

desktop:
https://cldup.com/jGwRoMfbCy.png

responsive:
https://cldup.com/t6uEWnvCQb.png

However, I'd consider as first thing to try to have the same markup and functionality. Any reasons why oen field must be of type "text" and the other one of type "search"?

Version 0, edited 8 years ago by afercia (next)

#13 @afercia
8 years ago

Worth reminding grunt patch:https://github.com/xwp/wordpress-develop/pull/153 can be used to test the "patch".

@afercia
8 years ago

#14 @afercia
8 years ago

  • Focuses accessibility added

Starting from @ryankienstra patch (thanks!) I've tried to do my best to pair the search widgets functionality with the menu items one. Trying to summarise:

  • because of native fonts, the input fields have a different height depending on the platform/browser used; this complicates the positioning of the icons and there's the need to have a fixed, predictable, height of the input field
  • other elements sizes and positions depend on font sizes, line heights, etc., so they should (ideally) be the same
  • adjusted the positioning of the elements below the search fields, should be consistent between widgets and menus now
  • all the input fields in WordPress have a 1px margin by default, so in order to correctly center the search fields one option is to reset at least the left and right margins; maybe worth considering to do this globally in the Customizer
  • moved some CSS to customize-controls.css, this could be further improved see #37873
  • the search icon color is now #72777c /cc @melchoyce
  • under a 640px viewport the widgets search field container background color is now the same of the menu items search (was white)
  • the widget search field is now of type "text" (was "search")
  • added a hidden description for the widget search field, targeted by aria-describedby
  • added the clear-results button to the widgets search
  • removed the change and search events bound on the widget search, for these "live searches" WordPress should standardize on input (+ keyup when needed)
  • added property and function to keep track and update the number of available widgets search results
  • the widgets search results are now announced via wp.a11y.speak()
  • added a visible and audible message when there are no widgets search results
  • some JS refactoring to "cache" jQuery elements

Some testing would be nice :) @celloexpressions any feedback about the CSS changes welcome!

Screenshots while testing the icons position, backgrounds are for testing purposes:

https://cldup.com/4j5MQg7ajg.png

https://cldup.com/D0d-ea3L6q.png

https://cldup.com/LFrPWkIg8b.png

The aria-live message in action:

https://cldup.com/hERsuPTNsd.png

Last edited 8 years ago by afercia (previous) (diff)

#15 @celloexpressions
8 years ago

  • Keywords commit added

Great work @afercia and @ryankienstra!

I found two bugs, but verified that they're existing without the patch as well:

  • On mobile, for menus, there is a double scrollbar when there are a lot of results. I confirmed that this was an existing issue, so we can address it separately.
  • Also unrelated to these changes, search results are cleared when the first infinite-scroll load happens if there are no more items (the initial results need to exactly match the number of items requested initially).

Based on that, I think this is ready for commit.

#16 @afercia
8 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 38709:

Customize: Improve the widgets and menu items search.

  • adds a "search" icon into the search fields
  • adds a hidden description for the widget search field, targeted by aria-describedby
  • adds the "clear-results" button to the widgets search
  • removes the change and search events bound on the widget search, for these "live searches" WordPress should standardize on input (+ keyup when needed)
  • adds property and function to keep track and update the number of the widgets search results
  • the widgets search results are now announced via wp.a11y.speak()
  • adds a visible and audible message when there are no widgets search results
  • moves some CSS to customize-controls.css

Props ryankienstra, melchoyce, afercia.
Fixes #36908.

Note: See TracTickets for help on using tickets.