Create greater visual distinction between filter chips and adjacent buttons #64935
+2
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jameskoster
added
[Type] Enhancement
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +19 B (0%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 0507ff7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10635197050
|
|
How does this border fit into the larger system? It seems to not be broadly applied in this style. |
|
The border would simply be a style property of the chip/token component once formalised.
Could you elaborate? A similar consumer would be an Autocomplete component: 
|
|
I mainly mean that this particular border isn't something I've visually seen in that many other components, so it feels like a "new material". |
|
Outside the scope of this PR, but wanted to understand the reason why there's a distinction between a complete filter chip and incomplete ones. Feel free to point me to a more relevant PR where this is or has been discussed. In terms of UX, if the latter isn't affecting filtering at all, should it even exist? Also noting that the incomplete chip styling (which reads like turned off) is very similar to the search bar (which when in tandem also reads as turned off/disabled). |
It's an affordance so that when there are many filters users can see which ones are active at a glance.
Filters can be added but unset, either by the user or data view config, which means they need to be visible in the UI.
I agree. |
I understand that, but what I'm trying to get to is why does it have to support inactive filters in the first place?
The way I see it, filters serve the purpose of modifying an existing collection of data. An unset filter does not accomplish that and yet adds a UI element that's not relevant. What's the use case for an unset filter? Is it to surface it and make it visible by default? If so, should the accompanying icon be a |
Exactly.
Maybe, yes. But we need to consider that a filter can be added manually, but left unset, in which case the inline |
|
I don't disagree with your assessment, but optimizing for an unset filter — either by dismissing one that is visible by default, or the use case below — sounds like we're not giving users a clear success path.
Again, I'm most likely missing context and have sidetracked the conversation enough here. :) Will think more about this one. |
|
Did you have any thoughts about the changes in this PR? :) |
|
Sorry, @jameskoster — a few loose thoughts: Visually, the border introduces a welcomed distinction. I suspect the light blue is not discernible at all in some screens, and the darker border helps create the boundaries for that element. Not sure it fully passes the squint test, but it's much better than before. Having said that, I recognize the argument that the border isn't a widely used artifact, so it could add inconsistency from the get go. For example, if I look at the screenshots above, it makes me question why the search input doesn't have a border now. Also, from what I understand, the two screenshots above represent two different states. On the second one, the |
|
Thanks, good insights. We can discuss the appearance of the search input in #65323.
I think it's mostly the lighter border that is new here. Secondary buttons include a border much like this one, though it is much darker. It's a similar story with inputs. Perhaps it would be better to spec this up as a dedicated component, with examples of all the different use cases (additional to filters) so that we can make a more informed decision on the design. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Adds a border to filter chips.
Why?
There is arguably too much visual overlap between filter chips and their adjacent ('Add filter', 'Reset') buttons, particularly when hovered.
Before
After
This PR attempts to create distinction by applying a subtle border to the chips. This gives them greater prominence compared with the buttons which feels appropriate in this context.
What do y'all think?
Testing Instructions