Drag and drop on long press #23497
Drag and drop on long press #23497
Conversation
|
Size Change: +1.57 kB (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
ZebulanStanphill
added
[Feature] Drag and Drop
|
I love this in concept, but with the way the drag-and-drop behavior has recently changed — where the block being dragged now disappears from view — this feels disorienting. I think some of it is that I'm not initiating the drag from the block toolbar. But when dragging, the block toolbar is the only thing I see and its attached to my pointer. |
|
Thanks for the exploration! I've been fiddling with it. The animation of the block growing to indicate the drag is a bit awkward. I wonder if dimming the block, or increasing an overlay opacity from light to darker might work better? So as the longpress is happening, the block gets darker until, SWOOP, it's sucked into the little black drag box (whatever we're calling it). I found an issue with the resizers on a Cover block. I assume this exists with Image blocks and Spacer blocks too. When clicking to drag a resize node, the longpress action triggers for drag and drop.
|
|
It appears we've lost some z-index elevation on the drag box too.
|
|
Also just noticed this longpress drag is triggered when attempting to zoom with the new image editing features.
|
|
I'm going to close this exploration since it seems like this is not something we can do on some touch devices anyway. In iOS, long press on a word is meant to select it. |
|
Update: I think we can maybe work around the iOS conflict if it doesn't feel too awkward. We can also long press after a selection is finished if the user is still pressing for 1 second. This would effectively make it a bit longer for iOS users to start a drag from long press on text (but not on other content). Regarding the other conflict with resizing and zoom, we can treat it the same as selection, so cancel the long press if resizing is detected. I agree about the animation. I think for consistency we should keep the block box for long press, even if the drag didn't start in the toolbar. A smooth animation from the block to a black box seems like a cool idea, but animation isn't my forte. @jasmussen What do you think about the transition from block to black box? |
|
Awesome Ella!
Just to be sure I'm understanding it, is this animation what you're referring to?
Due to all the excellent challenges outlined in this post, I think for starters we should probably only actually start the animation the moment the drag action is actually invoked. I.e. after whatever timer we land on has run out. At that point, the animation should be fast, like 0.2s max. The most obvious approach I can imagine is that the block being moved fades out and collapses, while the little black chip pops into existance. Google Tasks sort of shows how this can look:
I recall the primary challenge with that is that we couldn't make adjacent blocks in the canvas animate to fill up the space left by the block "lifted". That might become more evident with this animation. In absence of figuring out how to do that, it's probably fine for the animation to simply be the chip animating from zero and into existance, as the block is lifted. |
|
Hi @ellatrix Ella how is the long press PR coming along? It looks great Ella and Joen! It sure helps to improve drag and drop. |
|
I happen to come across this issue: That makes it a bit tricky with longpress to move a block. |
|
I was trying to get these changes working with our current version of drag and drop but haven't got very far. I dumped what I have over here in case anyone else is interested in giving it a go! Dragging kind of works but dropping doesn't 😄 |
|
Let's close this in favour of #63267. |
Description
As you can see at the end of the GIF, dragging and animation is cancelled if you start selecting text or you let go.
See #25237, #41665.
How has this been tested?
Screenshots
Types of changes
Checklist: