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 Fixed 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 Fixed :

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 Fixed 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 Fixed :

• 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 Fixed 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.

I have tested this change and it works well for me, and the filter drop-downs are in the right order.

I have encountered a couple of issues:

1. I can't seem to open the categories drop-down with the keyboard. The other filters can be opened by pressing "space", but that doesn't work for categories. I feel we need an intuative way of making it keyboard accessible.
2. You can click the checkbox on a category, or the category name to select/deselect. However, clicking the category text seems to have a very tight "target" area, and clicking just outside the text makes the drop-down disappear without selecting. As there is a bit of a gap between items, I think it would be easy for users to miss the target, and could be confused about why the category wasn't selected. I think this could be fixed by adding a small amount of padding around the category text.

Also when category drop-down is opened with the mouse, I can navigate the checkboxes with tab/shift+tab, but not with up/down arrows.

I think most users would expect to navigate drop-downs with up/down, and for tab to close the drop-down and move focus to the next form field.

I have taken the first step of adding a keyDown handler that opens/closes the dropdown when pressing "space" or "alt+down" or "alt+up", which matches the behaviour of the other dropdowns.

However, when it expands, the focus is still on the parent control. I think it should move to a child control (the first checkbox?) to start navigation within the drop-down.

Also need a keyboard handler for navigating between checkboxes withing the drop-down.

It might also be worth asking is there a prebuilt checkbox control we could use that has keyboard handling built in?

when i update and checkout the latest state of MR513 and do a drush cr i get an error:

TypeError: Drupal\project_browser\EnabledSourceHandler::__construct(): Argument #4 ($uuid) must be of type Drupal\Component\Uuid\UuidInterface, Drupal\Core\KeyValueStore\KeyValueExpirableFactory given, called in /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in /var/www/html/repos/project_browser/src/EnabledSourceHandler.php on line 34 #0 /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\project_browser\EnabledSourceHandler->__construct()
#1 /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService()
#2 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(278): Drupal\Component\DependencyInjection\Container->get()
#3 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(242): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer()
#4 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument()
#5 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(212): array_map()
#6 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(182): Drush\Runtime\LegacyServiceInstantiator->resolveArguments()
#7 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(163): Drush\Runtime\LegacyServiceInstantiator->instantiateObject()
#8 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create()
#9 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices()
#10 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles()
#11 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands()
#12 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#13 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(397): Drush\Boot\BootstrapManager->doBootstrap()
#14 /var/www/html/vendor/drush/drush/src/Application.php(214): Drush\Boot\BootstrapManager->bootstrapMax()
#15 /var/www/html/vendor/drush/drush/src/Application.php(180): Drush\Application->bootstrapAndFind()
#16 /var/www/html/vendor/symfony/console/Application.php(258): Drush\Application->find()
#17 /var/www/html/vendor/symfony/console/Application.php(167): Symfony\Component\Console\Application->doRun()
#18 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#19 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#20 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#21 /var/www/html/vendor/drush/drush/drush(4): require('...')
#22 /var/www/html/vendor/bin/drush(119): include('...')
#23 {main}
TypeError: Drupal\project_browser\EnabledSourceHandler::__construct(): Argument #4 ($uuid) must be of type Drupal\Component\Uuid\UuidInterface, Drupal\Core\KeyValueStore\KeyValueExpirableFactory given, called in /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\project_browser\EnabledSourceHandler->__construct() (line 34 of /var/www/html/repos/project_browser/src/EnabledSourceHandler.php).
 [warning] Drush command terminated abnormally.

@rkoller Are you able to run the current 2.0.x branch? I found I needed to update a few things with Composer and do a drush updb to get things working.

i am not using a composer based workflow but a git only workflow instead. but i forgot to run a git pull for the drupal core folder alongside. maybe THAT was the reason. not sure. but after running git pull on that i was able to run drush cr again as well as the error accessing the site is gone. thanks for the reminder. i really need to run core updates before i pull updates for a contrib project (i still need to get used to that new workflow - i had a composer patches based approach before) . will take a look at the changes itself tonight. also still have to write up a few outcomes from the ux meeting the week before last friday where we discussed this issue another time.

I have been tinkering with keyboard control. I have got it so that pressing "space" or "alt+down" or "alt+up" opens the drop-down, and moves the focus to the first checkbox.

Up/down arrows will then move between checkboxes in the list.

However, I'm having trouble toggling the checkbox with the keyboard.

As per comment #32, the order of the drop-downs has been changed into a more logical order.

However, the active filters are shown below it the reverse of that order. E.g. "Active - Maintained - Covered by security policy - Content Display - E-Commerce.

For me it makes no sense to show the filters in the reverse order of the drop-downs.

We should either:

1. Always display in the same order as the dropdowns, so "Categories, Security Policy, Maintenance, Development
2. Add the filters in the order they are selected, so the most recently added filter will always be on the right. If a filter is removed and readded, it would move to the end of the list.

I don't have a strong preference between these, but we should choose one and implement consistently.

Actually @lostcarpark, I think the answer is to get rid of the chips for anything except for categories. The state of the filter is shown in the dropdown, so I don't think they're needed.

OK, looking at this and trying to give a summary of what needs to happen in this issue to move it along.

1. Remove the non-category chips altogether. Only categories should show as chips.
2. Improve the click target so that the entire thing is clickable, and that clicking the box OR the label behaves as the label currently does.

There are some other follow-ups I will file that I think are related to this, but can happen later, in an attempt to keep this issue as tightly scoped as is possible.

1. Add an "apply" and "clear" button to the bottom of the category selector (we can discuss if this is necessary)
2. Add "onBlur" type of effect so that when we click off the category dropdown it hides
3. Improve keyboard accessibility for the dropdown
4. Change the OTHER dropdown selectors to something more intuitive, like toggle buttons instead of selects/dropdowns (does Claro have a toggle UI pattern?)
5. Eliminate "bounciness" when category is selected (happens if you're scrolled down and it scrolls back up when the cards disappear as the result of a new search; might make more sense to dim/disable, or keep the containing div at the height it is while new ones load)

@rkoller, I think it was you that had an issue with the page jumping when you press space to open categories in Chrome/Safari. I had only tested in Firefox. I've fixed that issue and tested in Chrome (I don't have Safari).

Still working on making it actually select categories.

@chrisfromredfin, agree with removing the chips for the other filters.

I'd suggest we go further. When closed the category drop-down always says "Select categories". When there's nothing selected, that make sense. However, when categories are selected, I think it should show the categories in the closed drop-down box.

Then, do we need the chips at all?

I've increased the label target area.

One thing I noticed is that the first input gets automatic focus and stays that way unless you click outside the dropdown.

Probably an issue that needs to be addressed separately and in conjunction with "onBlur" event handling in Svelte.

re @lostcarpark i can confirm that the dropdown isnt collapsed anymore when a checkbox is ticked by pressing the space key. excellent! and also thanks for adding the close on esc functionality!

re #46 📌 Improve the categories filter type in context to the rest of the filter component ui Fixed the problem you've raised has another dimension. if you tab through the multiselect list by the keyboard and tick one or two checkboxes down the way the focus outline follows along properly. but as soon as you tick another checkbox by the mouse the focus jumps back to the first checkbox.
probably we should discuss how the focus outline behaves in particular if the interaction is mixed with keyboard and mouse. maybe we should follow the behavior used for example on the permissions page. but yeah in general i agree move that discussion to the on blur followup issue.

another detail i've noticed, if you are opening the multi select with the space key the drop down is just expanded. if you try the same with voiceover activated in macos and use VO-space then the multiselect not only expands but the first element is auto-checked. that shouldnt happen. the multi select dropdown should just be expanded with space as well as with VO-space.

huh somehow the version got changed by accident, that wasnt itended.

@lostcarpark - for the scope of this issue, I'd like the chips just for categories, and in a follow-up I think we could change to "4 selected" or something like that. I still think seeing the chips for categories is useful because then you don't need to open up the select and scroll in order to see which four they are, though.

Feedback in #47 can/should be moved to 📌 Improve keyboard navigation for categories dropdown Active .

I have fixed some issues for both mouse and keyboard navigation.

Selecting/deselecting a category with either keyboard or mouse will now keep the drop-down open, and keep the focus on the same checkbox.

Clicking outside the drop-down, or tabbing off the last checkbox item will close the drop-down.

I've started making the selected categories display in the closed category box, as would be the case for a standard drop-down. At present I only have it displaying the ID, when obviously we want the category titles displayed. From Chris's comment #49, we could make it just show the count of selected categories.

I've now removed the chips for non-category filters as suggested in #49.

I also have it showing the selected categories (when there are categories selected), replacing the "Select categories" in the categories box.

At present the category box gets taller as you select more categories. I thought this would look unsightly, but I think it looks surprisingly okay.

We possibly should put a limit on how tall it can get. I can think of several approaches we could take:

1. Just let it grow to show all categories, since most people will only pick a couple.
2. Put all the categories in the box, but limit the height with max-height
3. limit the number of categories shown, and have a "+X" at the end to indicate the number of unshown ones
4. Show the category name when one category is selected, and "X categories selected" if more than one
5. Only show "X categories selected", never the names.

Added Tab and Shift+Tab keyboard behaviour.

Now when pressing Tab withing the open drop-down list, it will navigate to the next filter (Security Coverage). Pressing Shift+Tab will navigate to the previous one (the search bar).

Currently the previous and next destinations are hard coded. It would be nice to make that more generic, in case the available filters vary between browser tabs, but I'm not sure how to make that work.

I feel this helps to make the drop-down list feel like a single control, rather than a collection of separate checkboxes, and makes it behave in a consistent way with other drop-down lists.

I've quickly tested the latest state. A few observations:

1. When i tab into the category select field and press space the browser scrolls again while expanding the category list. Happens in Safari and Edge.

2. Displaying all the categories within the select field is sort of redundant with the list of category chips. Plus the entire list of selected categories is sort of hard to read as well as to process cognitively

As soon as you select more categories than that could fit within a single line the height of the select field expands to a multi unit height select field. problem is that the position of the modal remains one of a single unit height select field.

3. In regards of keyboard navigation, I have to check and test a few other cases, but it feels sort of unexpected and odd if you press the tab key that the modal collapses and the focus moves to the next select field. if you try the same for example on one of the three others, pressing tab does nothing, the select field remains expanded and you are only able to navigate the options with the cursor keys and close the list by clicking outside or press esc. therefore the differing behavior for the multiselect with tab feels odd and "might" be potentially confusing in case muscle memory kicks in.

Just noting that all tests are now passing.

Working on adding test for keyboard navigation.

Still need to rebase for latest changes to 2.0.x branch.

many folks doing great work on this now...

I've added a very simple Nightwatch test to test keyboard control of the category drop-down. I need to figure out how to make it actually run in the CI, and it will need additional keyboard test cases added.

I have added a Nightwatch test called "keyboardTest" that navigates to the category drop-down, expands it, moves down the category list, selects a category, closes the list, opens it again, moves back to the selected category, deselects it, tabs off the drop-down and verifies the next control is active.

I'm not sure that's everything it should test, but it's a start, so would appreciate if anyone could review and let me know what else is needed.

All code quality checks and tests are passing.

The Nightwatch test MIGHT be overly complicated, but it is thorough in its testing. I wish there were a way to do some of the setup for the test ahead of time / not in Nightwatch, but I don't think that's an option. :)

AND amazingly, more than anything, this opens up the world of Nightwatch to us which is a huge victory! James, can't thank you enough - as well as everyone else who had their hand in here - what great stuff!

Automatically closed - issue fixed for 2 weeks with no activity.

Some icons are not a uniform size, such as Content Editing Experience and Search Engine Optimization (SEO)

#nedcamp2024