Change layout to make plugin-specific content more clear

In general i like the idea of moving the plugin tabs. In the current position they are sort of confusing to the user. the tabs are positioned/crammed between the "filters block" and the list of "results" even though each plugin tab represents a whole different context of modules. it is even more apparent if you take a look at the order of the components mobile first:

current:
1. categories
2. search field
3. filter block
4. plugin tabs
5. results

the switching of the context from d.o (mocked) to drupal core is way down at position four. so the screenshot in the proposed resolution solves one problem by moving the plugin tabs to the first position:

proposed solution
1. plugin tabs
2. search field
3. filter block
4. categories
5. results

but by having the "search field" and the "filter block" in position two and three right after the plugin tabs in position one you now have the "categories" pushed to the back like the plugin tabs were before.
but ideally the users should be able to narrow down the scope before a search query is send aka they select the desired plugin and select the desired categories. therefor i wonder if the following order might make more sense?

alternative
1. plugin tabs
2. categories
3. search field
4. filter block
5. results

Filters/Recommended Filters, Search Textbox and List/Grid view are common across all enabled plugins. I will work on the suggested design change for now.

Plugins moved above container.

the provided screenshot in #7 looks good. the only odd thing is the patch fails to apply locally with composer-patches for me. no idea why :/ i've tried with the latest project browser dev release on a drupal 9.5.x-beta2 release.

and one detail that was brought up during todays PB meeting by @chrisfromredfin is the idea and wish that the buttons would look more like Drupals tabs. the easiest for Claro might be to style those grey plugin source buttons as secondary tabs defined in the Drupal design system

.

Thanks for the update @srishtiiee! I don't know why but i am still unable to apply the patch correctly. Still the same problem with composer patches like in #8. As seen in the screen shot i am able to see the plugin source tabs in the new position with the new styling but also still the tabs in the old place as well. no idea what is causing that.

a few details i've noticed about the latest changes:

• The green focus outline should have no border at the bottom as illustrated in the screenshot for the level 1 tab in focus.
• On hover the color currently remains at #55565b but it should be #0036b1 instead
• On hover the background color is #f5f8ff but it should be #e5edff instead.
• The blue border-bottom for the active tab should be 3px for the active tab for level 1 tab and 2,5px for level 2 tab. i was unable so far to figure out where and how the border-bottom is set. but on the screenshot the border-bottom for the active level two tab (drupal core 77 results) looks kind of too thin.
• The padding left and right of the tab label should be 2em(32px) for level 1 and level 2 tabs as far as i understand. but the padding for the level 2 tabs currently is only at 10px.
• The bottom line is currently set to: 2px solid #dee2e6 it should be 1px solide but i am not sure which color should be used. in the legend in the Drupal Design system it says #82828C
 while the line that is described is set to #D3D4D9. not sure what the right color is to go with?

Used Claro styles instead.

I've also applied the latest patch locally. A few observations and thoughts:

• The styling for the plugin source tabs looks all good now. Excellent thank you!
• One nitpick the too narrow margin mentioned in #14.2 is still too small imho if you compare it with the second example in the drupal design systems tabs section. the second level tabs and the search field label (in the latest patch) are still too close. for illustration purposes i've placed the design system example (on the left) next to the project browser page (on the right) and zoomed in the project browser page a bit to get roughly similar sizes.



• In regards of the layout the latest changes changed the order again. I still consider #13 the more clear order and layout as explained in #2.
• The newly (?) added separator line between the list/grid buttons and the categories side bar and the search results looks interrupting. i am not sure if it is necessary. it is also missing for smaller viewports.

interesting perspective and counter argument. thanks for that! i'll have to test and think through that after dinner and write up a comment.

but one detail to note upfront. in regards of the multiple plugins case and the fact that each plugin source tab could have its very own filter settings. that is something i completely realized one of the last two weekly meetings. i completely agree that it should be communicated clearly to the users.
the detail in that regard i forgot to mention in my last comment. each plugin source tab has its own number of results. THAT is completely misleading. a new user (or even me one or two weeks ago) is in the drupal.org mocked plugin source tab. with no search term entered out of the box drupal.org (mocked) has 4262 results, drupal core 77 results, and a third custom source has 300 results.
you set now a certain set of categories and you make a few bespoke adjustments to the filter settings and enter the search term "migra" in the search field.
now you get the search results underneath in the form of module cards. but at the same time you get the number of results for drupal.org (mocked) with 56 results and for drupal core 3 results and for a third plugin lets say 7 results. that gave me, until i've learned that each plugin source tab could have its own filters, the impression all plugin sources are searched with the same set of filters leading to those resulting numbers. meaning if i enter a search term that has an effect on all the available plugin source tabs due to that fact that each tab gets the search results displayed.
i would probably remove the count from the plugin source tabs completely and simply rely on the results count which is currently inside the filter component and is in order to be moved out of that #3310896: Improve UI of results count. Having a single result count makes it clearer that the scope of the search and the filter settings belong to the current plugin source only. Or is there a particular benefit of adding that results count to each plugin source tab I am unaware of so far?

apologies. ran into an issue that at one point the patch hasn't applied anymore locally when i've updated my composer install with another unrelated patch. from the point on i was unable to finish my testing. well at least i've remembered drupalpod tonight and managed to get the patch in a workspace running. will finish testing and playing around tomorrow and post a comment then finally.

just one detail upfront i've noticed about the 2nd level tabs. i usually run drupalpod in firefox but my default browser is safari. but in firefox the following for the focus outline of the active tab, it happens in the latest edge as well, but in safari it does not happen. there things behave as expected.

It took me a little bit longer to wrap my head around the problem. Played and tested a bit more today. Hereinafter the observations and conclusions in the context of the plugin source tabs:

1. In desktop browsers switching the plugin source leads to immediate scrolling up (see jump.mp4). Depending on the tab it is either scrolled/jumped to the status message or to the top of the page - I've tested in Safari, Firefox and Edge. Visually the most challenging example was in Edge when you click the Random Data tab, it scrolls first up towards the status message and then immediately scrolls back down to the tab, and that happens fast. In other browsers it jumps/scrolls up to the status message. Switching to the Drupal Core source jumps to the top of the page. Switching to drupal.org (mocked) induces no scrolling/jumping same when testing on iOS which I consider the expected behavior. Cuz those scrolls and jumps are unexpected to the user and might be a cognitive stress for some of them.

2. re #18- a heavy +1 for communicating the multiple plugin source case. But from my point of view the counter-argument made not necessarily applies. The categories change no matter if the sidebar is to the left of the stacked search field, filter componentand search results combo, or if the sidebar is next to the search results underneath the filter component introduced in that filter. I consider both cases potentially introducing a cognitive load to the user. And Í am not sure if the categories occupying the whole left column would give the impression that those categories would be shared across plugins since the sidebar would be underneath the plugin source tabs even with the faulty layout in #13. but there are potentially two problems. For one only categories are really saved for each plugin source and the filter component is sort of disconnected from the categories filter type:

a) currently the filter type "categories" stands out - it has differing category terms for each plugin source and the checked terms are saved on a per plugin source basis. In contrast the other filter types and its values are consistent across plugin sources. If you set for example the Development Status filter type to Active it is Active in every available plugin source.
But then there is also the case of the Sort by select which has a different amount of options for Drupal.org (mocked) and Random Data (same five options each) compared to Drupal Core which actually only has two options (a-z, z-a).
I wonder if it would be clearer as well as more flexible if the other filter type values are also saved on a per plugin source basis? That way it would be clear each tab has its very own filter settings (At the moment you have to remember which filter settings which plugin source has and which of those are persistent and which on a per plugin source basis). At the same time it would be handy being able to set differing filter settings for drupal.org and Random Data.

b) If you take a look at the Drupal Core source tab. You have the Development Status, Maintenance Status, and Security Advisory Coverage filter types. Those aren't really necessary for Core. All core modules are active, maintained and have a security advisory coverage. All the three filter types could basically removed for the Drupal Core plugin source.
But that isn't the actual point instead if you would remove those three from the Drupal Core filter component you could actually remove the filters button as well, that would leave you only with the sort by select box and in case a category is checked the corresponding chip(s). And that is the point, no matter where the categories sidebar is placed either in the position shown in #13 or like in the current state of the patch, there is alway a visual disconnect (in the current patch the categories sidebar and the search results are even visually separated from the filter component by a divider line).
But strictly speaking, semantically the categories sidebar belongs either into the expanded section when the filter button is pressed or the filter type and its values belong into the categories sidebar. But in the current state you have a disconnect which makes the comprehension difficult.

c) and also strictly speaking the Sort by isn't a filter but is about sorting the search results. Semantically it would be a better fit alongside the list and grid buttons. Each is about reformatting the output while the filter types are about the actual search result count.

3. The update spinner in the center of the page is kind of a distraction. When you enter or alter a search you always notice something is in motion on the screen for a moment but you need a second until you notice/realize what it was. There is always the fear you miss something important. I would expect if the spinner would show up either in line in the search field or in the area where the search results are displayed it would be ok, but in the center of the screen over for example the expanded filter component is kind of distracting and confusing.

4. The Sort by select box in the Drupal Core plugin source narrower than for the others with longer options like Project Usage.

5. Two microcopy details i've also noticed (probably out of scope but related somehow - probably suitable for a followup issue):

a) The placeholder text for the search field is sort of confusing: Module Name, Keywords, etc. Module name is clear but what is a keyword in the context of project browser and what means etc - what else is available? The only searches that lead to results were module names. But if I search for the core (experimental) category term there were no results - even with the option show all on each filter type. The placeholder text implies a lot of possibilities to query but the reality if i pick even a word from the description visible in the card on the screen or a category there are no hits?

b) If a search in a plugin source has no results you get: No records available. The terminology is confusing. Me as a user thought I was searching for projects but what does records actually refer to? projects would probably be the more appropriate term? And instead of available i would also refer to actual findingsomething or unable to find something. In general some word smithing.

As discussed with @fjgarlin on Slack the list perviously mentions points in the comments that should be fixed within the scope of this issue:

1. ref #17

One nitpick the too narrow margin mentioned in #14.2 is still too small imho if you compare it with the second example in the drupal design systems tabs section. the second level tabs and the search field label (in the latest patch) are still too close. for illustration purposes i've placed the design system example (on the left) next to the project browser page (on the right) and zoomed in the project browser page a bit to get roughly similar sizes.

2. ref #21

just one detail upfront i've noticed about the 2nd level tabs. i usually run drupalpod in firefox but my default browser is safari. but in firefox the following for the focus outline of the active tab, it happens in the latest edge as well, but in safari it does not happen. there things behave as expected.

see https://www.drupal.org/files/issues/2022-10-23/focus_firefox.mp4

3. ref #22.1

In desktop browsers switching the plugin source leads to immediate scrolling up (see jump.mp4). Depending on the tab it is either scrolled/jumped to the status message or to the top of the page - I've tested in Safari, Firefox and Edge. Visually the most challenging example was in Edge when you click the Random Data tab, it scrolls first up towards the status message and then immediately scrolls back down to the tab, and that happens fast. In other browsers it jumps/scrolls up to the status message. Switching to the Drupal Core source jumps to the top of the page. Switching to drupal.org (mocked) induces no scrolling/jumping same when testing on iOS which I consider the expected behavior. Cuz those scrolls and jumps are unexpected to the user and might be a cognitive stress for some of them.

see https://www.drupal.org/files/issues/2022-10-23/jump.mp4

for the rest of the points made in #17, #19, #21 and #22 their own issues will be created soon.

i've opened the issue in drupalpod. i am not sure if it is necessary to run the yarn build for that? there for i've tested everything without running yarn and then ran yarn install, yarn run build, and drush cr in the project browser svelt folder and then retested everything. but in both rounds i've got identical results.

#23.1 looks good now!

#23.2 unfortunately there is no focus outline at all in any browser - see https://www.drupal.org/files/issues/2022-10-27/no_focus.mp4 . i've tested in safari, firefox and edge.

#23.3 i've tested in safari, firefox and edge on desktop. there is no scrolling at all anymore. the position is kept in desktop browsers as well when the plugin source is changed. excellent!

in regards of #23.2 i'll set the issue back to need work.

Thanks for the fix @narendraR! I've quickly taken a look at the latest change in Drupalpod. I can confirm that the focus outline is visible again now. But there is only one minor problem left. if a none active tab gets into focus, the focus outline is shown now, but the grey separation line at the bottom gets hidden (not happening for the blue underlining for active tabs when in focus). i've added a screenshot, on the left a screenshot from the tab variants section in the drupal design system and on the right the current styling in project browser.

Thanks @fjgarlin and @rkoller for review and feedbacks 🙏.
Addressed latest feedback.

thank you for working on it @narendraR! it might be a nitpick but as you can see in the video i've attached, when the second level tab, which isn't active gets in focus, you have a slight shift of its label. something that doesn't happen for the first level tab nor second level tabs for example on /admin/appearance/settings. it looks like as you can see in the attached video it happens because of the 1px border bottom which is added when getting into focus.

Added 1 px in padding-top to adjust bottom border. May be I am doing something wrong here and it needs to be done in different way.

hm i've tested the latest changes. i can confirm that the shift doesn't happen anymore. but i am not sure if to counter the shift into the opposite direction is the appropriate measure instead of not let it shift in the first place. but unfortunately i am not much help here. :( perhaps someone else has an idea? I've only searched a bit and compared the markup and css of project browser page with /admin/appearance/settings in the hope to find a potential difference that might be causing the shift but no luck.
but one other detail i've noticed. on the appearance page (/admin/appearance/settings) and on the block layout page (/admin/structure/block) for example the second level nav tabs are link elements while in project browser they are button elements. i think it would be good to be consistent with the rest of core and use link elements as well?

As agreed in last weeks meeting i've created follow up issues for the points i've raised in the comments in here that would have delayed the fix of this issue:
#3318787: The spinner for updating the search results is distracting and disconnected
#3318791: Remove search placeholder, change field label to "Search"
#3318789: Improve the microcopy for no search results available
#3318817: Improve the categories filter type in context to the rest of the filter component ui

i agree. the markup should be consistent with the rest of core so swapping the element to a link element would be good.

and a nice to have, or for a follow-up, might be figuring out why the shift in #31 happens and how to prevent it. shifting in the opposite direction in #32 fixes it but i think not having the shift in first place would be preferable in the long run.

Changes pushed in MR. Also patch attached.

i've tested the provided patch file in #37 instead of the merge request. i am able to apply the patch again (the merge request failed the last few times and i had to test in drupalpod). i've manually tested. the focus outline looks fine now. i've also compared the second level nav on the project browser page with one on /admin/content in the safari web inspector. the css rules look identical now. and the element for the second level nav is also changed to a link element. from my end everything looks great and good to go. thanks @narendraR! i leave the status to needs review that someone could take another look from the code end if that's necessary.

The proposed solution includes adding information to the categories sidebar regarding which plugin is being filtered. This should either be added, or the issue summary updated to reflect the scope as it is currently (a decision may have been made in the comments, but I've not yet read them fully).

Addressed most of the feedback and added comments for remaining points. I have not added plugin name under categories for now. This can be done once approach is finalised.. may be in a follow up.

Got A11y maintainer interest in marking up the source select as tabs.

Tab pattern used as suggested in review.

Feedback in MR

It seems like code get removed due to rebase/latest code merge, hence created a new MR #332 of the relevant changes only.

Rebased with latest changes.

Marking NR to get testing to run.

I rebased this after committing #3375619: Fix test fails from upstream TUF changes and then also removed the remaining out-of-scope test changes. Not sure where those came from, but it passes without them.