Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify the search fields #56388

Open
afercia opened this issue Nov 21, 2023 · 9 comments
Open

Unify the search fields #56388

afercia opened this issue Nov 21, 2023 · 9 comments
Labels
Needs Design Feedback Needs general design feedback. [Package] Edit Post /packages/edit-post [Package] Edit Site /packages/edit-site [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Nov 21, 2023

Description

In a few places in the editor, a 'Search' field is in use. There are a few occurrences that are largely inconsistent, both visually and in terms of labelling, semantics, usage of the placeholder.

I'm not sure why there's such inconsistency. To me, it makes sense to establish a well defined pattern that is the best for visuals, usability, accessibility, and then reuse that pattern where necessary. Instead, having serch fields that look all differentand are labelled inconsistently doesn't help user experience and adds unnecessary cognitive load.

A few examples:

In the Patterns explorer modal dialog:

patterns search

In the (so far experimental) Dataviews > pages:

dataviews pages search

In the Fonts modal dialog:

fonts search

@WordPress/gutenberg-design I'd think this is a good case to add to the design system documentation, see #53615. That would help contributors to this project to be trained and educated to re-use existing, established, patterns instead of introducing inconsistent ones.

Step-by-step reproduction instructions

  • Observe the inconsistent Search fields at the following locations:
  • Post editor > Inserter > Patterns > Explore all patterns
  • Enable the 'New admin views' experiment and go to the Site editor > Pages > Manage all pages
  • Site editor > Styles > Typography > Manage fonts (the Aa icon button) > Install Fonts

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@afercia afercia added [Type] Bug An existing feature does not function as intended Needs Design Feedback Needs general design feedback. [Package] Edit Post /packages/edit-post [Package] Edit Site /packages/edit-site labels Nov 21, 2023
@jameskoster
Copy link
Contributor

I don't know that the visual DNA of a search input needs to differ from any other input type. So I'd lean towards the fonts approach (with the icon on the left) rather than the Inserter one here.

@ciampo what's the best way to proceed here? Could SearchControl make use of InputControl?

@richtabor
Copy link
Member

Just noting that command palette also uses icon on the left:

CleanShot 2023-11-22 at 15 12 45

@ciampo
Copy link
Contributor

ciampo commented Nov 25, 2023

what's the best way to proceed here? Could SearchControl make use of InputControl?

I can look into rewriting SearchControl using InputControl internally, and moving the search icon to the left.

@mirka
Copy link
Member

mirka commented Dec 27, 2023

@WordPress/gutenberg-design Just to check, I noticed that one potential downside of the "icon on left" layout is that we will need to show a separate close button on the right edge, taking up that much more space. Whereas in the "icon on right" layout, we can just dynamically switch it to a close button. This may be inconvenient in width-constrained areas like sidebars, especially with the large size variant. Are we ok with that?

Search field with both a search icon and a close button

@jameskoster
Copy link
Contributor

I think this is ok, the container would have to be extremely narrow for this to be an issue.

Generally icons found at the right of an input are interactive (e.g. clear text, show password, dictate), while icons on the left are more decorative. Since the current design violates that heuristic the trade-off seems worth it.

@t-hamano
Copy link
Contributor

t-hamano commented Feb 9, 2024

Related to this issue, what do you think about completely removing the gray background color or making it a lighter gray? As I recall, I may have seen an issue somewhere that mentioned this gray background color.

The current placeholder text color uses the browser's user agent style. In my environment it is #757575. On the other hand, since the background color is #F0F0F0, the current contrast ratio should be 4.04:1.

image

If we assume the background color is white, the contrast ratio should be 4.6:1.

@jameskoster
Copy link
Contributor

what do you think about completely removing the gray background color

In the vast majority of cases I see no reason for SearchControl do differ significantly from any other text field.

@t-hamano
Copy link
Contributor

Regarding the background color, I investigated why it was applied only to this component:

  • Background color was added in #20951 as part of the block pattern UI iteration. At this time, the SearchControl component did not exist yet. The lack of border and gray background color was also pointed out in this comment.
  • The SearchControl component was added in #32935. At this time, it seems that the no border and gray background color styles were inherited.

@jameskoster
Copy link
Contributor

Perhaps the next step here is to open issues with updated design specs for TextControl and SearchControl. Taking a wider look can probably provide guidance on the background color and icon placement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Feedback Needs general design feedback. [Package] Edit Post /packages/edit-post [Package] Edit Site /packages/edit-site [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

6 participants