Improve the categories filter type in context to the rest of the filter component ui

I believe the second screenshot above is a far superior user experience. I might add to it that we need to color the categories gray (as long as it's accessible) like the filters above. That might help convey that "the things with the gray background are filters."

I would also like the results count to also appear below, not just on the tab.

For mobile, it would be great to be able to fake-move the Categories up into the box (really, I think we'd have to shore it up and draw the background on both to make it visually one box, but two separate divs, in order to prevent order-switching for a11y reasons).

(I'm OK with "sort by" moving up into filters box.)

I've already commented over in the recent corresponding thread on the drupal slack.

I am not sure if the mockups in #4 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work are actually solving the problem. To associate the categories sidebar with the horizontal filter bar just by color is probably not enough (and also not in line with WCAG 2.2 SC1.4.1).

One of the key points and my main take aways from a recent webinar by the smashing magazine on search ux was “filters should be above search results”. Reason is when filters appear in the sidebar they cause layout shifts so users have to refocus every time they set a filter, and with the project browser ui there is a a refresh of the search results on every tick and untick. the recommendation was, which i agree to, to show applied filters and other relevant filters above/before the results. One approach, which would change the entire filter section might be the following:
Instead of a button (currently called filter and in the mockup in #4 called advanced) and instead of those chips add only four select fields, (categories, development status, maintenance status and security advisory) each containing a list of checkboxes or radio buttons. one site that is applying that pattern for example is: https://www.nejm.org/search?q=health&isFilterOpen=true (in case of project browser the filter wouldnt have to be hidden like on nejm.org)

the advantage would be you would get a clear separation of concerns for the whole project browser page. first you have the search box where the person enters the search term, second the filter bar with four select fields where it is possible to narrow the scope, then you get your number of results and your sorting options as well as the display style (grid/list) and finally your list of results - no more category sidebar mixed with the search results. clear and and way more easy to comprehend that way. plus all elements you are able to filter by are in the same proximity. in addition you could also drop the expandable drawer where the settings are listed as three radio button sets, also no clear separation of concerns plus on wide screen monitors you have huge gaps between each radio button set.

in regards of the select fields illustrated with the nejm.org example you might even consider adding an apply button to each of the select fields. that way you wouldnt fire a new query and an update of the search results on every tick or untick of for an category. from a sustainability perspective you would save cpu time as well as bandwidth and at th same time you go easy on the cognitive bandwidth of your user and you only provide an update to the list when all the decisions where taken on a select field.

the longer i think about it the more i like that approach. a cleaner untwined interface which is way easier to comprehend imho.

Implementing categories as a multi-select dropdown and moving it up above is brilliant. Leslie and I both like it. We think it should be the first of the four columns, and the columns should not be space-between like they are now, they should all align left with adequate padding to keep them away from each other logically.

I would love it if someone wanted to work on this one from the front-end / Svelte side.

I really like the multi-select drop-down too. It strikes me as a much cleaner interface. I also like the way in the example above example, the number of entries in each category is shown. This would be especially useful if it showed totals within the context of the current filters, so if you have "covered by security policy" enabled, it will show the total number of modules covered by the security policy in each category.

I have begin work on moving these around. It's far from perfect, but it's a start. There's a draft MR (!476) in place.

@chrisfromredfin started work on this at DrupalCon Portland 2024 and will be continuing on that

chrisfromredfin → changed the visibility of the branch 3318817-improve-category-filter to hidden.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-05-24 Needs work . The direct link to the recording of the meeting is https://youtu.be/eRTK--QbRmQ

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, and @SKAUGHT.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

At first apologies for the delayed comment, but the first week something else came up and the second week I've heavily struggled getting all the points raised during the meeting into a coherent and hopefully comprehensible order without leaving out too much detail. It has to be noted that the basis for our discussion was a brief presentation of the status quo in version 1.0.x-dev of project browser followed by the current proposed solution illustrated in the form of https://www.nejm.org/search?q=health&isFilterOpen=true and the EUR-Lex example by the Smashing Magazine:

The first impression an attendee had looking at the status quo of the search page of project browser at the beginning of the meeting, was that it is sort of busy and cluttered. It made him even feel sort of anxious due to the sheer amount of information one has to digest all at once, which is sort of overwhelming. So at the end of the meeting our conclusion and general consensus was that the proposed resolution is definitely a step into the right direction even though we haven't agreed on any clear recommendations.

Therefore in the following a list of all the points raised during our discussion within the scope of this issue and after that a few additional noteworthy points:

A) General layout
There was a clear consensus that the filter categories, currently placed in the sidebar, take up way too much room and something should be done to hide most or all of them by default. With the new navigation module installed and with the filter categories sidebar in place there is even less space left for the results horizontally compared to the horizontal admin_toolbar (screenshot is on a 16"):

• One part of the group liked the idea of moving and including the categories with the other filter options above the search results. It was also well received that with the multi-select field the list of categories currently shown on desktop viewports is hidden by default. It also removes the details element on mobile view port making the interface consistent in between desktop and mobile.

  (*Post meeting addendum: With the filter categories sidebar removed, you gain more room for the results, plus there is a clear separation of concerns, first the search then the filter section, and then the results section, stacked onto each other)

• As an alternative, based on the user research assessed at the University of Edinburgh in the context of search ux, it was suggested instead of moving all the filter components into a horizontal element on top of the search results, to move all the filter components into a sidebar on the right next to the search results.

  That is just a brief mockup done in devtools moving just the filter categories over. But the suggestion was to have a box/section for each filter option. For the reading direction of LTR, having the sidebar on the right, the filter would not interfere with the processing of the search results. It was also noted that research showed that their students wanted to see all results, since they mistrust filtering.

B) How active filter settings are communicated
The mockup for EUR-LEX (presented by the Smashing Magazine in the webinar on search ux) was very well received by all the attendees - overall it felt less visually cluttered. With that approach the chips for the active filter settings would be dropped. But the concern was raised by one attendee that people like chips, enabling them to easily assess the current state of the set active filters or remove one chip by clicking its close button.

• In case the chips are dropped it would be possible to communicate the default selection aka the active filter setting within each multi select field. That would work very well for the development status, maintenance status, and the security advisory coverage which is basically a boolean, either show all or the actual setting. Category filters have two problems, an "all" option is missing, at the moment that setting is implicit when no category checkbox is checked, so it would be desirable to add and "all" option. Then you have the problem that you can have up to eighteen categories selected, but already with two or three categories selected you wont have enough space available within the multi select field. nejm simply concatenates (https://www.nejm.org/search?q=health&isFilterOpen=true&startPage=1&isFil...) which is not helpful nor desirable. The suggestion was raised instead of concatenating simply display something like "3 categories selected". That way it would be communicated either all categories are selected or a subset, and if so how many. The downside it would still require one click to see the actual list of selected categories. A relevant aspect for people with a small working memory.
• To tackle the fact that people like chips as a way to easily assess and alter the set of active filter settings it was suggested to consider to combine having a set of four multiselect fields and chips for active filters. But these chips would have the same problem as the current state of the project browser interface. Having category chips in the same row as the chips for other filters is confusing. Development status, maintenance status, and the security advisory coverage are actual toggles/booleans standing for a single filter setting, while filter categories can have several chips. Then there is the fact that there is an effort to make those category chips clickable (see point 2 later within this comment). Instead of trying to make those different types of filters more visually distinct there was the thought why not wrap the chips for categories in one details element and the other three in another details element, to group them separately.

C) Multi-select fields vs checkboxes
There was also the question if each of the four filter types should be a multi select field or if development status, maintenance status, and the security advisory coverage should be checkboxes instead, since they are boolean values switching between for example maintained and not maintained, and grouped together somehow. So you have a multiselect field and a group of three checkboxes.

D) User testing
It was suggested to consider user testing whether to combine the three existing filters into one set of checkboxes and also for the question if the four filter types should be on top of the results or if they should go into a sidebar on the right.

During our explorations there were a few still noteworthy details out of the scope for this issue:

1. https://www.drupal.org/project/search_web_components → was brought up. Maybe project browser can get some inspirations from this module or even use some of its components? The attendee who brought up the module didn't know how feasible this suggestion actually is, but it might be at least worth looking at it or maybe get its maintainer interested in the effort of project browser?
2. One attendee wondered why it isn't possible to click a category chip on a module card on /admin/modules/browse, same as it is possible on a details page. His expectation was by clicking a chip on the browse page the clicked chips category would extend the list of already ticked filter categories. Another attendee had the exact opposite expectation, he thought the list of ticked filter categories would be narrowed down to the one clicked, same as the behavior on the details page. There is already an issue 🐛 Module categories on Browse tab aren't clickable, don't perform a search RTBC making the chips clickable. Behavior wise it follows the second pattern, and mimics the chips behavior on the details page. But the question remains how to make the link behavior of those chips clear on the /admin/modules/browse page?
3. On the other hand the question was raised if the chips are really needed there? What is the actual value of these chips being added there? The card layout feels visually cluttered, like there is a lot of visual information. But if a user has already filtered by categories, they already know the selected categories, if they have not filtered by category they are probably searching by a specific term. And the actual categories would be available on the details page for a module anyway. But in the context of the content of a module card on the search results page the attended was unable to imagine a situation where displaying those categories adds a huge amount of value. (*Post meeting addendum: to get an idea if these chips are of any value it was suggested to run some user interviews. During the meeting I haven't remembered but there was a questionnaire covering that question a few months ago: https://docs.google.com/spreadsheets/d/17JiSqr5VH0fupdGLo6pLatM2Vfx0y3vw... . In the sheet Question 1&2Stats the category component is ranked into the third important group out of four for the second question when people are just "browsing" with no clear goal in mind. It has to be noted that the questions referred to the module page aka the details page. So there was no specific question in the context of are categories considered a useful component on cards).
   On a related note in the context of the visual clutter, another attendee noted that cards should be as easy scan-able and consistent layout wise as possible (according to Vitali Friedman from Smashing Magazine). But at the moment you have one or two line titles making the short description start at different heights across the different cards and then you have one or two lines of chips depending on the number of modules a module maintainer has set.
4. In grid view cards are already hard to scan. At the moment the list view is using cards as well. For the list view the content of a card is just rearranged: a single column, less height, way larger line length where only the horizontal viewport is the limit, which is way past the goal of ~80 characters. Technically the list and grid view are both card based views. The group came up with the idea to instead align with the interface pattern media applies. To use an actual table for the list view (like on /admin/content/media) and keep using the cards for the grid view. By using a table you would be able to display way way more results onto a single page and those results would be way more easy to scan. @chrisfromredfin already opened a follow up issue: ✨ List view should actually be a table Active .

A few additional thoughts observations I came up during the write up for #15 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work :

In regards of right sidebar in point A. I wonder if the university of Edinburgh tested for pages that have a horizontal main menu on top. Meaning in the context of the Drupal admin ui with the horizontal admin toolbar in place having the filter sidebar on the right is definitely a viable option. But with a vertical navigation like with the the navigation module installed you have one sidebar on the left and one side bar on the right, the results are crammed in-between leaving again the problem of not enough room for the results. Plus having the setting on the right brings up the problem of continuous reflow every time the filter settings are changed which makes the results section busy and a constant source of distraction every time the filter settings are being altered.

By aligning the interface pattern for the list and grid view in project browser as mentioned in #15.4 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work to the media module there are two details to note:

• The elements, order, and/or labels for the filter section in media for the table and grid view vary significantly. For table you have media name, type, publish status and language. For grid you have published, name , media type, language, and sort by. For grid it might be considered as well to move the sort by option out of the filter section because it is not actually a filter. In regards of the micro copy, media uses - Any -, while project browser uses Show all. Also the filter button label differs, table has just filter while grid has apply filters - the filter button wouldn't be necessary for project browser. But over all i think it would be reasonable to make the filter options within those two tabs more consistent for media as well as align media and project browser in particular with any/show all. What do others think, is it a reasonable thought and should i open a follow up issue over in media?
• In regards of consistency i wonder if it would also make sense to drop the secondary tabs for table and grid in media and replace it with the toggle switch solution used in project browser. That way the interface pattern would be consistent inbetween the two? same question, what do others think?

And finally my current personal preference about the proposed resolution. I am in favor of having four filter types and each being a multi select field. The category filter type should get a show all option. I also like the x number of selected categories label for the multi select field in case more than one category is selected instead of to concatenate the list of selected categories. I also see the need to communicate the active filters, in particular for categories in some additional and/or different way alongside the multi select label, but chips still feel suboptimal as outlined in the second point in B.

I've pushed some tweaks and updates to responsive style. Filters should look much better for mobile/tabletish breakpoints now. Also made some stylistic changes, but things still needs additional UI tweaks.

Couple of things I was wandering about while looking at this:

- There is some breakpoint based logic with the Categories Filter in Svelte. It is being hidden on mobile. Assuming we need to take that logic out.

- Wondering if the "Filter by Category" and "Keyword Search" should be swapped. Making the "Keyword Search" fist form item. Just a thought.

thanks for pushing it forward! about your questions. the category filter breakpoint made the filter category sidebar collapsed by default on mobile. i agree, that can be removed. and about the second question in regards of the filter category and keyword search field order. yep that should be switched.

about your screenshots. i still think the search field and the filter multi select fields should be visually distinguishable. i'll just add my thoughts in regards of the different screenshots:

first screenshot: there you have the search field and the four filters with the same padding in one row (the order of search and categories put aside) all wrapped in a fieldset which also contains the reset link and the sort by option select field. in regards of the "all in a single line" approach i consider the eur-lex example clearer. there you have the search field in a different color and font size while the selected options for the filters have a larger font size and weight as well as a different color. plus the multiselects have no borders. and the search glass is left aligned, prepended instead of appended. (i am not entirely sold on the single line approach). and i dont know how the smashing mag would envision the single line approach for mobil cuz visually it is one single large field with three multiselects included. but i doubt it would work if the multiselects get wrapped.

second screenshot.same issue like with the single line approach, search is visually similar or close to identical to the four filter options. personally i am more drawn to an approach looking something like that:

desktop viewport (2 lines)

search
category, dev status, maintenance status, security advisory

and depending on the available horizontal viewport width the options for mobile viewports would be

mobile viewport (3 lines)
search
category, dev status,
maintenance status, security advisory

mobile viewport (5 lines)
search
category,
dev status,
maintenance status,
security advisory

and i wonder if the recommended filters link would be necessary at all? and at the same time i also still wonder if it would make sense to move the sort options out of the search and filter box. that the different steps (search, filter, sort /results) a separated visually more clearly?

@rkoller thank you for the feedback. Here are the latest changes, based on your feedback and the conversation we had in UX meeting today.

• Rearranged the search and filters
• Removed the Media Query that was hiding categories on mobile
• Updated Styles

I've created a branch 3318817-change-catfilter-for-2x to prepare the 2.0.x version of this branch in parallel. It's not clear if this will be committed to both 1.x and 2.x.

I started to fix the tests but the only phpunit tests that are breaking at the FunctionalJavascript issues that seem to be mostly about the UI changes, and I wasn't 100% if they are in flux. Otherwise the 2.0 MR is good and I'll keep it up to date with 1.0 changes if we're doing both.

from my understanding all work should happen in 2.x from now on and i doubt it would be committed to both branches, but suppose @chrisfromredfin is the better person to answer that. but in regards of the 2.x branch you've created, a huge thank you to you @sime! that one i am able to apply with composer patches, 1.x failed to apply constantly and i was unable to test locally.

nice, thanks for the update @zetagraph. I like the general direction, the interface is becoming more and more less cluttered. A few observations and thoughts, first about the recent changes in #20 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work :

• The filter by category multiselect field is currently not keyboard accessible, it is excluded from the tab order.
• It looks somehow odd to have the outline of a fieldset wrapping the search and filter element components while the underline of the secondary tabs is equal to the fieldset's top border. I wonder if it would make sense to remove the bottom, left, and right border of that fieldset? That way it would be more in line with other pages in core that have such secondary tabs.

and then about the open questions:

A) Category multiselect
The behavior of the multiselect in the current draft is odd. If you click exactly within a checkbox the checkbox gets selected and the multiselect collapses. If you click outside of a checkbox in close proximity the checkbox gets checked but the multiselect modal remains expanded. But in each case there is a reflow of the results section on every click - i am not sure if there is a new request each time when a filter setting is changed or only if the search query is altered. But i wonder either way if it would make sense to go with the suggestion in #7 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work adding an apply button to the multiselect. that way the categories could be selected and the reflow only happens when the apply button is pressed and the multiselect collapses (like for example on https://www.galaxus.ch/search?q=nintendo%20switch for the category multiselect)?

and then there is still the question if there should be an "all categories" option? I've thought again about the question if it would make sense to add a "show all" option to categories like you have for the development status, maintenance status and security advisory coverage filter components. For one all of the four current filter components should be consistent, either all should have a "show all" option or none should have one imho. But strictly speaking, the purpose of a filter is to filter for something aka narrowing down. so without a filter applied you show everything while as soon as you apply a filter either one or more of the categories or something like maintained you reduce the number of results.

Styling wise, there is no interface component for a multiselect in the drupal design system yet but i suppose the styling for the checkboxes should follow the design system. Another detail to note, at the moment if the list of categories is expanded the visible options are from "access control" to "integrations". If a user has hidden the scrollbars by default on for example macOS it might be unclear that this list is a scrollable one. It might be a good thing to make the height of the select list uneven; instead of going with a whole number of options, 11 visible categories at the moment, go with 10,5 or 11,5 instead maybe?

B) The development status, maintenance status and security advisory coverage filter components
It is more than a valid point that was raised again during the last UX meeting, that there should be at least three options for any select list in use. But i have to admit i really liked the EUR-Lex example where you have no label for the select fields and the current selection and context is provided just within the multiselect field. That way you see what the multiselect is about while nothing is selected or you see the actual selection, plus you get a consistent look of all the four filter components.
My worry was by having just a single multiselect field and then three checkboxes or toggle switches with an appended label might look less consistent and uneven. Plus the problem of communicating within a single label that unchecking shows all modules while checking shows modules with for example an active development status. That "might" be potentially challenging to communicate as well as to comprehend. One potential compromise might be the approach Semantic Scholar took (see the "has PDF" button on https://www.semanticscholar.org/search?q=geography&sort=relevance). Their filter options are a mix of multiselect fields and a toggle button. That way the filter line could look way more consistent and the multiselect and the toggle button would both add filters narrowing down the selection.

C) The active chips
The question is if the chips for active filters add value or noise. In the current form with a "few" filters added the chips take up quite a lot of space.

Plus there is the point that was raised during the UX meeting twice, that there is no way to distinguish which chips are about categories, which about the development status, which the maintenance status and which about the security coverage.

Have just played with it real quick and have the following small things I'd love to get cleaned up - but HOLY GOD this is so nice! Thanks!

1. I wish the page wouldn't "jump" when I clicked a filter... I think this is a result of the cards disappearing. If it's an easy fix, great. If not, we can file a follow-up.

2. I think we should get rid of the chips for non-categories, and only show chips for categories. The state of the select shows you what you've chosen there, and I think that's adequate. For categories, I would love it if it would show " selected" if it wasn't all of them, so it would show "3 selected" if you've picked some, ex.g.

3. I would love it if you didn't have to close the dropdown by using the dropdown, but something more traditional like just clicking off-focus as another option would make it a bit more usable (or even clicking escape?! 😬).

This mostly jives with rkoller's feedback, but hopefully is a bit more decisive. My mentality with merging is "is this an incremental improvement, a step forward?" If so, we can go with it then file follow-ups for things as-of-yet unanswered. If we can get at least 2 and 3 in, then it's a substantial incremental improvement, and we'll merge it.

Going to assume we're on 2.x

sime → changed the visibility of the branch 3318817-change-catfilter to hidden.

I've pushed a few updates to the `3318817-change-catfilter-for-2x` branch:

• Added focus state (accessibility)
• Updated markup and labels (accessibility)
• Improved and updated styles for the dropdown and checkboxes

This is the current state of things:

@sime can you help with number 3 in comment #27 for the off-focus/onBlur in Svelte. We just want to close the dropdown on click outside. Thank you.

> @sime can you help with number 3 in comment #27 for the off-focus/onBlur in Svelte. We just want to close the dropdown on click outside. Thank you.

I had a look and I got close, but I'm not experienced enough in Svelte to do this.

Let's change the order the filters appear in, also -

1. Categories
2. Security Advisory Coverage
3. Maintenance Status
4. Development Status

@chrisfromredfin order of filters should be updated.