This is a migrated thread and some comments may be shown as answers.

New drag-and-drop reordering functionality is not reliable

4 Answers 159 Views
TreeList
This is a migrated thread and some comments may be shown as answers.
Jacob
Top achievements
Rank 1
Veteran
Jacob asked on 17 Sep 2020, 07:13 PM

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.

4 Answers, 1 is accepted

Sort by
0
Georgi
Telerik team
answered on 21 Sep 2020, 11:13 AM

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:

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:

Regards,
Georgi
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

0
Jacob
Top achievements
Rank 1
Veteran
answered on 21 Sep 2020, 01:40 PM

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.

 

0
Georgi
Telerik team
answered on 23 Sep 2020, 08:56 AM

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

Five days of Blazor, Angular, React, and Xamarin experts live-coding on twitch.tv/CodeItLive, special prizes, and more, for FREE?! Register now for DevReach 2.0(20).

0
Jacob
Top achievements
Rank 1
Veteran
answered on 23 Sep 2020, 03:35 PM

Understood, thanks Georgi.

 

Tags
TreeList
Asked by
Jacob
Top achievements
Rank 1
Veteran
Answers by
Georgi
Telerik team
Jacob
Top achievements
Rank 1
Veteran
Share this question
or