Enhance category filter to allow AND / OR selection

Working on it.

I did some progress in the issue but as I'm going to leave now I pushed my code.

Hey, I'll continue doing this feature =)

Hi, I'm sorry, I can't continue with this task, I did not make any progress.

+1 for the idea in general. but i see one potential problem (i am not sure if i posted it already somewhere in the issue queue, if i made one comment about it on the drupal slack or if i just forgot to post it anywhere yet - i've searched but haven't found it)

but in the current state there is already the problem what is the sample size if no category checkbox is checked? what is returned if no search string is entered and what is returned if you search for a string with no checkbox checked? that isn't clear.

with the radio button labels any and all with the all radio button checked things might get even more confusing. "does that mean all checkboxes are checked then based on the wording?" is an assumption that might turn up.

I'll keep working on it. Just came back from vacation ;)

@rkoller as far as I understand the any and all are specifically for the categories. If you search for a string with no checkbox checked, it will return all modules that contains the string.

@paulocs yes i know that if no checkbox is checked all modules are searched for an entered string. but based on the micro copy it is not directly apparent to the user. you have to test the behavior and validate your assumption, in particular if you use the ui for the first time. but i have to admit i still have to at least think myself from time to time.
i have taken a closer look again. turns out for a narrow viewport you have an h2 named Categories but if you get to a wider viewport a legend element is displayed instead. but the interesting part it has a visually hidden span prepended:
<span class="visually-hidden">Filter by module </span>categories. For one if a a blind user is visiting the page on a smartphone then the announced title is categories while if the user is visiting the page later on the laptop or desktop the announced string would be Filter by module categories. That is even more confusing. But i think the visually hidden span points in the right general direction. Why not simply use something like Filter categories across all viewports and for everyone? That title would imply that the category checkboxes are for filtering (that way it is clear if no checkbox it is checked the scope isnt narrowed and filtered), at the same time it is bridging the gap to the filter component to the right on the desktop viewport, and it would also make the comprehension of the any and all checkboxes proposed for the resolution of this issue more easy.

I've added #3314350: [meta] Usability improvements for Project Browser only as related issue since it was already linked to the google data studio parent issue.

I'm worried about the UI complexity this will bring. Tagging for design

hey team, I worked mainly on the back-end to provide the feature (No css at all). I agree with #11 that we should have good a user-friendly design. For now I've created a radio button bellow the CATEGORIES title so you can review if the functionality is working and give feedback (see image attached).

What do you suggest in terms of design?

If we click the clear filters button, the value of orAndCategoryFilter becomes undefined and errors out on page refresh as the key for orAndCategoryFilter is missing in onSelectCategory() method in Search.svelte. We should map it with the store.

orAndCategoryFilter: $orAndCategoryFilter

Aside the points mentioned in #14 there are two more to mention.

The first could probably be fixed as soon as #3300262: Adjust the checkbox design for the categories sidebar to the Drupal Design system and #3293899: Adjust the radio button design to the Drupal Design system are landing. cuz in the current patch the different form elements look crammed together aside the fact they are rather small. visually the radio buttons have even less spacing to the first checkbox than there is spacing in-between checkboxes afterwards. it might be also worth a thought so set apart the two radio buttons a bit from the checkboxes.

the other detail is about the micro copy of the radio button labels. i've had a brief chat with @grienauer. we came to the conclusion that the meaning and difference between the words any and is not that easy to understand. for one all could create the associated/assumption that by selecting all checkboxes get selected. and then there is the question what any means in contrast in this context. and over all what is the exact difference between the two in the end. the two terms make the user at least think.
and one other detail to mind even though the two words are brief and short in english, to translate the meaning exact and clear into a foreign language the resulting words might get lengthy. @grienauer made the suggestion "Ausgewählte" and "Alle" for German. But the suggestion isn't exact nor clear and one of the terms gets significant longer. any and all makes things not easy at all.

i think those two labels might need some more word smithing. it might be worth a thought to consider to put the issue on the agenda of one of the upcoming ux meetings.

I'll work on #14 and fix the 'Custom Commands Failed'

I'm +1 with @tim.plunkett's concerns in #11. I'm not sure this should be pursued at all. Does not having this prevent a user from finding what they need on the rare occasions they visit Project Browser? The need to install a module isn't that frequent. Even if it is an obstacle, is it a large enough one to justify adding some significant complexity that becomes a new surface where surprise errors and test coverage gaps can emerge?

I'm checking the comments and I'll wait until we come with a conclusion if we should add this feature or not.

I'm with @bnjmnm, mostly from the point of view of "is it really needed?" The complexity of the plugins can be increased too, mostly due to this one feature.

So as it will increase the complexity a lot for a non-important feature I'm closing this issue.

@chrisfromredfin feel free to re-open the issue if you think we should keep working on it :)

I also agree with #11, #17 and #19 in general that adding the radio buttons for switching between AND and OR brings in complexity and entails a few follow up problems (i am also not sure if adding those, as suggested in the proposed solution, is the best idea) . but i would vote against closing the issue as a won't fix because the initial underlaying problem why the issue was opened in the first place still persists: "Users are unsure if, by selecting multiple categories, if they are getting an exclusive or inclusive search.". so to communicate it more clearly what to expect from the selections made for a search and what and how the module repository is searched might be a direction to turn towards?