WordPress.org

Making WordPress.org

Opened 15 months ago

Last modified 5 weeks ago

#2753 new enhancement

Plugin directory search sorting and filtering

Reported by: tellyworth Owned by:
Milestone: Plugin Directory v3 - Future Priority: normal
Component: Plugin Directory Keywords: needs-design has-ui-feedback needs-screenshots
Cc:

Description

We bumped sorting and filtering from the v3 launch, so it's time to revisit.

Implementing both is straightforward on the back-end, the main issue is the UI: where to put it, how to make it helpful and accessible. This is a general ticket for discussion and progress.

Attachments (4)

mock-search-results-sort.jpg (106.9 KB) - added by joyously 14 months ago.
How about if the sort is very simple, at the top.
mock-Search-results-sort-mobile.jpg (57.2 KB) - added by joyously 14 months ago.
And a sort control on a small screen
mock-Search-Results-Refine.jpg (174.1 KB) - added by joyously 14 months ago.
The filters could be hidden until the Refine Search button is clicked, at which point they appear in an overlay (could slide out from the side or whatever).
mock-Search-Results-Refine-mobile.jpg (87.3 KB) - added by joyously 14 months ago.
The filter overlay on small screen.

Download all attachments as: .zip

Change History (34)

#1 @gibrown
15 months ago

Some proposals for the scope of this change.

There are a number of open issues that involve browsing, sorting, or finding plugins that are orthogonal to just searching. Here's a list of the ones I found:

  • #2624 : view all the plugins for a particular author
  • #2631 : find recently updated plugins
  • #2653 : /browse/new and /browse/updated and /browse
  • #496 : /browse/popular - this one is really about deep paging

I'd like to propose that we solve all of these by adding faceting/filtering and then redirect from those paths to the search with the appropriate parameters for sorting/filtering. Some of these are kinda narrow use cases, but there is some overlap between them all.

List of features we need to add to search to satisfy all of these:

  • matching all plugins with search. If the search is blank then we run a match_all query and get back everything based on whatever filters/sorting are set.
  • filtering by author login
  • descending sort by update date range
  • either descending sort by plugin first publish date, or a filter on plugins created in the last three months
  • descending sort by active_installs or rating, or a combo. (or maybe the default alg with a match_all will work ok?)

Those use cases drive some decisions on what to allow sorting on. I'd suggest we support three cases (there are dozens of possibe fields we shouldn't add too many):

  • Current sort. More or less most popular, though maybe we should be stronger and call it "recommended" or something? It pretty heavily weights getting users support and plugins that stay up to date.
  • Recently updated - sort by plugin_modified
  • Average Rating descending - this should probably be a combo of number of reviews and ave rating so a single 5 star rating does not put a plugin above one with a 4.9 rating from 1000 users. #2686 has some interesting thoughts in it.

I left out "sort by date_gmt" with the thought that a filter can solve that and having a filter for that would make for both a better user experience and help new plugins find users. I was thinking of something similar to this Amazon "New and Upcoming" facet

https://cloudup.com/cUSzYLxRarc

It feels like it does a better job at inviting the user to click than a sorting option would because it gives you a promise that there is something inside.

Some other proposed facets:

  • Average rating: (just stolen from Amazon) 1 and up, 2 and up, 3 and up, 4 and up.
  • WP version: 4.8, 4.7, 4.6, ... (probably only show the 4 most recent versions though the filtering through url hacking should support any version)
  • Active installs. We should probably adjust our bins from what the plugins use. Maybe 100,000+, 10,000-99,999, 1,000-9,999, 100-999, 1-99
  • Percentage of support threads resolved: 75%+, 50-75%, 25-75%, 0-25%
  • Category: there was past discussion about things like free, paid, etc which it sounds like is desirable, but not yet defined. If we define it we could add them here.
  • Percentage of plugin strings translated into the current locale - This data is not in the index, but it does exist: https://translate.wordpress.org/locale/es/default/wp-plugins?s=jetpack

That all kinda feels like a lot to me and I wonder if we should cut some to simplify for a first release and see how it goes (eg do we need WP version? Doesn't feel like it would mean much to an end user). Other fields I've thought about:

  • Authors - would be a lot of noise. We should support filtering on it though and fix the author search
  • Tags look really noisy from what I have seen so far.
  • Total number of updates a plugin has had - kinda interesting to exclude plugins that rarely get updated
  • How many months has the plugin been getting updated for - maybe a better version of the above because less easy to abuse, but I'm not sure if it is useful enough

Other ideas?

A note on deep paging. Elasticsearch imposes a paging limit of 10,000 results. I don't really think there is a good use case for going that far, but 10k seems to work ok and not break so I don't care. We will start to hit this though if we are matching on everything. I think that is fine given that we are now giving the user a bunch of other ways to sort and filter through results.

For mobile, do we just hide the faceting sidebar? At most allow a sorting option? Or maybe the sidebar floats to the bottom of the page?

Some thoughts on timing. This is both a significant and also not that hard project. It is significant in that we need to change the design to add a sidebar, a sorting option, and add a bunch of url param handling. It is not hard in that there is a bunch of code for doing faceting and filtering that is destined for Jetpack in the next month or so that we can build off of. If we make some decisions around design over the next month then I can push ahead with the implementation in a pretty straightforward manner (once we update Jetpack).

This ticket was mentioned in Slack in #meta by gibrown. View the logs.


15 months ago

#3 @gibrown
15 months ago

  • Keywords ui-feedback needs-screenshots added

This ticket was mentioned in Slack in #meta by ipstenu. View the logs.


14 months ago

@joyously
14 months ago

How about if the sort is very simple, at the top.

@joyously
14 months ago

And a sort control on a small screen

@joyously
14 months ago

The filters could be hidden until the Refine Search button is clicked, at which point they appear in an overlay (could slide out from the side or whatever).

@joyously
14 months ago

The filter overlay on small screen.

#5 @joyously
14 months ago

@gibrown, I put the filters that made sense to me into a mockup image (see attachments).
I am of two minds on how the filters should behave. One is that each choice is a link (parameterized search) so the page reloads on each. The other is that it is a form that you set all the parameters and then submit once.
When I have used these types of filters, my preference is one submit, but people with fast connections probably prefer each click to change the page.

#6 follow-up: @joyously
14 months ago

One thing that is unclear is whether it is different code that populates the plugin search results in the admin versus the page that looks the same on wordpress.org.
Does this ticket cover both contexts?

#7 @gibrown
14 months ago

Thanks for adding some mockups. Helps to think through some of the complexities.

For sorting:

  • I'm going back and forth a bit on the word "popularity" and wondering if we should just say "relevance" which is at least open to interpretation
  • I'm not sure what sorting by plugin name would be? Alphabetical? What use cases does that solve for us? Also, we won't always be able to page through all of the results, so I think it would be a broken experience

Looking at the original design some more, I don't really like that the search box is in the upper right of the current design. Makes it hard to find and therefore hard to adjust. Feels to me that it should be in the center of the page, and much bigger than the text that says: "Showing results for:"

We also need someplace to display any filters that have already been added to the search. Maybe just below a more prominent search box with a set of filters using something like https://select2.github.io/examples.html#tags (though maybe something better than that).

For faceting, I think we should have the facets on screen at all times on large screens. That may mean reworking how the current results are displayed, but should make the search more browsable and interactive. I guess on small screens the faceting will have to slide in, or not exist at all.

I'd also love to just skip straight to doing a React UI for the search interface to make interacting much faster, but that would make the project a fair bit bigger I think (or at least it would make it harder for me to implement). I was looking at these for instance: https://react.rocks/tag/Faceted_Search

#8 in reply to: ↑ 6 @gibrown
14 months ago

Replying to joyously:

One thing that is unclear is whether it is different code that populates the plugin search results in the admin versus the page that looks the same on wordpress.org.
Does this ticket cover both contexts?

It is different code. The core plugin search is separate, but it uses the same backend algorithm. I think we should focus on iterating on the design here before looking to improve the UI in core.

This ticket was mentioned in Slack in #meta by gibrown. View the logs.


14 months ago

#10 @gibrown
14 months ago

We had some discussion about this in the plugin dir meeting yesterday. Want to capture two potential options for how to do implementation:

1.

Use the new Jetpack search sidebar widget to provide faceted search and filtering on the search page: https://github.com/Automattic/jetpack/blob/master/modules/search/class.jetpack-search-widget-filters.php

We'd also want to implement the appropriate sorting of results and redesign the layout of the page so it works on mobile.

This is probably the easiest path since it uses a lot of already existing code. An example of filtering and results is here: https://vip.wordpress.com/?s=search&category=case-studies&year=2013&monthnum&day

2.

A React/JS app that let's users interactively refine their searches. I had build something like this in backbone a while ago (https://greg.blog/2012/08/20/quickly-build-faceted-search-with-elasticsearch-and-backbone-js/), but that wouldn't work very well here. Ideally this would be a flexible UI that could be used in other situations also.

This would let us build a much more modern search interface: search as you type, fast responses to changes, etc. But it would also be a fair bit more work since it is all new development. Almost certainly needs some additional help.

We would also need to iterate on the rest api a fair bit. The other benefit to building a great React/JS app here is that it could be reused in wp-admin where most users do their searching for new plugins. This would be a big benefit.

Last edited 14 months ago by gibrown (previous) (diff)

This ticket was mentioned in Slack in #design by joyously. View the logs.


12 months ago

#12 @joyously
11 months ago

@gibrown How about like this site's search and filters? https://www.carvana.com/search

This ticket was mentioned in Slack in #core-php by joyously. View the logs.


9 months ago

This ticket was mentioned in Slack in #meta by sergey. View the logs.


9 months ago

This ticket was mentioned in Slack in #core by joyously. View the logs.


8 months ago

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


6 months ago

This ticket was mentioned in Slack in #design by joyously. View the logs.


6 months ago

This ticket was mentioned in Slack in #design by joyously. View the logs.


6 months ago

This ticket was mentioned in Slack in #design by joyously. View the logs.


4 months ago

#20 @boemedia
4 months ago

We discussed this ticket yesterday in the Design meeting. We think the plugin directory could hugely benefit from a sort & filter feature. I have taken a look at the mock ups in this ticket and here are my findings:

  • the way the filter and sort buttons are designed, aren't coherent. They have a different look and feel and are too distributed on the page
  • the term refined search could be changed into 'filter', since this is a common and well known term for this.
  • the filter options are now presented in a pop up. This is not ideal and I don't think this gives a good user experience. We have to ask the accessibility team for their view on this too

As for the filter options themselves:
Not sure if a filter on 'support threads resolved' would be something users look for. What filters could be interesting?

  • topic (like security, seo, user management, etc.). Someone is looking for a plugin with a specific purpose
  • last updated - we don't like plugins that aren't updated over 3 years (maybe combined with tested with versie x.x)
  • rating (although not sure if this should be a filter option; may work as well as a sort option, just like no. of installs)

This list could be extended, although we should consider that the more filter options people have, it's not always getting clearer at the same time.

For inspiration, we could look at what's done at the themes directory: https://wordpress.org/themes/tags/accessibility-ready+photography/

I also think the booking.com filters are something we could look at, since they've done a lot of UX research: https://www.booking.com/searchresults.en-gb.html?label=gen173nr-1FCAEoggJCAlhYSDNYBGipAYgBAZgBHLgBB8gBD9gBAegBAfgBC5ICAXmoAgM;sid=cc87f6e69f36f712aa9721a1c62012e1;city=-2602512&;ilp=1;d_dcp=1

What I like about the booking.com filter over the themes filter is, that it's there all the time. You can filter and sort from the same screen. However, the page is not mobile friendly, which is something I really like on the themes page.

Last edited 4 months ago by boemedia (previous) (diff)

#21 @boemedia
4 months ago

  • Keywords has-ui-feedback added; ui-feedback removed

This ticket was mentioned in Slack in #accessibility by boemedia. View the logs.


4 months ago

#23 @boemedia
4 months ago

  • Keywords needs-design added

This ticket was mentioned in Slack in #design by boemedia. View the logs.


4 months ago

#25 @gibrown
4 months ago

@boemedia thanks for the review. Very helpful.

My current plan on this is to add the Jetpack Search sidebar widget to use for filtering and sorting. Here's a screenshot:

https://cloudup.com/i3ue6hjqwcf

And you can play with the interaction a bit on this test site: http://gibrown.wpsandbox.me/main/?s=post

We'll need to play with the CSS a bit of course. I think this comes pretty close to matching what your example of booking.com is doing though, so sounds like we are on a similar page.

This does mean that we are going to need a search page that has a sidebar designed and built.

#26 @afercia
4 months ago

A few accessibility considerations, not pretending to be an exhaustive list of potential issues to address:

Sidebar:
If it's going to be a fixed sidebar, I see no a11y concerns. Instead, if it's going to be a "sliding" sidebar, it's highly preferable it is placed in the source right after the toggle button that opens it. This way, it would be in the natural tab order. Otherwise, focus needs to be managed.

"Sort by" select:
It should have a button to submit, see https://core.trac.wordpress.org/ticket/40925

Interaction:

One is that each choice is a link (parameterized search) so the page reloads on each. The other is that it is a form that you set all the parameters and then submit once.

Checkboxes and a submit button are highly preferable. Triggering a search when checking a checkbox produces an unexpected change of context though. Depending on the implementation, there's also the risk the search fails to return the intended results and the risk to hammer the server with multiple requests. For example, quickly checking and unchecking multiple checkboxes can easily fail.
To reproduce on the http://gibrown.wpsandbox.me/main/?s=post example, just quickly check and uncheck dowork with a double click. Although you've left the checkbox unchecked, the search triggers after the first action and you get results for dowork tag=dowork.
Ideally, a submit button should always be used, as that's the only reliable way to confirm the users intention to submit.

Checkboxes:
Consider to group them in a fieldset with a legend and in this case the headings can be removed.
Note: for inspiration, see the themes filtering in core, which has been changed to use fieldsets/legends (no headings) together with some more a11y improvements (e.g. buttons are now buttons and not links <a class="drawer-toggle" href="#">, the submit button is now also at the end of the form, etc. see https://core.trac.wordpress.org/changeset/38640). Instead, the themes directory hasn't been updated with this changes.
If keeping the headings, the heading hierarchy in the page should be correct. Currently, on http://gibrown.wpsandbox.me/main/?s=post I see the headings are h4 and they skip a few levels.

Labeling:

Search as you type:
Note: I'm not taking into considerations the mentioned "search as you type" UI, as it seems it's not going to be implemented for now. However, please consider this kind of UI needs a considerable amount of work to get a minimum level of accessibility and I'm not sure they can be made "fully" accessible. For the similar searches in core, some concerns have been expressed about their real usability, see for example https://core.trac.wordpress.org/ticket/31818 and https://core.trac.wordpress.org/ticket/38211
Also worth considering the following WCAG Success Criterion about keystrokes timings: https://www.w3.org/TR/WCAG21/#keyboard

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes ...

#27 @rianrietveld
4 months ago

For inspiration:
An example of an (almost) accessible filter with options is on the search results page of the Newsroom of Encompass Health:
https://newsroom.encompasshealth.com/?filter%5Basset_type%5D=&s=encompass
The filters button toggles the visibility of the search options.

Last edited 4 months ago by rianrietveld (previous) (diff)

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


3 months ago

#29 @chriscct7
3 months ago

As a tiny bit of feedback, size of zip probably is not a useful metric to almost any average user

This ticket was mentioned in Slack in #meta by joyously. View the logs.


5 weeks ago

Note: See TracTickets for help on using tickets.