Ability to move DragBetweenLine intersection and rendering to beneath an expanded item's <ul>

[tonyketcham]

Is your feature request related to a problem? Please describe.
The default UX for reordering dragged items beneath an expanded item does not feel intuitive and takes some getting used to:

Screen.Recording.2022-09-09.at.4.00.11.AM.mov

especially as the reorder behavior above the top child is not consistent for children of the expanded item:

Screen.Recording.2022-09-09.at.4.09.23.AM.mov

Describe the solution you'd like
I would like to be able to hover my dragged items at the bottom of the expanded layer's <ul> element and get drag between line feedback there (rather than directly beneath the expanded parent) for dropping the items beneath the expanded layer.

Describe alternatives you've considered
Perhaps this could be a non-breaking change by providing a prop to the tree environment similar to defaultInteractionMode

[combdn]

I agree. I was about to report this as a bug when I saw this issue.
In my view, it is indeed a bug. The line should indicate where the dragged item will land, and currently, it doesn't.

CleanShot.2023-09-03.at.15.56.33.mp4

[lukasbach]

Right now, the logic for determining the drop target is fairly complicated, so introducing customizability there is probably not that easy.

I understand that the current behavior might not be super intuitive, but I'm also not sure how an ideal behavior would look like, or rather if I correctly understand the behavior you suggest.

Assuming the following state

- Desserts
  - IceCream
  - Cookies
- Drinks

• Dragging at the bottom half of Desserts will drop the item below Desserts, so in the root layer between Desserts and Drinks
• Dragging at the top half of IceCream will drop the item at the top of the Desserts contents
• Dragging at the bottom half of Cookies will drop the item at the bottom of the Desserts contents
• Dragging at the top half of Drinks will drop in the root layer between Desserts and Drinks, same as first case

Imho this behavior is fairly consistent in regards to where you hover with your mouse and where the item will end up. The drag line will be displayed where the mouse is, though a visual differentiation is put between the first and second case by indenting the line to the right to the indentation of the layer that the item will be dropped at.

Now if I understand correctly, you suggest to keep this general behavior, but just move the displayed drag line in the first case at the same location as in the final case? I tried an implementation out for it, so it would be possible, but honestly, I'm not sure if this is that much more clearer than the current implementation, and to me feels rather unexpected than intutive.

What are your thoughts, or did I misinterpret something of your suggestions?

[combdn]

See also Fitts’s law.

[lukasbach]

Thanks for the visualization. I played around with it a bit more, and I think I agree. I implemented the behavior as you suggested for dropping at the bottom of open folders, you can check out the new behavior at https://rct.lukasbach.com/storybook/?path=/story/core-drag-and-drop-configurability--default. I also added an escape hatch to use the old behavior with
the canDropBelowOpenFolders option on the tree environment.

The behavior for dropping at the top of the last item in an open folder remains the same. This still has this ambiguity, where dropping at the top of one item is something else as dropping at the bottom of the item on top, but if they are changed the same way, there are scenarios in which certain drop targets wouldn't be available at all anymore, so I don't see a good solution for changing that behavior.

Let me know what you think!

[tonyketcham]

Love this!! I had a play with the new behavior and found it's not possible to drop an item at the end of a tree's root child folder if the last item is an open folder:

Attempt.to.drop.at.bottom.of.tree.mov

We often see our users trying to either drag slightly to the left or slightly down to be the last child item of a root child folder of the tree while there's an open folder at that index. Here's a video from a user research session where they struggle with this interaction:

User.research.tree.drop.at.end.of.root.-.no.ppi.mp4

Do you think it would be possible to have x-axis assist in finding drop targets?

[lukasbach]

Cool demo, love the look of your app!

There actually is an open discussion to this very issue at #261. I mentioned there already that using the horizontal axis might be a bit difficult to integrate in the existing drop logic, but I did add some logic to interpret dropping below the final tree item (as long as it is still in the tree container) as dropping at the bottom of the tree into the root item.

[lukasbach]

The changes that we discussed have since been released with v2.4.0. Again, big thanks for sponsoring the development of this feature! I'll close this issue, please feel free to reopen or let me know, if you have any other issues.