Differentiate visually dragging with and without hierarchy

Created on 23 September 2023, 9 months ago
Updated 4 April 2024, 3 months ago

Problem/Motivation

Dragging menu items or terms can have hierarchy and motion in 4 directions.
Dragging blocks in block layout does not have hierarchy and only has up and down motion.
User does not have visual clues on whether or not a draggable list has hierarchy or not.

(This change might also contribute to solutions to comply with WCAG 2.2. criteria 2.5.7 dragging movements)

Steps to reproduce

  • Go to for example the Block layout page (/admin/structure/block)
  • You have 4-directional arrow icons that illustrate the directions the icon can be dragged on the x- and y-axis but on the block layout page it is only possible to reorder an item on the y-axis.

Proposed resolution

Common icon for draggability helps identify draggable icons.
When "acitve" the modified icon could mark what kind of dragging is supported in that particular view.
Proposed icon in the partial screenshot:

Remaining tasks

  • Allow CSS to know if a draggable item table has hierarchy or not
  • Instead of scaling use different Icons or use a suitable more complex transformation
  • Map areas that tabledrag works only vertically or horizontally direction and add the correct parameters to display the correct icon

User interface changes

Hierarchical draggable list items:

Vertical draggable list items:

  • The title attribute changes from Drag to re-order to Change order (summary for the reasoning from the usability meeting in #24 Differentiate visually dragging with and without hierarchy Needs work ) .
  • The icon changes to
  • The pages the new icon is used on are:

    • Every Manage form display and Manage Display page
    • admin/structure/block
    • admin/config/content/formats
    • Every text format, eg admin/config/content/formats/manage/basic_html?destination=/admin/config/content/formats
    • Every image style, eg 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
    • If any type of selection field is created the allowed values list
    • Most of the sections of a view have the option to rearrange items in their drop buttons, eg on /admin/structure/views/view/content
    • The states and labels for every workflow, for example /admin/config/workflow/workflows/manage/editorial?destination=/en/admin/config/workflow/workflows

    API changes

    Data model changes

    Release notes snippet

    Feature request
    Status

    Fixed

    Version

    10.3

    Component
    Claro 

    Last updated about 9 hours ago

    Created by

    🇫🇮Finland simohell

    Live updates comments and jobs are added and updated live.
    • Usability

      Makes Drupal easier to use. Preferred over UX, D7UX, etc.

    Sign in to follow issues

    Merge Requests

    Comments & Activities

    • Issue created by @simohell
    • Assigned to joaopauloc.dev
    • Issue was unassigned.
    • Status changed to Needs work 9 months ago
    • 🇧🇷Brazil joaopauloc.dev

      Recently I was working on Allow to JS-filter blocks in regions on the block layout administration page Allow to JS-filter blocks in regions on the block layout administration page Needs work 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 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.

    • last update 9 months ago
      Custom Commands Failed
    • Pipeline finished with Failed
      9 months ago
      #26747
    • last update 9 months ago
      Custom Commands Failed
    • Pipeline finished with Failed
      9 months ago
      #26760
    • 🇮🇳India Gauravvv Delhi, India

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

    • last update 9 months ago
      30,379 pass
    • Pipeline finished with Skipped
      9 months ago
      #26991
    • last update 9 months ago
      30,379 pass
    • Pipeline finished with Skipped
      9 months ago
      #26992
    • Pipeline finished with Success
      9 months ago
      #26990
    • 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 -

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

      Attached reference video as well.
      Thanks

    • Pipeline finished with Failed
      7 months ago
      #62760
    • Pipeline finished with Failed
      7 months ago
      #62778
    • Pipeline finished with Success
      7 months ago
      #63158
    • Status changed to Needs review 7 months ago
    • 🇧🇷Brazil joaopauloc.dev

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

    • 🇩🇪Germany rkoller Nürnberg, Germany

      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?

    • Status changed to Needs work 7 months ago
    • 🇧🇷Brazil joaopauloc.dev

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

    • 🇩🇪Germany rkoller Nürnberg, Germany

      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

    • Pipeline finished with Success
      7 months ago
      #63209
    • Status changed to Needs review 7 months ago
    • 🇧🇷Brazil joaopauloc.dev

      Fixed on the last commit.

    • Status changed to Needs work 7 months ago
    • 🇩🇪Germany rkoller Nürnberg, Germany

      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
    • 🇨🇭Switzerland saschaeggi Zurich

      @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.

    • Pipeline finished with Success
      6 months ago
      #64518
    • 🇧🇷Brazil joaopauloc.dev

      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.

    • Pipeline finished with Failed
      5 months ago
      #79908
    • Pipeline finished with Canceled
      5 months ago
      #79916
    • Pipeline finished with Failed
      5 months ago
      #79919
    • Pipeline finished with Failed
      5 months ago
      #79941
    • Pipeline finished with Failed
      5 months ago
      #79944
    • Pipeline finished with Success
      5 months ago
      #79976
    • Status changed to Needs review 5 months ago
    • Status changed to Needs work 5 months ago
    • 🇩🇪Germany rkoller Nürnberg, Germany

      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 href=" https://www.drupal.org/project/drupal/issues/3389317#comment-15359308 Differentiate visually dragging with and without hierarchy Needs work ">#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.

    • Pipeline finished with Success
      5 months ago
      #81431
    • Status changed to Needs review 5 months ago
    • 🇧🇷Brazil joaopauloc.dev

      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.

    • Status changed to Needs work 5 months ago
    • 🇩🇪Germany rkoller Nürnberg, Germany

      @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 :/ 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.

    • Pipeline finished with Success
      5 months ago
      Total: 544s
      #90607
    • 🇧🇷Brazil joaopauloc.dev

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

    • 🇩🇪Germany rkoller Nürnberg, Germany

      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.

    • 🇩🇪Germany rkoller Nürnberg, Germany

      Usability review

      We discussed this issue at 📌 Drupal Usability Meeting 2024-02-09 Needs work . 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.

    • Pipeline finished with Failed
      5 months ago
      Total: 175s
      #91579
    • Pipeline finished with Success
      5 months ago
      Total: 524s
      #91590
    • 🇧🇷Brazil joaopauloc.dev

      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.

    • 🇩🇪Germany rkoller Nürnberg, Germany

      @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?

    • 🇩🇪Germany rkoller Nürnberg, Germany

      And I've also added the needs issue summary update tag to reflect the latest changes.

    • 🇧🇷Brazil joaopauloc.dev

      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.

    • 🇩🇪Germany rkoller Nürnberg, Germany

      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?

    • Pipeline finished with Success
      4 months ago
      Total: 513s
      #101871
    • Status changed to Needs review 4 months ago
    • 🇧🇷Brazil joaopauloc.dev

      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 on the table structure like the example below.

          '#type' => 'table',
          // For filter.admin.js
          '#attributes' => [
            'id' => 'filter-order',
            '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.

    • Status changed to Needs work 4 months ago
    • 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.

    • Status changed to Needs review 4 months ago
    • Status changed to Needs work 4 months ago
    • 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.

    • First commit to issue fork.
    • 🇫🇷France nod_ Lille

      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 :)

    • 🇫🇷France nod_ Lille

      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.

    • Pipeline finished with Failed
      4 months ago
      Total: 484s
      #102389
    • 🇧🇷Brazil joaopauloc.dev

      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.

    • Pipeline finished with Failed
      4 months ago
      Total: 171s
      #102476
    • 🇧🇷Brazil joaopauloc.dev

      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.

    • 🇫🇷France nod_ Lille

      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.

    • 🇫🇷France nod_ Lille
    • 🇧🇷Brazil joaopauloc.dev

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

    • Status changed to Needs review 4 months ago
    • 🇫🇷France nod_ Lille

      that looks good to me

    • Status changed to Needs work 4 months ago
    • 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.

    • Status changed to Needs review 4 months ago
    • Pipeline finished with Failed
      4 months ago
      Total: 208s
      #104962
    • Status changed to Needs work 4 months ago
    • 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.

    • 🇧🇷Brazil joaopauloc.dev

      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?

    • 🇧🇷Brazil joaopauloc.dev

      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.

    • Pipeline finished with Failed
      4 months ago
      Total: 475s
      #105322
    • 🇫🇷France nod_ Lille

      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.

    • Pipeline finished with Canceled
      4 months ago
      Total: 386s
      #105327
    • Status changed to Needs review 4 months ago
    • 🇫🇷France nod_ Lille
    • Pipeline finished with Failed
      4 months ago
      Total: 464s
      #105336
    • Status changed to Needs work 4 months ago
    • 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.

    • Pipeline finished with Canceled
      4 months ago
      Total: 154s
      #105361
    • Pipeline finished with Success
      4 months ago
      Total: 542s
      #105364
    • Status changed to Needs review 4 months ago
    • 🇫🇷France nod_ Lille
    • 🇩🇪Germany rkoller Nürnberg, Germany

      I've tested again all the pages listed in #37 Differentiate visually dragging with and without hierarchy Needs work 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.

      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.

    • 🇩🇪Germany rkoller Nürnberg, Germany

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

    • 🇧🇷Brazil joaopauloc.dev

      The issue summary looks good to me.

    • 🇬🇧United Kingdom joachim

      > 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.

    • 🇧🇷Brazil joaopauloc.dev

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

      Google Material:

      Bootstrap icons:

    • 🇺🇸United States smustgrave

      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.

    • Status changed to Needs work 4 months ago
    • 🇺🇸United States smustgrave

      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.

    • 🇧🇷Brazil joaopauloc.dev

      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?

    • Status changed to Needs review 3 months ago
    • 🇫🇷France nod_ Lille

      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.

    • 🇬🇧United Kingdom joachim

      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.

    • 🇫🇷France nod_ Lille

      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.

    • Status changed to RTBC 3 months ago
    • 🇺🇸United States smustgrave

      Seems all feedback has been addressed

    • 🇪🇸Spain ckrina Barcelona

      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.

    • 🇬🇧United Kingdom joachim

      > 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.

    • 🇬🇧United Kingdom joachim

      Two minutes in inkscape.

    • 🇬🇧United Kingdom joachim

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

    • 🇪🇸Spain ckrina Barcelona

      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.

    • 🇬🇧United Kingdom joachim

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

      Works for me! :)

    • Pipeline finished with Failed
      3 months ago
      Total: 161s
      #124107
    • 🇬🇧United Kingdom joachim

      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.

    • 🇩🇪Germany rkoller Nürnberg, Germany

      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

    • Status changed to Needs review 3 months ago
    • 🇪🇸Spain ckrina Barcelona

      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?

    • Status changed to Needs work 3 months ago
    • 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.

    • 🇧🇷Brazil joaopauloc.dev

      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, maybe we also need to change the icon of the cursor which now is different from the icon on the table drag.

    • Status changed to Needs review 3 months ago
    • 🇧🇷Brazil joaopauloc.dev

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

    • Pipeline finished with Failed
      3 months ago
      Total: 676s
      #124273
    • Status changed to Needs work 3 months ago
    • 🇪🇸Spain ckrina Barcelona

      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.

    • Status changed to Needs review 3 months ago
    • 🇧🇷Brazil joaopauloc.dev

      I reverted the icon to the first one.

    • Status changed to RTBC 3 months ago
    • 🇫🇷France nod_ Lille

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

    • Pipeline finished with Failed
      3 months ago
      Total: 8081s
      #124360
    • Pipeline finished with Success
      3 months ago
      Total: 547s
      #124575
    • Status changed to Fixed 3 months ago
    • 🇬🇧United Kingdom alexpott 🇪🇺🌍

      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.

      • alexpott committed cde3ff56 on 10.3.x
        Issue #3389317 by joaopauloc.dev, nod_, Gauravvvv, joachim, simohell,...
      • alexpott committed c8ff8fd5 on 11.x
        Issue #3389317 by joaopauloc.dev, nod_, Gauravvvv, joachim, simohell,...
    • 🇬🇧United Kingdom alexpott 🇪🇺🌍

      @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.

    • 🇫🇮Finland lauriii Finland

      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.

    • Automatically closed - issue fixed for 2 weeks with no activity.

    Production build 0.69.0 2024