Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#8414 closed feature (wontfix)

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:
Blocked by: Blocking:

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 (9)

comment:1 Changed 11 years ago by Scott González

Owner: set to brennan.roberts
Status: newpending

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

comment:2 Changed 11 years ago by brennan.roberts

Status: pendingnew

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 11 years ago by Scott González

Resolution: wontfix
Status: newclosed

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 11 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 11 years ago by Scott González

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 11 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 11 years 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 11 years ago by Scott González

@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 use case as brennan.roberts, but even Paul agrees that it should be removed.

Version 0, edited 11 years ago by Scott González (next)

comment:9 Changed 10 years 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.