SortBy filter is conflicting after switching between different tabs

My expectation is that if you never interact with the Sort option, every tab should be sorted by their default sort.

But if you select a specific Sort for one tab, it should persist across tabs when possible.

For example, if you select Z-A on one tab, it should be used across all tabs.

I think this issue is obsolete as Make relevance the default sort 📌 Make relevance the default sort Active removes the 2 sorting options that were causing the problem.
Marking it needs review.

I think this is still a valid issue as per #3.

So i have recorded a video demonstrating what's happening on 2.0.x.In this video i have 4 sources enabled.

The only thing that's not happening correctly is when i select say Z-A sort type in Random-data plugin and i visit some source plugin which does not have that sort option in the select list (Contrib modules in this case) then the sort option is set to default across all the tabs.Not sure whether we want this or something else.
Marking it NR for getting some opinions on what we want.

So given that #3 is generally the preferred behavior, the open question is still what should we do in this situation?

(1) Go to source "D", sort by Z-A.
(2) Jump back to source "A" which has no Z-A.
(3) So it sets source "A" to sort by its default.

CURRENTLY it's also setting ALL sources to sort by their defaults, too, so
(4) Jump back to "D" and it's no longer Z-A

Should we instead keep D's sort to Z-A, effectively meaning we're storing the active sort per source? But if that's the case, what would happen if I:

(1) go to source "D" and sort Z-A
(2) go to source "A" which has no Z-A so it sorts by Relevancy
(3) change source "A" to "date"
(3) go back to "D"
- should be it still on Z-A? Or should it be "date" (if available) or should it be its default?

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-12-13 Active . That issue has a link to a recording of the meeting.

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

When you tag an issue for usability review, please make it easy for the usability team to review the issue. Update the issue summary:

• The "Proposed resolution" section should describe all the changes made in the issue.
• The "User interface changes" should show the existing UI and the proposed UI.
• The "Remaining tasks" should include one explaining the usability issue(s).

For this issue, the issue summary described a problem that has already been fixed. After we tested that, we had to read the rest of the comments to figure out what the open questions are.

I am adding the tag for an issue summary update and setting the status to NW.

At the meeting, we discussed the various controls: filters, sort order, and display (list or grid). For each of these, there are reasons to have different choices depending on the source:

• Filters: The categories for modules are different from the categories (yet to be determined!) for recipes. When themes are added to the project browser, they are likely to have yet another set of categories. The statuses of security, maintenance, and development apply to contrib modules but not to core modules (except for development status of experimental modules).
• Sort order: it does not make sense to sort core modules by recency, but this is an option for contrib modules. Relevance comes from some external data (Solr or ElasticSearch, I think) and is not available for core modules.
• Display: Currently there is very little information to display on recipes, compared to modules, so users might prefer different displays. When and if we add themes, users will want to choose a different display for them.

For each control, considered by itself, that suggests having a setting for the source (tab) that is independent of the other sources (tabs). If I choose a filter, sort order, or display for contrib modules, then I want those choices after switching to another tab and then switching back to contrib modules.

Considering the various controls together makes the decision clearer. We do not want the choice of filter to be tied to the source (tab) but the choice of display to affect all sources (tabs).

If we did want one of these choices to affect all sources, then the control should be moved out of the tab, but let's not do that.

Some related observations:

• Do not show result counts for the other sources. Keep the count above the results, and remove it from the tab.
• We know that there are technical reasons for keeping core modules separate from contrib modules, but users do not care about that distinction. They would rather see all modules in the same place. It may lead to confusion as modules are moved from core to contrib.

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