Differentiate visually dragging with and without hierarchy

Recently I was working on Allow to JS-filter blocks in regions on the block layout administration page and one of the comments/suggestions was to change this drag icon since in that page we drag only vertically. I added the support there to change this icon based on attribute data.

But I didn't know about this issue, so we decided to remove this feature of Allow to JS-filter blocks in regions on the block layout administration page and try to do this work here.

I used the drag icon supported by the browsers, but I saw that in the Proposed solution there are some suggestions. I would like to propose that we use the icon displayed by the browsers when we are dragging vertically. So, we can follow a pattern of icons instead of creating a new one, even if the icon proposed is very similar. The icon that I added is not the same as the browser(row-resize), I'll update that soon.

Follow two examples where I change the icon.

and

Thanks.

Hi,

Based on the last comment #5 solution. tested the issue Differentiate visually dragging with and without hierarchy. and found that in blocks drag able icon is changed for vertically rearranged order. also tested in views also there are only vertically reorder but found the changes. attached image for reference.

Tested Steps:
1. Drupal 11.x setup and moved on path admin/structure/block and admin/structure/views/view/frontpage to verify the icon.
2. Moved to Merge request !4936 , and verified the changes on block and view page.
3. On block page (vertical) looks fine, but on view (filter criteria) it's still same.

After MR:
Block:

Veiws:

Tested merge request !4936 on Drupal 11.x. The drag icon is updated only for the blocks not for the view page.
Attached screenshot, as in #6 comment images are not visible.

I was trying to fix the issue for the views drag icon but what I observed here is that the drag icon is updated in the views as well but not for the filter criteria tab. So we need to update the table drag functionality for the filter criteria tab only.
Table drag-icon functionality worked for below mentioned list -

• Block
• Views
• Fields
• Sort criteria
• No results behavior
• Relationships

Attached reference video as well.
Thanks

Hi all, thanks for testing.
The drag icon for views was fixed.

one detail i've noticed when testing the patch. it is working as expected on the block layout page but if you go for example to the manage form display page of the article content type /admin/structure/types/manage/article/form-display you still have the old drag icon for horizontal and vertical dragging even though only a vertical drag is possible there as well. since the scope of this issue isn't solely about the block layout page but about Core in general shouldn't other list pages only allowing vertical drag updated as well with this patch?

Good catch @rkoller, i'll update this form too. Do you remember any other place that we should update this icon?

a few that come to mind are the manage form display and manage display pages for:

• block types
• comment types
• contact form
• content types
• taxonomy
• account settings /people/accounts

Fixed on the last commit.

thanks for the fast fix! i manually went through the pages i've listed in #12 and i can confirm that all are using the horizontal drag now. to make sure everything behaves correctly i've also tested adding new entities on the different entity types - all using the horizontal drag now. great!

but then i've noticed in my previous test i forgot to install the rest of the available core modules. i've quickly installed and went through the additional ones. i've noticed the following you've already adjusted? (at least they already have the horizontal drag):

• media
• workspaces

but the following occassions still employ the horizontal/vertical drag;

• content moderation for example /admin/config/workflow/workflows/manage/editorial?destination=/admin/config/workflow/workflows
• the effects on an image style for example /admin/config/media/image-styles/manage/large?destination=/admin/config/media/image-styles
• admin/config/search/pages
• short cut sets for example /admin/config/user-interface/shortcut/manage/default/customize
• text formats and editors /admin/config/content/formats

update: forgot to install the multilingual modules. those two have also horizontal/vertical drags:

• /admin/config/regional/language
• /admin/config/regional/language/detection

@joaopauloc.dev I love the direction here, thanks for working on it.

Something we have to keep in mind here is that there are modules like field_group which alter the ability to drag & drop e.g. in the Manage form display.

Hello @saschaeggi, thanks.
Good point. I tested here because I did remember the field_group and this was the result.

But in my opinion, this is something that should be fixed on the field_group module.
When this issue is merged I can work on a particular issue in the field_group module. The way that we are adding this option to choose the icon drag will be easy to fix on the field_group.

Thanks for the update! I've already wanted to post a comment one or two days ago after a conversation with @mgifford, but havent found the time yet. :(

But at first a note about the current patch. It applies cleanly again. I've went through the pages mentioned in previous comments and /admin/config/regional/language/detection raised in #14 is still showing the drag handle for vertical and horizontal dragging.

And i've found another page that we've missed before which wasn't mentioned yet: /admin/people/roles

And the detail I've talked about with Mike is that both the vertical as well as the vertical/horizontal drag handle both have the same title attribute: Drag to re-order . Technically vertical/horizontal is not "just" a change of order but also a change of hierarchy. Therefore we've wondered if it would make sense to use different titles for each drag handle?

About the titles itself I am still thinking about but for the new icon perhaps something like "Vertically drag to re-order" might work while for the old vertical/horizontal icon, which is a bit tricky, something like "Drag to change order and hierarchy" might work? Not sure.

I'll set the issue back to needs work based on the two pages that still use the vertical/horizontal drag handle.

Hello, @rkoller.
I fixed both pages that don't have the icon correct.

If you think that is necessary to update the title of the icon I can work on that.

@joaopaulooc.dev thank you! i can confirm the two pages i've noted have now the vertical drag handle. while testing another patch i've spotted another case or better cases :/ (thought I've already catched all). if you are adding a new field to a content type and if you choose Selection list, all three available options currently have vertical/horizontal drags for the allowed values on the field config edit form.

in regards of the title i'll ask others over in the #ux channel today or in tomorrows meeting to see if there is a broader consensus for the addition of the titles and in case there is also quickly talk about the suggested micro copy.

i'll set the issue back to needs work because of the Allowed values on the field config edit form. In regards of the title i'll provide infos about the outcome as soon as i know more.

Hello, @rkoller.
I fixed the icon in the allowed values form on the edit field settings that you mentioned.
Any update regarding the icon title?

thanks unfortunately the last two meetings were packed with issues. just moved the still open issues from last week over to the meeting tomorrow. so the odds are high that we are able to finally discuss the icon titles and have a brief discussion in regards of word smithing.

Usability review

We discussed this issue at #3418992: Drupal Usability Meeting 2024-02-09. That issue will have a link to a recording of the meeting.

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

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

There was a consensus that having different title attributes for the different icon types is a good and useful thing. We've spent a good share of time ideating and discussing the viable options. We tried to avoid the term drag with regard to https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements, if you take single pointer usage into consideration for example. Aside that we tried to avoid directional terminology like up, down, left, right, or more complex directional terminology like vertically or horizontally. Technically it might be also a good thing to use clear instructional language instead of using conceptual language. We haven't ended up with a clear recommendation but two suggestions:

For the vertical drag:
Change order

For the horizontal/vertical drag:
Move in any direction

The only minor problem with the suggestion is that change order uses conceptual language (order) while move in any direction uses instructional language. Move in any direction was the most clear with a broad consensus. Problem is to apply a similar instructional patter for the vertical drag you would have to employ some directional terminology, at least we had no better idea so far. So there is the slight disconnect between the two because one is conceptual while the other is instructional at the moment.

Hello @rkoller.
I implemented the suggestion mentioned above and I thought both titles fit well. As you can see in the images below.
Move any direction title example.

Change order example.

@joaopauloc.dev awesome! just applied the patch. I can confirm the icons for the Selection lists are using vertical drag icons now and both titles are shown as well. Looks good!

And i would have one question, something i've just noticed. it is out of the scope for this issue, but it is sort of related and you are familiar with the code in that context.

if you go onto page with with vertical drag handles and have the showing row weights toggle active like for example on
/admin/structure/types/manage/article/form-display you’ll have a numbers field for weight and select fields for parent and region.

if you go onto page with vertical/horizontal drag handles and have the showing row weights toggle active like for example on /admin/structure/menu/manage/admin you’ll only have a number field for weight available.

Having the option to set the parent within a select field on a form display page has no purpose at all since the fields there are in a flat vertical order. The correct and mandatory place for the parent select field would be on pages with hierarchical positioning like on a menu page instead. It looks like the positioning somehow got switched at some point.

I’ve cross checked on two fresh installations of Drupal 10.2.3 and 11.x-dev. The problem applies to each of them as well. I will open up a follow up issue for the problem. The only question, would it be necessary to postpone the followup issue on this issue or should it be set just as related? Cuz from my understanding with this patch there are two types of sortable lists introduced. at the moment the only difference is the icon but i think the parent select field for the hierarchical sort type would be another difference?

p.s. would you know what would be the appropriate component for that issue? claro like this issue wouldnt be the correct fit but the occassions are scattered across components. menu is the system component while the form edit page is the field ui component and more.

And I've also added the needs issue summary update tag to reflect the latest changes in regards of the title

Good catch @rkoller.
In my opinion, we could follow it as a new follow-up issue and just set it as a related issue. Then we can move forward with this one.
Also, as you mentioned is not related to the changes of this issue. I think the changes in this issue make evident the issue that you found.

ah thanks for the confirmation!

i went through the whole admin ui another time. i found two more pages (and i really thought we already catched everything):

1. /admin/structure/taxonomy
2. the filter processing order for a text format ( for example /admin/config/content/formats/manage/full_html?destination=/admin/config/content/formats

and one other detail. would it be necessary to add a change record an or a documentation page for this issue with instructions for contrib maintainers in case their module has any none hierarchical draggable lists? not exactly sure about the exact requirements in that regard?

Fixed both pages.
I think we need to add a change record since we changed the table drag plugin to support both icons.
For other modules or even in a core feature to use the vertical icon just need to add the following attribute data-drag-orientation on the table structure like the example below.

    '#type' => 'table',
    '#attributes' => [
      ....,
      'data-drag-orientation' => 'drag-y',
    ],

By default, the table drag will use the horizontal/vertical drag icon.
But we need to update the documentation too. But I don't know how to do that.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Implementation is not going to play nice with modules like field_group that adds possible indentation levels in place they are not possible initially (like the manage display list). Having to add a data attribute (outside of the existing tabledrag config as well) is not a option here. We need the tabledrag script itself to figure this out based on the tabledrag configuration so that we can support contrib properly and not forget edge cases.

Field items are not supported and those would be the most visible ones to update for the majority of users.

Added a few comments in the MR.

Aside from that +1 on the feature :)

This is what I had in mind.

The block interface, manage display do not seem like hierarchical interfaces but they are in the code (the regions are the first level of hierarchy) so they do not show up as reordering. We can maybe find a way to tweak that but what most people would run into are the multi-value fields to reorder, and those show up properly with the attached patch.

Thanks for the suggestions @nod_. I didn't know about the indentEnabled setting, much better.
I removed the old setting of the forms.
I also made a list of all the places where we already noticed that the icon should be changed.

Without user configuration.
admin/structure/block
admin/config/content/formats
admin/config/content/formats/manage/basic_html?destination=/admin/config/content/formats
admin/config/media/image-styles/manage/large?destination=/admin/config/media/image-styles
admin/config/regional/language/detection
admin/config/regional/language
admin/config/search/pages
admin/config/user-interface/shortcut/manage/default/customize
admin/structure/taxonomy
admin/people/roles

Needs quick settings.

Field settings default values.
Create a field of the ListItem type add more than one default value and save, you should able to order the default values.

Views
Go to any views and try these.
rearrange fields.
rearrange filter in views.

Workflow
Enable workflow and content moderation modules and go to
/admin/config/workflow/workflows/manage/editorial?destination=/admin/config/workflow/workflows

Regarding the manager form display and manager display I'm working on that.

Hello @nod_.

Regarding your comment #36. I was looking for some way to do that.
I couldn't identify a way to make this dynamically for tables that we have h/v dragging. In the case comment on Field form settings, I tried to use other tabledrag settings but wasn't enough.

I checked out the class tabledrag-leaf that makes the drag h/v work added by the form EntityDisplayFormBase. Since this setting is added on the base form, I couldn't identify a way to make this work without any change by the contrib modules like field_group.

I will spend more time this weekend on this issue but I guess without any change on the contribe module will not be possible.

Another possibility could be to keep the form display with the h/v drag icon. As you mentioned in your comment #36 the settings are hierarchical.

I tried to find a way to do it as well, didn't find anything obvious. Since using indentEnabled covers most of the obvious cases I'd say it's good enough for now. It'll fix the most user-visible instances of the problem (multi-valued fields) so I'd call that a win.

@nod_, should I move this issue to needs review?

that looks good to me

just a last fix to make https://git.drupalcode.org/project/drupal/-/merge_requests/4936#note_271242

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Hey @nod_, the main problem with this approach it's the Manager form display and Manager fields show the vertical/horizontal icon being displayed but the user can only drag on vertically.
I would like to suggest to change the change EntityDisplaysFormBase to work in a different way than the parent works. Then the icon will be properly.
Also, we could create an issue(feature request I think) on the field group module to change the EntityDisplaysFormBase to work as they need.
What do you think?

Adding two patches as examples of how we could change the tabledrag settings for the core display the vertical icon and for the field_group display the vertical/horizontal icon.

Field group example.

Core.

That's a good idea, although needing contrib to change is not ideal.

I think I found a solution to make that dynamic, it works on the manage display with field_group automatically, on the block layout.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

nice @nod_

I've tested again all the pages listed in #37 as well as pages that contain the hierarchical icons like menu pages with the latest changes from @nod_ . everything looks good and works as expected on an install of drupal 11.x-dev. and it looks like an elegant solution @nod_ came up with. nice!

I've then taken an initial attempt to update the issue summary. I've slightly adjusted the steps to reproduce section. I've then added current screenshots, the changed title attribute strings, as well as a list of all the pages the new icons apply to to the "user interface changes" section. please review those changes and in case the issue summary can be considered up to date remove the "needs issue summary update" tag afterwards. thank you.

used one wrong file name by accident in the issue summary.

The issue summary looks good to me.

> The icon that I added is not the same as the browser(row-resize),

The row-resize icon has a horizontal line in it because it's about dragging a *boundary*, the line between rows.

Here we are dragging *objects*, the rows themselves. That's not the same operation and I don't think that's the right icon.

Something that's just the same as the 4-way arrows but only up and down would make more sense.

It would also be more visually distinctive, as currently with poor vision, both icons look like a + shape.

I did a quick research for drag icons looking for other options but didn't find any different.

Google Material:

Bootstrap icons:

Personally the icons in the issue summary I think makes sense. With the up/down arrows or 4 arrow cross for up/down/left/right.

To keep the issue from staling going to move to NW for the open threads from @nod_. Luckily I see @joaopauloc.dev you opened the MR so for the threads you've resolved can you close.

Are we going to keep the drag icons? I think they demonstrate very well the drag proposal and I think we don't have too many different options.
@nod_ do you have any comments about the changes?

All in all, I'm ok with it. I don't think they're perfect but it's easy to change them later if needed.

I'm going to say it again -- with the horizontal line in between the arrows, it's meant to convey moving a boundary and not dragging an object.

Folks from the Usability team have reviewed this issue and do not seem to have a problem with the icons, I trust the judgement of the usability team here. If it ends up being a big problem, the fix is something like 1 or 2 line change once this patch is in.

We could delay this for another year to get the icons perfect, or we could get that in now, get some feedback from a wider range of folks and update if necessary. I think the code as-is will make things better for most folks. And if it doesn't we'll roll it back.

Seems all feedback has been addressed

It looks like you were faster @smustgrave to move this to RTBC. :)

So noting my +1 to RTBC this, both on a code perspective and as a UX maintainer.

As @nod_ says, I'd also prefer to be more pragmatic and move the icon design to a follow-up without blocking the whole improvement. I'd agree with both @nod_ and @joachim on using an icon without a line in the middle as a slightly better solution, but priority wise the current solution is already an improvement on a usability perspective.

> We could delay this for another year to get the icons perfect

Just take a copy of the existing 4-way arrow and chop off the side arrows. It's that simple.

Two minutes in inkscape.

SVG upload didn't work; here it is zipped.

Thanks @joachim. A mentioned, a small icon change shouldn't block issues that are good enough. If we want Drupal to move faster we can't block issues that improve Drupal for this details that can be done in follow-ups.

You're welcome to change the actual code on the MR with the SVG if you get here before a committer. Otherwise, you can open a follow-up issue to remove the line.

> You're welcome to change the actual code on the MR with the SVG if you get here before a committ

Works for me! :)

Done.

(I'm confused why the original is in /images/src/ and the new one in /images/icons/currentColor/ but I assume it's theme stuff I don't understand.)

In passing -- it makes it MUCH easier for people to understand the work in a branch if it's rebased against 11.x rather than has 11.x merged in.

hm i wanted to take a look how the proposed icon behaves in the interface but after successfully applying the changes (the new svg is in place where it is supposed to be) i am still seeing the old icon for example on /admin/structure/types/manage/article/display

Moving it to NR since design changes have been made.

Would it be possible to see the result with the new icon design applied to evaluate it?

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Hi folks, the last commit was missing the built CSS file.
Now you guys can see the new icon applying the patch again.

But in advance in the image below is the new design.
Personally, I think the old one is better.

Also, maybe we need to change the icon when we are dragging which now is different from the icon on the table drag.

Thanks for the proposal and also thanks @joaopauloc.dev for the screenshots! It made it easier to see it in action.

Sadly, as a designer I have to say that the resulting icon doesn't follow the minimum visual requirements that we need. The main of the flaws it has is that the top and bottom arrows don't have enough weight to be perceived as the key elements to understand the action. They worked with the cross because in the the weight was taken by the cross itself. But in here, to communicate the up-down direction they need to be bigger and not that close.

I know that with design anybody will feel empowered and will want to give an opinion, so my recommendation is to move back to the previous icon and open a follow-up to find a better replacement for this one.

I reverted the icon to the first one.

Thanks, testbot taking it's time but setting RTBC for when it's done

Committed and pushed c8ff8fd559 to 11.x and cde3ff56ed to 10.3.x. Thanks!

We can continue discussions about improving the icon in a follow-up issue if people want. @joachim I think we should not be changing icons when an issue about icons has got to rtbc and through UX review. Follow-ups are great for this.

@joachim or to put it another way with visual changes there is always another opinion and there is never a realistically provable 100% right. Yes it would be lovely to put everything visual change through proper UX testing but that is never going to happen.

I agree that the current solution may not be perfect but it solves the described problem and is better than what exists today. So even if this is not perfect, it's good enough. Based on that +1 for moving forward with the proposed solution.

We can validate this future in future by testing how this performs when we do UX testing next time. We can decide if this needs an additional iteration based on that.