Allow to JS-filter blocks in regions on the block layout administration page

On it :)

Hello, the first patch proposal is attached.

I put to search on the entire line(tr), so as we can see on the gif demonstration attachment if we type system or core, all blocks of this category will be displayed. I've considered the entire line to make it easy to find custom categories or something like that, views for example when you don't know the block name but you know that's a view block.

But we can discuss that if you think that doesn't make sense and the filter must query only in the block name is easier to change.

Also, the patch hides all regions that do not contain any block base on the query, same thing, we can change this behavior to keep all the regions and display the message that does not contain any block based on the filter. But this behavior makes it difficult to find blocks on the bottom page, that's why I started to hide the regions too.

@anybody what do you think?

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

This seems like an excellent addition!

It will need a test case to cover this new feature though.

Adding unit tests.

Tried to fix CCF for #9.

@joaopauloc.dev just fyi for next time. Should include an interdiff with all patches

Also when you add tests should add a test-only patch followed by the full patch (with the tests and fix)
allow-to-js-filter-blocks-3273173-9-tests-only.patch
allow-to-js-filter-blocks-3273173-9.patch

Should be in that order so we can see the test-only fail and full patch pass. Shows we have a good test

Adding this one back to my list to review again though.

The last submitted patch, 10: 3273173-10.patch, failed testing. View results →

Trying to fix unit tests.

The interdiff tool following this doc → didn't work to me, maybe it's because I started wrong.

Let's see if this fix will pass and the next time I will follow all the steps to create a patch and provide that interdiff, sorry about that.

Hi @joaopauloc.dev, I have reviewed your patch on drupal version 10.1.x. Using filter option we can easily find out blocks.I think we can move the issue to RTBC if we don't need any Additional features. Need RTBC+1

Testing the patch out.

Searching for "ab"
No filter runs

Searching for "abc"
Filter runs

Seems like it needs least 3 characters to run

Changing how we query on the line, now we search only the first and second td that contains the block label and region name.

Issue I had from #17 was resolved.

Good job!

The last submitted patch, 10: 3273173-10.patch, failed testing. View results →

The last submitted patch, 10: 3273173-10.patch, failed testing. View results →

The last submitted patch, 10: 3273173-10.patch, failed testing. View results →

The last submitted patch, 10: 3273173-10.patch, failed testing. View results →

The last submitted patch, 10: 3273173-10.patch, failed testing. View results →

1. +++ b/core/modules/block/js/block.admin.js
   @@ -106,4 +106,100 @@
   +        once('block-filter-region-text', 'input.block-filter-region-text'),
   

   Ideally, we would use data-drupal-selector for targeting the input.

2. +++ b/core/modules/block/js/block.admin.js
   @@ -106,4 +106,100 @@
   +            // Query in first and second column, which means the block label and region name.
   ...
   +          // Each blocks until found one block that means we can't hide the region.
   ...
   +        // Back to the table element and for each region without blocks will be hidden.
   

   Nit: These should wrap to a new line.

3. +++ b/core/modules/block/js/block.admin.js
   @@ -106,4 +106,100 @@
   +                    <strong>${Drupal.t(`Any block found.`)}</strong>
   

   It looks like the pre-existing pattern is to not show a message when there are no results. If we want to keep this, at least we should improve the wording here. Something like "There are no blocks matching the filter conditions.".

4. +++ b/core/modules/block/src/BlockListBuilder.php
   @@ -130,6 +130,22 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +      '#size' => 30,
   

   We should increase the size to fit the placeholder text in Claro.

5. +++ b/core/modules/block/src/BlockListBuilder.php
   @@ -130,6 +130,22 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +        'class' => ['block-filter-region-text'],
   

   We should probably hide this when the user has no JavaScript. This is already implemented for the search filters in the extensions section.

6. +++ b/core/modules/block/src/BlockListBuilder.php
   @@ -130,6 +130,22 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +        'data-list-element' => '.block-layout-list',
   
   @@ -179,6 +195,7 @@ protected function buildBlocksForm() {
   +        'class' => ['block-layout-list'],
   

   Can we use a data-attribute instead?

7. +++ b/core/modules/block/tests/src/FunctionalJavascript/BlockFilterTest.php
   @@ -80,6 +106,122 @@ public function testBlockFilter() {
   +    $session->wait($debounceWaitTime);
   ...
   +    $session->wait($debounceWaitTime);
   ...
   +    $session->wait($debounceWaitTime);
   ...
   +      $session->wait($debounceWaitTime);
   ...
   +    $session->wait($debounceWaitTime);
   ...
   +    $session->wait($debounceWaitTime);
   ...
   +    $session->wait($debounceWaitTime);
   ...
   +    $session->wait($debounceWaitTime);
   

   Can we wait for a specific change in the browser instead of an explicit time? We've had problems with explicit wait times in the past in the cases where the CI might be running too slow or fast for some reason.

On it, fixing comments.

@lauriii I removed some asserts that could be false test failed depending on theme blocks structure.

Appears the points in #26 have been addressed

This works great except for one issue: pressing Enter in the filter field submits the form and saves the block layout and then reloads the page, which is unexpected; the module filter has code to prevent this from happening, I think this should be copied over here too.

@longwave added the preventDefault function and event listener

Confirmed not able to press enter and reload the page. Think this would be a great feature to add.

This will be a great addition! MR has some things that should be addressed before it goes in.

working on comments

Appears the functionality is still there and the points have been addressed.

The JavaScript refactoring looks great, and nice turnaround time on that 👍

I have another round of feedback on the MR, but it's largely to polish up what's looking like solid code already.

Working on new comments

Thanks for keeping this alive @joaopauloc.dev!

Added some feedback mostly around the comments in the JS.

I wondered if this could reuse existing JS filtering code, but the block layout page is quite different to other lists that we have to filter, so I don't think it is worth trying to unify.

Feedback for comments appear to be addressed.

The MR should be on 11.x instead of 10.1.x.

Can someone update that? There are instructions for rebasing → in the Drupal wiki.

joaopauloc.dev → closed merge request !3462

New merge request created to 11.x

Thanks!

I think we may need to do some UX testing on this one because this is the first instance where we are introducing a JavaScript filter in a page that has table drags. I personally think that the experience is a bit confusing because all of the other regions disappear and at this point you can most of the time only edit the block instance itself.

Providing the patch to make it easier for the UI friends to test it.

@smustgrave brought up the issue over in the #ux channel end of last week. I've added the issue to the meetings shortlist today. i've already taken a look at the patch during the week to get an idea think it would be really helpful to discuss it in a group context.

But when testing i've noticed one technical aspect i wanted to post upfront. End of last week I was testing in MacOS Monterey with the latest versions of Safari, Edge and Firefox with MR4687. I've retested before todays meeting in Ventura now (also with the three aforementioned browsers) and retested now with the patch provided in #54 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work in case there are any changes. But in all three scenarios and all three browsers i ran into an uncaught TypeError with "rowObject.matches is not a function".

The issue turns up if i try to drag one of the blocks, no matter if something is entered in the filter field or not, the block somehow is not released from the drag state. meaning i am not keeping the mouse key pressed anymore but the block is still moving along up and down with the mouse cursor. the uncaught type error is flooding the console with every position change of the block when the browser window with the block layout is in focus. sometimes the issue turns up on the first, sometimes with the second or third drag, but it happens and seems inevitable. i'll add a short video illustrating the issue in firefox.

Hello @rkoller, thanks for the feedback.
I also found the issue that you mentioned("rowObject.matches is not a function"). But is related to another issue, you can see more details here Javascript breaking on block layout page after drag or select new region 🐛 Javascript breaking on block layout page after drag or select new region RTBC

ah thanks for the link @joaopauloc.dev! out of curiosity, i am not a developer, is acceptable to apply both patches, the one for this issue alongside the one for the other issue, at once? cuz usually issue should be kept isolated was my understanding?

i've successfully applied both at once but the issue still persists but the type of typeErrors changed. the interesting detail i have for each of the three browsers different typeErrors. should i post those different outputs over in the linked issue?

Hello folks,

I've updated the javascript code that filters to use only vanilla javascript since I saw this one [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint → .

@rkoller thanks for the feedback. I also find strange behavior on the filter. After using the filter, the drag and drop does not work correctly in some scenarios. One issue that I found was when you move a block to another region and use the filter, the block moved appears in the old region, when the filter is clear the block appears in the correct region again.

I applied the patch of the issue Javascript breaking on block layout page after drag or select new region 🐛 Javascript breaking on block layout page after drag or select new region RTBC , as the javascript is breaking when we use the drag and drop we need to fix this error to use and test the filter. So I fixed the error here too, but I don't know how to proceed now, should we close the issue Javascript breaking on block layout page after drag or select new region 🐛 Javascript breaking on block layout page after drag or select new region RTBC or wait for the issue be fixed as this filter needs the fix.

@rkoller I don't know if the issues that you find are related to the issue that I mentioned, but maybe is a good idea to test again with my last commit. But feel free to add information related to behavior that you found.

I'll wait for the next reviews and fix if any error found.

Thanks in advance.

thanks for the explanation @joaopauloc.dev!

i've tried again to apply the latest changes (MR4690, from the other issue, and MR4687, from this issue) but for MR4687 this time i now get Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/drupal/-/merge_requests/4687.diff. Before both patch applied without any errors. But when I went into the block.admin.js file and compared the changes with the changes on gitlab for your latest commit, the changes were in place (but i only took random samples). Testing in the three different browsers lead to the following behavior:

1) Safari
a) without anything added to the filter field:
I just clicked and dragged a block and again after releasing the mouse button the block kept following the vertical movement of the mouse cursor and an error in the console looks like that (but it isn't flooding the console anymore)

TypeError: undefined is not an object (evaluating 'weightField[0].className') is_BNQJD_M5×SLVCGCxuBjnXzqPB9CLrJOuR16XAnhZPE.js:378:3014
(l (anonymous function) - js_BNQJD_M5×SLVCGCxuBinXzqPB9CLrJOuR16XAnhZPE.js:378:3014
[f] (anonymous function) - js_BNQJD_M5×SLVCCuBinXzqPB9CLrJOuR16XAnhZPE.js:229:11762
[ (anonymous function) - js_BNQJD_M5xSLVCGCuBinXzqPB9CLrJOuR16XAnhZPE.js:229:2446
If] dispatch - js_BNQJD_M5×SLVCGCxuBjnXzqPB9CLrJOuR16XAnhZPE.js:3:40003

b) added the string "tabs" to the filter field
the dragged block behavior is still the same. but when in addition i drag the secondary tabs block from the breadcrumb section into the highlighted section i see the placeholder text "no blocks in this region" three times for the breadcrumb section and one "no blocks in this region right before the highlighted section. if i drag the secondary tabs block back into the breadcrumb section the secondary tabs line replaces one of the three previously shown up "no blocks in this region" lines and there are only two left. if i move the secondary tabs block out of the breadcrumbs section there are again three lines of "no blocks in this region"

2) Firefox
a) without anything added to the filter field:
same behavior like in 1a) but different error:

Uncaught TypeError: weightField[0] is undefined
    onDrop https://drupaleleven.ddev.site/sites/default/files/js/js_BNQJD_M5xSLVCGCxuBjnXzqPB9fCLrJ0uR16XAnhZPE.js?scope=footer&delta=0&language&theme=claro&include=eJx9UVtywyAMvJAfZ-hJMgJUhwQjKolM09NHtsM0djr9AbQSK2nXE-N4-arI906p8rgcnV_QwLVAGgrTxCiygQrOgUu4RYkgXGRXHtBRzX4pyIrfWiG11C_Sp5iv0sldFOfRgVh5AqbRA4cGQ5hj3rgz8Qwp_rSyKZEzFtG7EU27_uA13nBtsJ8rSkngcQfqssoZISB3LpG_tsQabKXRhuZs2KbSqca9Ek98kHOc_yAZXtZ47WqSFspis77nAsN-qcBUXFWl_BTgiWe49fbDlDwTq6_aEi02Tyk5WGxd72HGXN9AyBr7zxT91XQ4JLsqyI12eQ_RfJTj0M58mCHDhPy_8432OAOKh4Ifq1guTqcSC47t8QBocQXW:378

b) added the string "tabs" to the filter field
identical behavior like in 1b) but the same error like in 2a)

3) Edge
a) without anything added to the filter field:
Same behavior like in 1a) but again another slightly different type of error

Uncaught TypeError: Cannot read properties of undefined (reading 'className') Js_BNOID_SC4780BocOW: 378

b) added the string "tabs" to the filter field
Same behavior like in 1b) but the same error like in 3a)

Not sure if it would help to paste the full console output of the typerrors.

Hello folks, the last issue( unit test here → ) that I found fixed. I attached a video testing in Edge browser with all issues mentioned above not happening.
I am also adding the patch with all the changes.

Thanks so much @rkoller and @smustgrave for the tests.

Best.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-09-22 Fixed . That issue has a link to the recording.

Thanks for working on this feature. It will be a big help for sites that have a lot of blocks.

We found that the filter worked well if we wanted to find a block and configure it, or add another block in the same region. However, there are several problems with rearranging blocks. For example:

1. Regions with no blocks shown are completely hidden, so we cannot move a block to such a region using drag-and-drop.
2. If we move a block to one of those regions using the select list, then the region is still hidden.
3. If some blocks in a region are hidden, then there is no reliable way to move a block within the region. In fact, if there are 3 blocks showing, then I can get different results by dragging the bottom one to the middle (then saving) or by dragging it to the top and then to the middle (and saving).
4. There are also some accessibility (a11y) issues that came up. I think that @rkoller plans to comment on those.

We have some recommendations and a suggestion.

1. Recommendation: add a "clear" widget to the filter, probably a link with an X icon. (Not related to the points above.)
2. Recommendation: never hide the regions. This should help with (1) and (2) above.
3. Suggestion: add a control (checkbox?) for each region to show all blocks within that region, overriding the filter. This should help with (3) above.

If you follow the third suggestion, then there are several decisions to be made. Should the control be visible when the filter is empty? Do we need a way to clear all these controls? Assuming a checkbox, how should it be labeled: perhaps "Show all" or "Show all blocks in this region". Come up with some help text (description) for the filter, mentioning the override.

Some other ideas came up at the meeting for making it easier to reorder blocks. Perhaps the filter should "float", so that it is always visible. If we also implement the first recommendation, then the user can scroll to the desired region and clear the filter. If the page can scroll to the right place when the filter is cleared, then that would help. Or maybe make it so that clicking on a block selects that row, and then scroll to the selected block when clearing the filter.

Of course, there may be other solutions to the problem, That is why we make it a suggestion, not a recommendation.

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

One initial disclaimer. During the usability meeting 📌 Drupal Usability Meeting 2023-09-22 Fixed we've looked at a test site that had applied the latest patch from this issue as well as the patch from 🐛 Javascript breaking on block layout page after drag or select new region RTBC . Reason for applying both patches, I was under the impression from previous tests, that it was mandatory for the block layout filter patch to function correctly. Therefore point 2 from Benjis list ("If we move a block to one of those regions using the select list, then the region is still hidden.") isn't entirely applicable anymore as demonstrated in #61 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work . @joaopauloc.dev explained later on that he included the fix from the other issue in this issues patch as well now.

In the following a few additions to the points @benjifisher mentioned in relation to suggestions and accessibility plus one or two more points I've ran into while testing.

1. In the context of the second recommendation never hide the regions. This should help with (1) and (2) above. one suggestion that was voiced during the meeting is to provide some sort of filter status for each of the regions. Something like:

x blocks hidden. (for example 4 blocks hidden)
no blocks hidden
or
x blocks filtered (for example 4 blocks filtered)
No blocks filtered

So the user would be provided with some information about each region which is in particular useful if the suggestion of the checkbox/button to show all blocks for each region is picked up.

2. If you are using the filter functionality with a screenreader there is no aural feedback about the filtering results. I've added a short video (see search_filter.mp4) illustrating the problem using VoiceOver on MacOS Ventura.

3. If you keep the filtering for the string "menu" and drag the Main navigation block up past the Primary menu heading until it sticks then the region in the select field changes to Header but there is no heading called Header. The block stands for its own without any heading.

4. If you drag a block with the drag handle you get a * that it's position got altered but if you change the region via the select field the * character is not being added.
(*point was not discussed during the usability meeting, noticed afterwards)

5. no matter if you filter or go through the full list.
- switch to the row weights view.
- change for example Primary admin actions from the Highlighted to the Hero (full width) region via the select field.
=> the block is correctly moved to the Hero (full width)-region
- now alter the weight value for for example the Primary tabs block also located in the Highlighted-region
=> the block remains in it's position, you have to click the save button. I
=> It is sort of confusing that one interface element causes and immediate visual effect while the other has no effect at all and you have to very same form first?
(*point was not discussed during the usability meeting, noticed afterwards)

Completely out of scope for this issue but for the sake of completeness and reference two mainly accessibility related points that were touched as well during the meeting:

A) The table drag icon has arrows pointing to all four directions (up, down, left, and right) which is creating the assumption the block could be dragged and positioned in all four directions. Problem is in the context of the block layout pages the user is only able to move blocks up and down - the block layout page is not hierarchical like for example a menu or taxonomy. On mouse over the mouse cursor also becomes a table drag pointing to all four directions. It would be preferable to only show and highlight the directions the user is able to drag elements to. @simohell already filed an issue for: ✨ Differentiate visually dragging with and without hierarchy Needs work

B) The aural interface for the configure- and drop-buttons are sort of redundant and in lack of context (slighty worse in case weights are hidden, but that isn't relevant for screenreader users) . That is most apparent if you got used to the general functionality and purpose of the page and now you try to quickly navigate directly via for example the Rotor in VoiceOver. There are many redundant and hard to distinguish entries:

Hey folks, thanks for the comments.

Regarding the suggestions on #62.

1. I added the clear widget to clear
2. In my first approach I didn't hide the regions, but I felt a little confused about finding the block that I just searched for, because there was a little problem with keeping all regions displayed, if the block that I searched displayed on the bottom, the feature to filter the blocks doesn't make much sense, because I still not seeing the block. But okay, I agree that hidden regions cause more confusion to drag blocks or change their position. So, I back the code to display the regions but I added something to help us reach the blocks that we are searching for, Below the input filter I added a link for the user to click and scroll to the first region where a block was found. With this feature, it makes it easier to find a block that we are searching on the bottom page., what do you think about this?
3. I didn't add the checkbox but would like to suggest that we use a button with an eye icon to control the visibility of the blocks by region that overrides the filter param. Also, besides the eye icon, there is a link for the user to go back to the filter. What do you think?

Regarding the suggestions on #63.
2: I'll work on that.
3: fixed.
4: I could reproduce this issue on a clear d11 side, so I think is not related or is a side effect of this issue.
5) I have to check that.
A) I fixed the table drag icon in this issue, I just forgot about this comment mentioning that there is another issue.
b) I have to check that.

Clear widget and the link below to go to the next region.

The button/eye icon to control the visibility of the blocks by region.

Waiting for comments regarding the changes and I'll work on the unit test for the new changes.
thanks

At first thanks for pushing up the initial preview and all the work on it! I will use the references used in #65 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work :

#62-1 In general the clear filter field pattern looks good. And it is a good thing that it is consistent with other places in the admin ui where it is used. I've searched cuz i wasn't consciously aware if such a pattern already existed but found it for example on admin/structure/views and /admin/config/search/path. The only two details found in that context apply to everywhere in Core and therefore these points i've noticed might be suitable for a follow up?
a) The button label used for the clear filter field button is Cancel button which i consider sort of "unprecise" and unclear. Something like Clear filter-button might be more descriptive. With cancel i wouldn't exactly know what i am actually "canceling".
b) Markup-wise <div pseudo="-webkit-search-cancel-button" aria-label="cancel" role="button"></div> is used in the shadow content for the input element in Safari . that means the clear filter button has a browser specific look and is also potentially not available in every browser. In Microsoft Edge the button looks different and in Firefox the Clear filter button is not available at all for example. Would it make sense to provide a dedicated button element for the close button? That way it would be available in every browser plus the styling could be consistent across browsers as well? In regards of the technical implementation I found an interesting article: https://www.scottohara.me/blog/2022/02/19/custom-clear-buttons.html . But as i initially said completely out of the scope for this issue. And the state the patch currently is in in the context of the added clear filter button looks totally fine for me.

#62-2 I agree with you if you search on a mobile device for for example Powered by Drupal the only match is in the Footer Bottom region which is way underneath the fold. Definitely a downside. I think in the usability meeting we ideated that the first match should automatically get into focus. But by adding such a link the user is more in control and the moving to the results would be a deliberate choice. but on the other hand i am not sure if the scrolling poses a visual challenge and trigger for some groups of people. I've asked @mikegifford about that detail and will add his reply later.
But in general i like having all the available block regions shown all the time. it provides some visual anchor and an outline (and the users also don't have to remember all the available block regions in particular in case of a small working memory). But the list of regions on a results page looks unsteady. block regions with no blocks in the region have a dedicated section in the height of a block element. while block regions that have blocks hidden have no such fixed height component instead a line is added with the number of filtered items and the change filter link. Plus the "place block" and the "x filtered/change filter" line are quite close together. Might be a potential problem in regards of the touch target size (SC 2.5.5 - https://www.w3.org/WAI/WCAG21/Understanding/target-size.html) as well.
One idea to make the list less unsteady. for block regions that have all blocks filtered out add a fixed heigh block component like for block regions with no blocks in the region and add "x blocks filtered" and the change filter link there. In regards of the show and hide filtered results i move the answer the next point.

#62-3 i agree that checkboxes might be ambiguous in the context of a toggle button. maybe use the aria-pressed attribute to provide some context and clarity about the state and use a button element. in regards of the "jump back to the filter" field link it is the same like for the "jump from the filter" field to the first result so i would wait for the feedback from mike.

And in general i think it might be a good idea to briefly revisit the issue in the next usability meeting to discuss based the new prototype.

#63-4 i agree better do this in a follow up issue.
#63-A i like the icon. is that vertical drag handle icon as well as the eye icon already used anywhere else in Core or would it need some design feedback?

Thanks for the feedback @rkoller, appreciate that.

#62-1-a: Agreed, I'll fix it.

#62-1-b: Agreed, also when I was testing the clear button on other pages, I noticed that the button clears the text on the input, but does not trigger the filter, so the input is cleaned but doesn't clear the results. Maybe we should open an issue to fix that together with button style.

#62-2: I think I didn't understand well, your suggestion to add the eye button and the link to filter in another row only when there are no blocks in that region? or move these two buttons to another row having or not having blocks in that region? if yes, I think is a good idea, I can change that. But if we add the new row below the region with a button only if there are no blocks can be confused I think.

#62-3: Got it, I'll fix it.

#63-A: No, all drag-and-drop table that knows in Drupal admin use the same icon, I got this icon from CSS, when we set the mouse cursor to row-resize. But I think we should remove this style from the changes of this issue and move to this one ✨ Differentiate visually dragging with and without hierarchy Needs work , also the @simohell provided some icons to different drag in this issue that we can use.

I'm waiting for new comments after the meeting that you guys will discuss this issue.
Thanks in advance.

#62-1 yes i agree think all should better be done in a follow-up issue.

#62-2 only a rough mockup. i just chopped it together in devtools. the button label is just a placeholder and the button could also have the icon in it.

but the the mockup is more about the general idea of keeping the consistent vertical row height by using a block component like block regions that have no blocks to filter instead of extending the height of the block region row with the "filtered change filter" line. that way there is a separation of concerns. in the block region header row you have the controls like place block and show/hide filters while the row underneath contains just information. either no blocks to filter available. or x number of blocks filtered. that lowers the cognitive load and lowers the amount of distraction.

and i wonder instead of having a "change filter" link on each block region row which is sort of redundant would it make sense to perhaps have a single button at the bottom right corner of the screen instead? or is the going back to the filter field link necessary at all?

#63-A +1 for moving the work on the icon to the issue @simohell opened

#62-2: totally agree, I'll work on that.
Thanks.

@rkoller re:

but on the other hand i am not sure if the scrolling poses a visual challenge and trigger for some groups of people.

All smooth-scrolling poses a trigger for me. The code needs to check for prefers-reduced-motion and just jump to the location rather than smooth-scrolling if it is set to reduce.

at first thanks a lot @charles-belov for taking the time knowing that the experience testing might be potentially triggering for you. one question about your preference in general. instead of the usage of a prefers-reduced-motion: reduce media query that switches from scrolling to directly jumping you would prefer a dedicated setting for animations/motions for the page (like https://holohalo.net has a toggle switch in the upper right corner - but warning it is an opt-out animations toggle button, per default there is an animation running steadily) or for the admin ui in general? Because based on caniuse the prefers-reduced-motion support is pretty good across browser at ~95%. Are browser not reliable in that regard so that a dedicated setting is preferable over a media query based solution?

We have briefly revisited and discussed this issue at 📌 Drupal Usability Meeting 2023-10-06 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at today's usability meeting were @AaronMcHale, @emma-horrell, @benjifisher, @rkoller, @simohell, and @worldlinemine.

I've demonstrated the latest changes introduced to MR4687. We have discussed two aspects, for one the newly introduced scrolling functionality and then the visual presentation of the status information - in case either no blocks are added or if block are filtered out.

There was a consensus that it is the better choice to move the scrolling / "move through the page" functionality to a follow-up issue. This issue is about filtering and not about the moving through the page. At this point it is difficult to make assumptions and cover every use case from the smallest site with a real small number of block regions and blocks up to a real complex large site with many block regions and even more blocks. In combination with the insights and confirmation @charles-belov provided in #70 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work it might be the more sensible choice to observe the feedback after the issue got in and then make an educated choice which direction to take based on the feedback. One of the options might be the approach @charles-belov outlined. Another option that was brought up during the meeting might be, instead of providing a "jump to" functionality and to complicate things further, to let the filter field behave similar to the bulk actions footer bar on /admin/content. But instead of being positioned at the bottom have it positioned fixed, staying at the top of the page. That way sighted users would always have the filter field in reach no matter at what position on the block layout page they are and would be able to make adjustments to the filter string. That way the "jump to" functionality might not be necessary at all?

In the context of:

there was a consensus that instead of using the term filtered to use the term hidden instead.

In regards how to arrange the different components the only clear consensus was to move the filtered/change filter line for the block region rows. By moving the "change filter" to a followup the remaining question how to handle the information about filtered blocks with it's hide and show functionality.

One suggestion was to move the information next to the block region title to prevent that the block regions and their info blocks don't stack up too much vertically so less scrolling is required in the first place. Another plus it would be clearly communicated if and how many blocks are filtered for a block region.(*post meeting note that reflects only my personal view: that you are able to show and hide the filtered blocks by clicking the "x filtered" is a detail i forgot and missed to demonstrated during the meeting, but that might be relevant here. you would have the block region label, then an information about the number of hidden blocks that is at the same time a functional button showing and hiding those blocks and then a button to place a block).
The other option would be the pattern described in #68 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work . That way function/control and information would be clearly separated even if it takes up more vertical space that way. Sighted users can easily digest the information at hand. Downside is that the information row might be unnoticed in case the screenreader user is only going through focusable / interactable elements. I've created a short video stepping through the current state of the interface sequentially with VoiceOver by pressing VO-arrow right (see filtered.mp4).

Hello folks, I implemented more details about the suggestions/comments that you discussed.

First of all, after the last update you gonna see that the table drag icon added in the previous changes was removed since we have a proper issue to fix that and I also work there ✨ Differentiate visually dragging with and without hierarchy Needs work .

Secondly, I implemented the layout proposed by @rkoller on suggestion #62-2. This layout is much better than the first one that I proposed. Take a look at the image below.

Regarding the feature to jump to. I removed the link(change filter) that goes to the filter and I followed the suggestion that you guys mentioned

let behave similar to the bulk actions footer bar on /admin/content

. But I have just a concern about the filter block feature. I think the main proposal of this issue, as I understood, is to make a way to find a block on this page easily. Since we started to not hide the regions that do not have visible blocks, my feeling is that it might still pose a slight challenge. What do you think? The jump to functionally makes things easy, I think. That's why I kept the jump to working together with the new filter behavior. I'll wait for any feedback about it. If we want to remove this feature, we could discuss another easier way to find a block on this page.

Just one question about the new button to show/hide blocks on the region, if the filter is empty. How could this button work? Does it make sense to work alone or we can, for example, add a disabled style or even not display it when we are not filtering?

Best.

@rkoller Thank you for your detailed ask.

My preference is that sites take me at my word that I don't want animations and only show animations that I have explicitly requested, preferably by explicitly toggling a switch from not-animate to animate or by clicking a play control.

So, if you do have a toggle switch on the page, it would default to animate if I don't have prefers-reduced-motion set to reduce, but default to not animate if I do have prefers-reduced-motion set to reduce. And that would be the behavior I would advocate for Drupal core and contributions to follow.

Always take my stated preference as the default for my visit, please, because I am counting on websites to respect my system-wide request. Having to look for an additional setting in order to be free of unrequested animations places a barrier to my interacting with a website in a safe manner.

As a side note, the example site you provided (https://holohalo.net), is not automatically animating for me in Firefox or Safari (and that is true for Safari whether I have System Settings, Accessibility, Display, Auto-play animated images turned on or off). It is animating for me in Chrome, and the labels on the toggle switch appear to be backward, that is, off is on the left but to turn the animation off I need to move the switch to the right; again, if I have prefers-reduced-motion set to reduce, the proper behavior would be to default to off and let me decide if I want to turn it on. That said, it is in an obvious, easy to reach, location, as long as I'm using a pointing device and not keyboard-only.

@rkoller Support looks pretty solid here - https://caniuse.com/?search=prefers-reduced-motion

@Charles Belov I like this suggestion:

If there is a toggle switch on the page, it would default to a more static view if the user/browser has prefers-reduced-motion is set to reduce

@media (prefers-reduced-motion: reduce) {
  /* styles to apply if a user's device settings are set to reduced motion */ }

but default to animate if the user/browser has prefers-reduced-motion set to reduce.

I don't see why we don't formalize support for this in Core and add it to https://www.drupal.org/docs/develop/standards/accessibility-coding-stand... →

re #73 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work
apologies for the belated reply and thanks for all the changes @joaapauloc.dev. finally found some time to test your latest changes. a few observation and answers:.

First of all, after the last update you gonna see that the table drag icon added in the previous changes was removed since we have a proper issue to fix that and I also work there.

excellent thank you!

Just one question about the new button to show/hide blocks on the region, if the filter is empty. How could this button work? Does it make sense to work alone or we can, for example, add a disabled style or even not display it when we are not filtering?

i would suggest the following behavior. with nothing entered in the filter field the show/hide button is currently shown but i wouldn't show the button for any of the block regions there at all.
as soon as a string is entered in the filter field i would only show the show/hide button for block regions that have actually filtered and hidden blocks. for block regions with the status no blocks in this region i wouldnt show the button either. show the buttons only on block regions where the buttons have an actual function to show and unhide filtered blocks. in all the other occasions the buttons are none-functional and shouldnt be available/shown.

and about those buttons. currently they are not reachable via the keyboard neither by tabbing nor visible in the rotor under links section like the place block buttons. therefore i was unable to test in regards if the state and state change is announced correctly. but probably the aria-pressed attribute might be a good choice.

in regards of providing the information how many blocks are filtered for a region or if there arent any blocks in a region i've talked with @mgifford he suggested that using something like aria-labelledby might be a viable choice to provide the information placed in one table cell as additional information for another cell. that way sighted users would see the information structured like it is at the moment with the latest changes while screenreader users would get the announcement like "Header 1 filtered this region" . i have only tried manually via the devtools and aria-labelledby just replace the block region name with the status. but i am not a developer and probably did something wrong. or maybe providing the additional information works in that case with aria-describedby. not sure.

let behave similar to the bulk actions footer bar on /admin/content

hm i am not completely sold on neither of the two. i am not sure if having the filter field set behave similar to the bulk actions is a good thing nor if having a scroll/jump link.

my uncertainty in regards of the filter behaving like the bulk actions might be due to the current implementation. if you compare bulk action with the block layout, bulk action have the bulk action bar stick right at the bottom of the page while when you scroll down the table header is sticking right underneath the admin toolbar also in a fixed position like the bulk action bar at the bottom.

in comparison in block layout for a while (during my first testing) the filter component had some padding between the toolbar and the upper border of the filter component . but right now when i retest the filter component sticks right underneath the toolbar which is good. the only problems compared to the bulk actions are for one that the table headers (block, category, region and operation) scroll with the content and therefore scroll outside the visible viewport. one idea might be to attach that table header to the filter component so it becomes one fixed block of components on top of the page? and that table header might provide some color contrast to the main content underneath. cuz the filter component has a white background color and so has the table underneath. on the content page the bulk operations are black and the table header background is greyish. and another point the filter component has a bigger height. you have the label then the field and then the got to link. and another point as soon as the filter switches to the fixed position it gets extended to the right border of the screen, on the bulk actions both the bulk action as well as the table header keep the maximum width of the table.

i am not completely against the "let the filter behave like bulk actions" nor am i against the "go to content". each might be useful. i haven't come to a final conclusion. but in particular the filter component behavior feels a bit odd at the moment but might work out fine with some polishing.

in regards of the go to items found link. you dont have to necessarily remove the scrolling. with the media query @mikegifford posted in #75 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work there could be progressive enhancement. the standard behavior would be the jump while people that dont have reduced motion switched on for their devices would get a smooth scrolling. the scrolling would be defined within the meta query. and one detail i struggle visually with the go to items found solution, i have no visual cue were the first match actually is. the page jumps or scrolls but then i have to still visually orient what is the block region the link is pointing to. would some color highlighting be helpful?

and one technical observation the behavior illustrated here https://www.drupal.org/files/issues/2023-09-15/firefox.mp4 → is back. i again run into TypeError: undefined is not an object (evaluating 'weightField[0].className')

re #74 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work thank you so much for the detailed explanation and the outlining of your preferences and train of thought behind. super helpful!

as you can see @mikgifford has already updated the a11y coding standards as mentioned #75 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work and he also already created an issue for adding an accessibility preferences page to the user profile that can be found at ✨ Add a section to the user profile to store accessibility preferences Active . Please chime in if you have any ideas and suggestions.

and i completely agree about the example page. the sole reason i brought it up was that it was the only example for a page that uses such a toggle i am aware of. implementation wise it is not the best example. too many downsides and odd behaviors as you lined out. i think such a toggle works if you have the need to provide a toggle for a single page with animations like in case of that startpage example but as soon as you have something like the drupal core and contrib where you can have more than one place animation might take place i think having a centralized place for setting the users preferences like suggested in the linked issue is a good thing.

Hello folks, follow some updates.

1: The button on the regions to show/hide all blocks on the region was updated to appear only after any filter was type, also appears only if the region has block filtered.

2: The width of the fieldset input filter getting the entire screen when the user scrolls the page was fixed.

3: The table header sticks below the input filter when the user scrolls the page.

4: The button to hide/show the blocks can also be reached by tab.

5: Finally, when the user clicks on Go to items found. the blocks that match with the filter applied get highlighted by a background color-success, the same behavior when we add a new block on the page.

Hello, @rkoller regarding the issue that you mentioned that is back. I couldn't reproduce it.
Follow the new button behavior.

Also, the new Go to items found. with rows highlighted.

There are a few issues to be fixed but regarding the issues that you mentioned, I think we got some progress.

Thanks.

I completely agree with #79 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work , that is definitely progress. And the issue i was referring to that slipped back in were the odd behaviors with dragging (see the video from #55 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work ) but with the latest commits it is working again properly. A few comments in the context of the latest changes:

1. one question: search for the string menu for olivero. in the primary menu block region you have one block called "main navigation". for the header block region all blocks hidden. now try the following

• drag the main navigation block into the header block region by the drag handle.
• dont save just reload the page and search again for menu
• instead of using the drag handle change the region in the select field for the main navigation block from primary menu to header
• all of a sudden in contrast to when you drag the block the whole header region gets expanded and the hidden blocks are being shown as well.

=> i would try to keep things consistent between both ordering cases. i have to admit i dont like if a system does things pro actively like expanding a list. and with a high number of blocks it can be visually overwhelming if someone is unprepared. but on the other hand if you move block regions with a block it is probably required aside moving the block between regions also to readjust the position within the region so the auto expanding would save a click. but on the other hand if you drag a block from primary menu down to sidebar each block region would expand while the block hovers over it. might feel unsteady and overwhelming. I am not sure which approach would be the preferable one. What do others think?

2. one other detail in the context of reordering blocks. the status row for block regions that have hidden filtered out blocks behaves like a regular block just without the option to drag it, but you are able to move blocks within that block region above and underneath that status row:

i think those status rows should always be right after to the block region row they describe.

3. one idea. with the go to filter results link the blocks in question are visually hightlighted. would it make sense for the case of you expanding a block region to visually highlight and label which of the blocks are filter matches? for a theme that has more or less only the standard blocks it might work without any labeling but if you have 20 or 40 blocks things could become difficult to have an overview.

4. I definitely like the styling of the filter box as well it's behavior when the filter box attaches to the table header when you scroll down the filtered block layout list. the changes look really good. the only detail that is still nagging me is that the filter box feels prominent through its height due to the label the field and the go to link. but that is more of a design question. and in regards of the "go to items found" link you are able to click it several times. and each time the browser scrolls/jumps.

Thanks for the quick feedback @rkoller.

#80 1: Totally agree, both methods to move the block must have the same behavior. This was a side effect of the last changes but will be fix on the next commit. Both blocks moved when dropped into the new region will open all blocks filtered if have, this was our last behavior until the changes. I'll wait for new comments if we need to change this behavior as your comment about the negatives and positives regarding this behavior.

#80 2: This change will be a difficult one because the instance of the table drag of this page is handled by another javascript file that is different of the filter page. Drupal table drag does not provide custom events to make this change easy. But I'll try to change this. I agree that the result message filter working as a draggable item is quite strange.

#80 3: Nice suggestions, but I have one question. In my last change, I added this highlight into the rows when the user clicks on the link to go to the element. I think we could add these highlight rows when the user types anything on the filter, no matter if the user clicks on the link or opens all blocks on the region. What do you think?

#80 4: Before those last changes, the height of the fieldset was higher than all other fields that we have this kind of filter, for example, the filter element that we have on the modules page, but now, the height is the same. I think we could follow this height in every filter. However, I noticed that the distance of the filter to the table is larger than the other filters. I'll fix that. Regarding the behavior of clicking many times on the link, I'll fix that too.

One more time, thank you so much for the great feedback and suggestions @rkoller, appreciate that. In the next few days, I'll commit all those changes above and let you know.

Thanks.

Hello, a quick update of my last comment #81 regarding the #80 2 item.

I could implement the same behavior when we are dragging an item and the next or previous item is a region name. Now the drag item jumps the "filtered count items" message too.

But, I didn't enjoy the usability of this feature, as we already jumped the region header, jumping two rows makes the usability a little weird.
As I mentioned before, I agree that does not make sense for the row that displays the filtered items "be draggable". But now, after I implemented and used the drag feature the experience was not good. This got worse when we needed to move the row to the top or bottom that had not been displayed, was definitely a bad experience. But this is my opinion, I'll appreciate any feedback.

Now, regarding the issue above, I would like to suggest another option to display how many blocks we have filtered or not.
Here is the layout that I thought could be useful to show the blocks hidden or hide all blocks on the region. In this option, I think we kept the current experience of dragging the blocks and also display the filtered information needed.

What do you guys think?

#81.1 With the distance of a few days revisiting from my personal perspective i consider it sort of convenient if there are only one or two blocks hidden in a block region and those get auto unhidden when a new block is moved into the block region. but if you have a few more the amount of auto unhidden block might be overwhelming as illustrated in many_filtered_blocks.mp4 where 17 filtered blocks get auto unhidden. another detail to note for that example the actual block moved into the block region remains beneath the fold that way and you have manually scroll down to find it again again.
even if it is one extra click i sort of lean towards making the unhide the filter a deliberate choice so the person has to actually click. but the auto-unhide could still be introduced after the feature is in and the broader feedback of users is it would be desirable to have the block regions auto-unhide. but for now i would vote to make it a deliberate step. i also got a feedback from @worldlinemine a few days ago, his reply was:

Hm… I just thought about this again and I agree it should be consistent. I don’t see added value with it auto-unhiding so my preferred behavior would be for it to behave similar to drag and drop.

#81.3 so you basically mean to visually highlight the filter results all the time as soon as a filter term is entered to the filter field? in general a good idea. but we have to mindful about one or better two details. for one WCAG SC 1.4.1 https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html. we probably would need to come up with a second way how to label block rows and communicate what a filter result is. cuz at the moment there are two colors used, green for filter results and yellow for blocks with an altered position. for someone being color blind that might be hard to distinguish? and the second question about how those states communicated by color are communicated to screenreader users. that would be the other question. that question already applies to the current state i just forgot raise it.

the following two i already replied to on slack but thought about them a little more and let it sink in.

#82.1 strictly speaking it already looks odd if you drag a block into another block region past the block region header row. any dragging of a block would actually look odd as well but the point is that regular block rows have a consistent layout that way only the label for the block, the category and the region label differs. position wise and component wise they are identical without any shift of layout. but in contrast the difference to a block region row and the difference to a block region and status row combo have a significant visual difference. personally i don't consider the behavior illustrated in the animated gif bad. the status row needs the close proximity to the block region row. and having the status row as a row within a block region where blocks can be dragged above and underneath i consider problematic and potentially confusing. and the more blocks are moved in between a block region row and the status row the more difficult it becomes making the connection between the two or even finding the status row in the first place.

#82.2 in the second screenshot you’ve added the number of filtered blocks to the block label but the status row for that block region is also shown still. i suppose the status row with the block label showing the number of filtered blocks in place would be removed. that step would have two downsides.
having block region rows next to each other might look way more stacked and overwhelming. those status rows in between provided some sort of extra visual separation from my point of view and give the layout some “room to breath”.
on the other hand adding more information to the button label makes the label even longer. the ideal goal should be not more than two or three words, ideally a single word. before the button label was just about the function of hiding and showing now information would be added as well about the number of filtered blocks. in addition having numbers in parenthesis makes the label harder to read and process.
Revisiting the screenshot after a few days i am still not sure if moving the information into the button label is a good idea. i am worried that the cognitive load might be too much. but that is my personal experience. i think i still tend to a clear separation of concerns with a toggle button about showing and hiding filter results and a status bar underneath. that information would be opt in a way. you "could" scan it or you just press show or hide filter results. but still would be good to get other opinions on that as well as all the other open points.

One other minor detail i've noticed while revisiting the issue. if you enter for example menu the link underneath the filter field says Go to items found.. If you instead search for cdfg the "link" underneath the filter field states There are no blocks matching the filter conditions..
Visually there is no indication that the first is an actual link directing you to the first matches while the other doesn't do anything. but on mouseover you still get the pointer mouse icon for both of them. when taking a look at the markup both are a paragraph tag with the same css class for styling. would it make sense to adjust the markup as well as the styling? for the former an actual link that is also styled as a link while the latter could be kept as a paragraph element but styled slightly different just as informational text with no change of the mouse cursor on hover?

Gauravvvv → made their first commit to this issue’s fork.

Hello, @rkoller.

I agree with your first topic. I updated the implementation to not display all blocks on the region where we drop a block or change the block region by using the select.

The second one about the highlights I didn't change anything, in the next few days I'm gonna check that.

The third one. I used the drag again jumping the row filter status, and feels good. I agree with you that dragging a block between the header and the filter status is confusing. So, we can forget about my suggestion on #82.

Last but not least, I fixed the message below the filter input when we didn't have blocks on the filter criteria.

Follow a quick demonstration of the changes.

The overall direction looks good. Aside the list of open issues i've drafted over in the conversation on Slack (will update the issue summary after your review and combine it with the points about the current patch after you'Ve reviewed that as well)

1. If you search for content block for olivero and you have disabled blocks that are matches, those disabled blocks dont have a green background color.

for one i was unable to find the exact hex color for the greenish font color but it sort of looks too light and might miss the required 4.5:1 color contrast. but on the other hand it looks like the disabled blocks are sort of secondary matches. but shouldnt the search be about the actual string you are filtering for and it should highlight enabled and disabled the same way? you want to identify the matches more easily and then drag one ore more of those matches.

2. show filtered button. it is good with aria pressed but on the other hand having the same label but having at the time a changing button icon is confusing. one time it is called show filtered with a closed eye then show filtered with an open eye. and the button itself has not dedicated "pressed" styling. for screenreader users the current approach is clear but for sighted users it might be a source of confusion? i think it might be good to ping @ckrina over on slack and get some feedback?

3. Also in the context of design feedback it might be good to get some input about the styling of the "go to items" link. Should it be a link or should it be an action button? The only problem i see with the current implementation is that the link has a very small font size and the touch target might also be too small?

4. The micro copy of the status line " 1 filtered this region". Would it make sense to add what is actually filtered? At the moment it reads like something is missing. Something like "1 block filtered" or "1 block hidden" , that way it would be more concise and streamlined. and that the context of that status line is the block region is probably apparent?

Thanks again @rkoller for the feedback.

#86 - 1. Working on that.

#86 - 2. Make sense, i'm gonna search for a button on drupal that has this style as "pressed" and add this style on the button.

#86 - 3. I'll try to increase the font and add here the style and we can check which size is better.

#86 - 4. Agreed, i think 1 block filtered sounds better than 1 block hidden since we are filtering the blocks. What do you think?

#86.1 nice!

#86.2 there is the active state (pressed) if you take a look at https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/💧-Drupal-Design-system?type=design&node-id=553-0&mode=design&t=ak4Zy2SB9fVpigo0-0 on the buttons page in the upper left in the states section.

#86.3 +1

#86.4 i agree filtered is probably the better fit and consistent with the button label that way.

I've taken initial step of the creating a first draft of remaining steps for this issue. I've added all issues from #62 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work on that are either fixed, need work or need a follow up issue. Feel free to update and oversights, mistakes or anything missing. Thanks

@ckrina at first a short screencast illustrating the filter functionality. see current.mp4. There are two details that could definitely need some design input, but in case you notice anything else in the video please raise that as well.

A) Go to items found. link

As soon as you enter something in the filter field a link is shown right underneath the field, see:

The potential problems:

• Probably a too small font-size and touch-target
• The filter component is visually too dominant -> the filter label, the filter field and the Go to items found link are stacked vertically onto each other. While for bulk actions on the node list page you have number of selected nodes, the select field label, the select field and the apply to selected items button aligned horizontally inline (see the next screenshot).

The questions:

1. Should the Go to items found link remain a link or should it restyled as an action link button? And depending on the recommended choice what would be the preferred way of styling?
2. Should the filter more orient towards the bulk actions in regards of styling? Moving away from vertically stacking the three elements (the filter label, the filter field and the “go to items found” link) and display them inline horizontally inline like the bulk actions component does? At the moment the filter box has just a larger height compared to bulk actions taking away visual screen space in particular on mobile devices.

B) Show filtered-button

All blocks that don’t match the string entered in the filter field are getting hidden. With the Show filtered-button the user is able to show and hide the none-matches. Since toggle buttons with labels opposite of the current state are potentially confusing according to Leonie Watson: https://www.youtube.com/watch?v=OUDV1gqs9GA&t=3221s the toggle button is using the aria-pressed attribute and the same button label “Show filtered”.

For screen reader users:

Button not pressed:
Show filtered toggle button

Button pressed:
Show filtered selected toggle button

For sighted users:

Button not pressed:

Button pressed:

The problems:

• For screen reader users the current aural interface is crystal clear
• In contrast for sighted users it is ambiguous instead. Having the same button label while the icon changes is confusing
• The pressed state isn’t reflected by the toggle button visually

The questions:

1. Would it be legitimate to use the active state defined in the Drupal Design System for the pressed button (not only when the mouse button is pressed)?
2. Or should we go with the recommendation you’ve made on #2293803-245: Replace confirm password element with a new password element with show/hide functionality → to use action links with the icon and button label switching - which would have the downside it would become ambiguous for screen reader users again?

A) Go to items found. link

I'm not sure it's a really standard and easy to understand pattern, but on a design perspective I'd do the following:

1. Should the Go to items found link remain a link or should it restyled as an action link button?
It should be a link, but styled as an action link.

2. Should the filter more orient towards the bulk actions in regards of styling?
I'd say yes, it should stay in the same horizontal space if there's room.

Test with it applied (the small variation of an Action link):

B) Show filtered-button
For this I don't have a super strong opinion. I've done this 3 tests:

1. With an Action link:
   
2. With the Checkbox:
   
3. With a Toggle:
   

On a visual perspective I'd recommend the first one (with the Action link) because it sets a visual hierarchy with the button next to it, but I don't want to make life harder to some users if there is no way to make it better for screen reader. I think the checkbox also works, and the least I like is the checkbox.

Hello folks, I updated the feature implementing the suggestions above.

A) I moved the link to go to the items found to the right of the input element as in the image above.
B) I implemented the new Show filtered button following the first example on B first image.

Follow the image below as an example of the changes.

Thanks for the feedback and the suggestions.

@joaopauloc.dev thanks for carrying this forward

Have not re-tested but javascript tests appear to be failing.

Hello @rkoller and @ckrina.
I have one question about the new design of the input filter and go-to elements.
We also have the case when the user types something that there is no result and we display a message like

There are no blocks matching the filter conditions.

Should we move this message to the left as the link to go to the element was? like the image below.

re #92 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work
A) i completely agree. and in regards of the unusual pattern. if i remember correctly the consensus was to go with the current form and make adjustments in a followup. but i think i will gather some feedback from a few user groups i regularly attend to.

B) i would vote for the first one as well. the only downside is the problem with the switching icon with this one. @ckrina should i open up a follow up issue about developing a new button state? i could summarize the points we've discussed over here: https://drupal.slack.com/archives/C1AFW2ZPD/p1704456082112179?thread_ts=... i think there are quite a few places in the admin ui that could benefit from that kind of "pressed" button state, and it would solve the switching label and/or icon problem for toggle buttons.

re #93 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work
about A: I've noticed two details:

• the "go to items found" element is excluded from the tab order, it is not keyboard accessible.
• #92 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work used an arrow pointing down, in your variant you are using a chevron pointing down. The problem with the chevron, having a text label flanked with such a chevron creates the association of a select field and not a skip link.

about B:

• there is currently a regression. i am not entirely sure but i think it got introduce somewhere after it was first fixed in #78 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work . at the moment if nothing is entered in the filter field the show filtered button is shown for each and every region.
• the only problem i have with the current styling is that you have a fixed label now while the icon is changing. so having a striked through eye with the show filtered label is in particular confusing. i think the best solution would be the aforementioned followup in #92 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work .B
• and one other detail i've noticed with the region label, place block button and the show filtered button combo in the context of the columns on mobile. on desktop everything is within the block column while on the iphone you have the region in the block column the place block button in the category column and the show filtered in the region column. tricky, not sure what the best approach might be here :/

re #98 ✨ Allow to JS-filter blocks in regions on the block layout administration page Needs work
I have no strong opinion about that one, but i lean towards like you suggested to keep the notification in the same place as the skip link. but that reminds me to one other detail from the remaining tasks list, that notice still needs an announcement for screenreaders. otherwise that notification goes unnoticed for a screen reader users. there is the need for an aural feedback.

This is not the issue that made the test fail @sijumpk.
I commented the some lines on my last commit that broke the feature but I was trying to identify why some tests are failing.
I already tried this option to resize the window locally without the comment work and didn't work.
But I finally found the issue and will commit the fix to the test.

Hello @rkoller.

re #99 A: Both details were fixed.

re #99 B: First and second points fixed. now the text Show filtered and Hide filtered is based on the "button" status.

My next steps:

• Work in more unit tests to cover all new features added by the issue, it's missing some scenarios
• Work on the remaining tasks by priority

changed the remaining task section from an unordered to an ordered list to easier address and reference the different points

updated the remaining task. marked a few as done and removed number 24 which becomes obsolete with the switch button pattern

There is a new problem that surfaced in the context of the new navigation module. The following issue illustrates a problem with stick headers 🐛 The sticky header has an offset Needs review . with both MRs applied, the one in the claro queue and the one in the navigation queue the table header is scrolling past the filter field set overlaying it:

After some more research and a discussion with @joaopauloc.dev on slack i'll update the four follow up issues listed:

5. remains the same - i will finish a draft soon
10. the scope is slightly different, a follow up issue is need, but the * gets added if the weight is changed by a number field the * is added while if the change happens via a select field the * is not added.
11. i would drop the task entirely, for one it might be confusing for none sighted people if the fields are dynamically reordered right after the value is changed and on the other hand @mgifford said the drag and drop functionality probably would have to be rebuild from the ground up anyway since it isnt scaling well in its current form. according to him the current form was intended as a short term fix in D7.
12. add the prefers reduced motion with no preferences media query already within the scope of this issue. it is an easy fix since the animation related parts have simply to be wrapped within this media query plus moving it to a follow up wouldnt make too much sense since there wont be a single centralized place to fix that animation problem, it has to be solved in each component anyway it looks like.

created the followup for point 5 in the remaining tasks section: ✨ Add a clear button to the fields ui Active