Query filters and search usability #603
Replies: 7 comments 14 replies
-
|
Hmm @dd32 made a good point.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for opening a discussion for this. Results and sort area
I worked on an idea time ago that addresses these two points and looks similar to yours. It splits the search area into two rows: Search and filters; and Results and sort. Here is the mockup I made with Showcase in mind.
The first row has the search input on the left, and filter actions or preset filters on the right. The second row shows the results and a sort action that only changes the order of the results. This second point is important to conceptually separate the amount of results from how it's ordered. I've been advocating this idea in other discussions, but now it's time to reconsider it. Pre-filter view
This is great feedback. If we want to continue with showing Curated patterns, placing the single-selection filter as buttons would make it more explicit. In that vein, the tab area needs to look different than regular buttons to prevent users expecting the same behavior. Here is a previous idea I explored but with tweaks based on your suggestion.
Results label
Curious about how this works. The label should convey the amount of what's below. |
Beta Was this translation helpful? Give feedback.
-
|
I like this approach. Feels clearer to me. |
Beta Was this translation helpful? Give feedback.
-
This was intended to mirror showcase, again — on Showcase's homepage, the query total is the total number of sites available, even though that query is just "featured". The same thing was happening on Patterns, until just before launch when we had to switch everything back to curated and pull out the separate archives. Showcase, if it used the real current query, would say 18 sites here. In any case, that can be updated on Patterns if it's deemed a bug here, just make a new issue or I can create a new issue. |
Beta Was this translation helpful? Give feedback.
-
|
I agree. This feels much more intuitive to me and highlights that it's a filtered result set. Of these changes, I think pulling out the all/curate/community options from the dropdown is the best first step. Along with updating the "tab" look for patterns. If we were to go with that we could immediately use it on the first iteration of plugins & themes and have it work logically later.
If we wanted more visual distinction, we could also consider a button group which is essentially how this works: 
This may not work longer term for plugins though if we end up with all/community/commercial/canonical. A button group of four with very long text feels weird. |
Beta Was this translation helpful? Give feedback.
-
|
One more thing to consider is that plugins would likely have both dropdown filters and the "all/community/commercial" toggles. |
Beta Was this translation helpful? Give feedback.
-
|
To @ryelle
I understand. It makes sense conveying the total amount. The label does not relate a search action.
If we decide going with this pattern, then I would appreciate if can create the issue. Curious about @jasmussen's thoughts on removing the label in Showcase to avoid confusion between "total items of the repository" and "results of the term typed".
It looks confusing showing two labels for search results and total items. I would show just one.
Because of this is that I would not add the wrapper border. Instead, I would keep it simpler and see whether it works. |
Beta Was this translation helpful? Give feedback.
-
|
The video below illustrates what might be a temporary solution (that's already partially implemented) until we have a more holistic site-wide solution. cc @ryelle 
patterns.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
Is the "partially implemented" because it's not there on the homepage? I explained that one above but it sounds like now that we've pulled the archive page/homepage is no longer a unique featured set, I should remove the special handling. |
Beta Was this translation helpful? Give feedback.
-
|
The two places that seem to not have it are search archives and the homepage. By "partially implemented," I didn't mean to imply it was a mistake or anything, just that the extra descriptor was only implemented in certain spots.
Yeah, I personally think it would make sense to do so since the homepage is now paginated. This would also be the simplest solution to making the number of patterns displayed more clear. |
Beta Was this translation helpful? Give feedback.
-
|
It appears like I'm piling on questions, so feel free to guide me in a different direction, but I'm also curious why we chose to put the search field below the tabs. I feel that puts unnecessary cognitive load on the user to find the best category to search from. If we look at some of the top searches for the pattern directory: "Contact", "Blog", "Footer", "Hero", "Header", "About", "Services", "Menu", "Pricing" and "Faqs", it isn't clear to me what category I would need to search from since most don't match nicely. If I started by browsing and then decided to search after not seeing what I was looking for, there's a very high chance that I'm in the wrong category and would see no results until I instinctively click "all". I suspect this will be the same problem for all the directories. To me, it feels much more intuitive to have the search bar above the tabs and on search, default back to the "all" category. When users click through the tabs the search would be persisted. 
|
Beta Was this translation helpful? Give feedback.
-
Yeah, I like the layout you proposed, Steve, if we can get it to work that way.
Agreed. |
Beta Was this translation helpful? Give feedback.
-
We could change that technicality, if it would help smooth this out — so that, for example, a user could search for "pricing" and then click "Banners" to get that combined filter, "Banners + search term 'pricing'".
Yes, ideally we can figure this out now, so that we can implement it consistently across the other sites. |
Beta Was this translation helpful? Give feedback.
-
|
To @ryelle
That sounds great. My only concern is investing effort in something that could change again and go further beyond the scope of style update. I'm drawn to keeping this change simple, trading off some level of consistency, and revisiting the single search flow for all repositories once we're done with this update stage. My assumption about effort might be wrong, so I follow your suggestions on this change. |
Beta Was this translation helpful? Give feedback.
-
Some change is expected, but the purpose of this ticket is to find a more steady state so I'm curious about what future updates that you see that may introduce a bigger paradigm shift. |
Beta Was this translation helpful? Give feedback.
-
|
What I have in mind so far is a UX flow where search input is the predominant action and all categories are one/multiple filters on the right. The search action and filters refresh the page without users "leaving it". Applying filters through single or multiple selection occurs in popovers that also refresh the page as you select them without the current "apply" button. That outlines my ideal scenario for the main repositories: Themes, Patterns, and Plugins. |
Beta Was this translation helpful? Give feedback.
-
|
Noting that I've rephrased the title of this discussion to reflect the wider feedback it's been generating — all issues with the query filters + search, not just related to the total label. |
Beta Was this translation helpful? Give feedback.
-
|
Being able to "clear" the search form has come up a few times:
The idea is to get back to the archive view of whatever you're viewing, I think — in Patterns, the workaround was to add the breadcrumbs, which gives you the "All patterns" link back to home (this mirrored Showcase, despite Search not actually being an "L3" page here).
The same is not true on the theme search or plugins search.
|
Beta Was this translation helpful? Give feedback.
-
|
Just to cross-link a few other issues, these all relate to how the combination of search, filters, category navigation all work together.
Updated with new links Aug 28 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for curating all of them. |
Beta Was this translation helpful? Give feedback.
-
Context
As part of the pattern directory launch, I ran user testing on the directory, the notes can be found here. The three users I interviewed had a difficult time understanding that the result set was currently being filtered by the "curated" option. I think there are 2 fixes for that:
In this discussion, I would like to discuss the second one "Be more verbose about the result set context.".
The Problem
The problem is much more pronounced because of the auto-applied curated filter in the pattern directory.
Take the landing page for example [I removed all the patterns for a better screenshot]:
User testing revealed the following:
1,875 patternslong based on the query total1875patterns from the Query total block but only 2 pages.Their feedback suggested that we could do more to explain the current state. I think we have the opportunity to do it better with the Query Total block.
I propose that we give users a verbose and visual indicator that the result set is filtered as close as possible to the interaction zone.
Can we:
Screenshots
Beta Was this translation helpful? Give feedback.
All reactions