Filter by category should be scrollable

Thank you for opening an issue for that problem. That one was already identified and raised within 📌 Improve the categories filter type in context to the rest of the filter component ui Fixed but slipped through when the issue was set to fixed and there was never been a follow up issue filed. In one of the usability meetings we've discussed the problem, see #3318817-15: Improve the categories filter type in context to the rest of the filter component ui → . Back then we concluded that the four available select field components should have the same height, at the moment the multiselect gets expanded in height indefinitely. the option that was used in other examples we saw was keep the height at one height unit and concatenate the list of selected categories. but concatenation is not desirable. the solution you've proposed by setting a max height would ease the problem but still the button would have a bigger height then the other three. Our suggestion and conclusion in #3318817-15: Improve the categories filter type in context to the rest of the filter component ui → was:

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.

(in that example 3 categories would have been selected)

And then you still have the chips underneath showing the list of selected categories as well (see #3318817-26: Improve the categories filter type in context to the rest of the filter component ui → and it was also covered in #15) which would be another reason why it wouldnt be necessary to have the list of selected categories displayed within the multiselect select field.

personally i am still not a fan of those chips. it makes the filter field set sort of overwhelming from a cognitive load perspective, but having a multiselect label "x categories selected" and the list of selected categories underneath is still a acceptable compromise which could be further improved at a later point if more actual users are testing and using project browser. so my vote in regards of the proposed resolution for this issue would be keeping the heigh of the multi select at the same height as the other select fields. and adjust the multiselect label based on the number of categories selected to "x categories selected" . In regards of the case if no category is selected that could be tackled in a follow up issue cuz the "select categories" label in case no category is selected is not clear. for one all other select fields tell the user what is current displayed and with "select categories" it is not explicitly communicated if the multi select is additive or subtractive. but as i said that is something out of the scope for this issue.

This is how it looks now.

Marking it needs review to get an initial feedback of the approach that's defined in #3.

Thank you for the initial work @utkarsh_33! In general this looks great, a lot of cognitive load got removed and the filter section got a little bit less overwhelming

the only detail i wonder about, it feels odd to always use the "x categorie(s) selected" pattern, no matter if you have selected one category, two or x number of categories. the initial idea that lead us to that pattern was to use "x categorie(s) selected" instead of concatenating the list of categories. so an option to consider might be to at least display the actual selected category name if one category is selected or maybe even two, but that might already become tricky if the search engine optimization (seo) and or content editing experience categories are selected, that might already require concatenation.

and that brings me back to the category chips. with the category multi select displaying that unspecific string "x categorie(s) selected" category count, the multi select has sort of externalized the display of the list of selected categories to the chips. so categories have the multi select as well as the chips as an area of interest and focus. then there is also the question what happens if at one point another multi select is added does that get chips as well then? and how to communicate that visually either way?

circling back, if the chips might be removed that could be beneficial for ✨ Make the overall design of the browse page more compact and dense Active , but it might also ease the difficulty about the area of focus for the category multi select. you would have a single multi select instead of two areas in close proximity that provide information. but that would be the bigger scope. for this issue my suggestion would be to consider displaying the category title if one category is selected and if more than one category is selected switch to the "x categorie(s) selected" pattern. but i would also fine with the current state. what do others think?

How about changing the dropdown text to 'Select more categories' when one or more categories are selected? The dropdown's purpose is clear, and we are already displaying the selected categories as chips.

My $0.02 is that for simplicity's sake and making an incremental step forward, that for the scope of this issue we:

- leave it as "1 category selected" or "2 categories selected..." but for 0 we do the default that we have now.
- we leave the chips in place to show the user which categories are currently selected

This is ready for reviews as the tests are all green now.The current state of the MR is inline with what was suggested in #11 ✨ Filter by category should be scrollable Active .

Thanks! Looks small, but big for UX

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