Filter (categories) selection is leaking over into other sources

Totally agree. I think we originally assumed everything would have the same TYPES of filters, but not necessarily the same values inside (for example, recipes may have categories, development statues, maintenance status, etc - but they wouldn't have the SAME categories, even if they did).

So I think we have to do this.

I was trying to reproduce what's demonstrated in the video by @rkoller but i think this problem no longer exists.This was solved in This issue 🐛 The functionality of showing results behaves abnormally on tab switch sometimes Active i guess.

@rkoller, Do you think this issue is ready to be Closed(outdated), or is there anything further that still needs to be addressed?

took me a while to refresh my memory about the scope of the issue. i've first only skimmed through the title and the problem statement section, based on that i would have said the issue could be closed as outdated after the issue @utkarsh_33 linked fixed the leakage of filter selections across source types.

buuut reading through the proposed resolution more closely another time i think the more fundamental conceptual problem is still left to tackle that is not in the title and problem section but the proposed resolution only. At the moment, if you illustrate the components on the pages as priority guides, you get:

1. secondary tabs
2. search field
3. filter
4. results

Would the search scope only be the active source type, the visually hierarchy would be crystal clear except for the redundant search count. the user first decides the search context by selecting the active source type (1), then decides on the search term (2), then is able to refine and narrow down the results by filtering (3) and then is able to browse the final results (4). everything would be in a clear hierarchy and order top to bottom.

Instead on every change of the search string and/or interaction with the filter settings a new query is sent against each available and enabled source type. the individual number of results for each source type is reflected in each secondary tab (1). The count on the active secondary tab/source type (1) is redundant to the result count in the results section (4). That way the users attention is drawn between the secondary tabs (1) and the results (4) - while being in search field (2) which is part of the filter section (3). There is not that clear visual hierarchy and order and clear separation of concern of all the steps involved in the search experience. the relationships are not clear but intertwined. overall the interface still has a mixed messaging that lacks clarity.

there is also the question what is the benefit and or the actual need to search across all available source types? instead it might become rather a performance hog. at the moment you only have the contributed modules source type that queries the endpoint on drupal.org but sooner or later the recipes source type will do that as well, and themes might be added there as well. that way you would get three requests on every change of the search string or adjustment of the filter settings. and there is still the possibility that sites and agencies add their own private source types on top of that.

In the following the two approaches including including the proposed resolutions for each variant:

variant A - query all source types:

• move the search field between the primary tabs and the secondary tabs.
• remove the result count from the secondary tabs
• keep the search scope to all known and enabled source type

variant B - query only the active source type:

• remove the result count from the secondary tabs
• limit the search scope to the active source type

I regard of clarity and a separation of concern, my personal preference would be clearly variant B...

ps. in the drupal dojo austin where i'Ve presented the current state of project browser i got a few ideas/suggestions in regards of source types and filters that might apply here as well. but i havent had the time to summarize the findings. will catch up on this in the next few days.

I agree with @rkoller that variant B is a better approach to solve this fundamental issue that exists right now.

ps. in the drupal dojo austin where i'Ve presented the current state of project browser i got a few ideas/suggestions in regards of source types and filters that might apply here as well. but i havent had the time to summarize the findings. will catch up on this in the next few days.

Is there anything that you wanted to update or add according to the above comment or shall i start with the approach in variant B?

i wouldn't add anything to the scope for this issue. but i've summarized the additional points raised during the aforementioned drupal dojo austin in: 🌱 Discuss and perhaps improve how source types are integrated into the overall search experience Active