Ticket #8414 (closed feature: wontfix)

Opened 2 years ago

Last modified 10 months ago

Draggable should provide a "cancel" method.

Reported by: brennan.roberts Owned by: brennan.roberts
Priority: minor Milestone: 1.9.0
Component: ui.draggable Version: 1.8.21
Keywords: Cc:
Blocking: Blocked by:

Description

Woe to the Draggable: why has it not a proper "cancel" method? While his sibling Sortable may be halted on command, Draggable must sit idly by, waiting for that next "drag" event so that we may return false. Pity.

Let us rectify this grievance forthwith!

Change History

comment:1 Changed 2 years ago by scott.gonzalez

  • Owner set to brennan.roberts
  • Status changed from new to pending

Why? Programmatic canceling is bad UX. We plan on removing it from sortable.

comment:2 Changed 2 years ago by brennan.roberts

  • Status changed from pending to new

The scene: generic real-time application. A mess of draggable things that may be moved or deleted by any user. User A starts dragging one item. User B deletes the same one.

This displeases user A. But such is collaboration.

comment:3 Changed 2 years ago by scott.gonzalez

  • Status changed from new to closed
  • Resolution set to wontfix

You should let the user finish their action and then inform them that the item has been deleted by someone else. Dragging is not a long running operation.

comment:4 Changed 2 years ago by brennan.roberts

Perhaps.

Imagine the same application, except where large modal changes will and do happen frequently, entirely replacing the original collection of draggable things. What happens here to mid-drag item? Must it persist in this new, unwelcoming world until liberated by a mouseup?

comment:5 Changed 2 years ago by scott.gonzalez

It should. That's much less jarring to the user. You can display a message to the user if you need to, or manually find a way to cancel. But, this is bad UX. You should not remove an item that a user is in the middle of dragging. We will not encourage such behavior by adding a method to explicitly do so.

comment:6 Changed 2 years ago by brennan.roberts

It's an interesting opinion, but I'd always considered jQuery UI an unopinionated toolkit that provided all the necessary means to shoot myself in the foot. I'll have to either adjust that or get my bullets elsewhere.

Thank you for your time and swiftness.

comment:7 Changed 22 months ago by eleotlecram

Correct me if I'm wrong, but AFAIK most drag-and-drop file explorers (Windows Explorer, OSX Finder, KDE's Konqueror and Dolphin, Gnome's Nautilus) allow you, as the user, to start dragging a resource and then, mid-flight, allow you to hit the ESC button, which will then immediately abort the drag operation and revert the state to which it was prior to drag start.

Now do you guys suggest that all these file explorers have their UX wrong? I suggest one reconsiders reopening this ticket.

comment:8 Changed 22 months ago by scott.gonzalez

@eleotlecram: Whether pressing escape should cancel a drag and whether there should be a public cancel method are two different things. Providing a public cancel method encourages users to create bad UX. The team has discussed this before, while reviewing sortable's API. Sortable's cancel method was implemented by Paul Bakaus for a user with the same use case as brennan.roberts, but even Paul agrees that it should be removed.

Last edited 22 months ago by scott.gonzalez (previous) (diff)

comment:9 Changed 10 months ago by tjcrowder

Please reopen this ticket and fix this. I'd be happy to fix it if the fix will be accepted. It's simple, basic functionality for which there are solid, real-world use-cases. I was VERY surprised to find I had to hack together a way to allow the user to remain in control of the drag (by being able to cancel it).

Note: See TracTickets for help on using tickets.