New drag-and-drop reordering functionality is not reliable

[Jacob]

Drag-and-drop reordering between sibling nodes in the TreeList widget is a feature I've been greatly anticipating, and I'm happy to see it available in the 2020 R3 release. Unfortunately, in its first incarnation, it has some serious reliability issues and doesn't seem production-ready to me. See the attached screen recording of the widget's demo page and observe the steps I take:

1. I drag Rinah's node to the upper border of its current position, which is also the bottom border of Akeem's node. Nothing happens, as expected.
2. I do the same thing again, but this time, it reorders Rinah before Akeem.
3. I then drag Rinah to the upper border of its current position again, which is also the bottom border of its parent node Hyacinth. Instead of the expected behavior of nothing happening, Rinah becomes a sibling of Hyacinth ordered after her.
4. I drag Rinah back to be a child of Hyacinth again so I can retest the same action from step 3.
5. I repeat step 3. Rinah becomes a sibling of Hyacinth again, but this time she is ordered before Hyacinth instead of after her.

From these steps, I can identify two bugs and a UX suggestion.

• Bug: Steps 1 and 2 should not have produced different results. The same action should consistently produce the same result.
• Bug: Dragging a node to the upper or lower border of its current position should not trigger any reordering action.
• Suggestion: Implement you drag-and-drop reordering UX to be more like DevExpress's TreeList. In their implementation, dragging a node to the upper or lower border of its current position does not even show a reordering indicator, making it obvious to the user that they're not going to reorder anything. In addition, their styling for doing a sibling-level reordering (a thick horizontal line across the entire length of the row where it's being reordered to) versus a re-parenting (making all four borders of the new parent appear thick while you're hovering over it) is much more intuitive in my opinion. It's very obvious when the node is going to be reordered, re-parented, or neither. See the other attachment for an example of what I mean.

[Georgi]

Hello Jacob,

I was able to reproduce the inconsistent behavior. Indeed doing the same reorder should twice should have the same result. I have logged an issue in our github repository and you can track it in the link below:

• https://github.com/telerik/kendo-ui-core/issues/6030

As for your UX proposal, I can suggest you to submit it to our feedback portal, this way other users can also vote for it and based on the traction we will consider implementing it:

• https://www.telerik.com/support/feedback

Regards,
Georgi
Progress Telerik

[Jacob]

Hi Georgi,

Thanks, I will submit my suggestion over there. Regarding the second "bug" I reported (perhaps it's not a bug, but a feature change), can I ask if dragging a node to one the borders of its current position is supposed to change the order, or if that's unintended as well? If it's unintended, I would argue that it's a different issue from the first one and needs its own GitHub Issue number, and if it's intended behavior, I will submit an item to the feedback portal for that as well as the border styling stuff I suggested in my third item.

Thanks.

 

[Georgi]

Hello Jacob,

The described scenario is a valid reorder operation, thus, it is expected to be allowed. I totally agree that it is redundant and it results in the very same order, but still there might be an use case where someone might still need the events to do some operation although the order did not change. If you believe this is should not be allowed I can again suggest you to log another item, this way this will be discussed with our UX specialist and they might consider redesigning the behavior.

Regards,

Georgi
Progress Telerik

[Jacob]

Understood, thanks Georgi.