Try: Don't show a clone when dragging. #23024
Conversation
jasmussen
added
Needs Design Feedback
|
Size Change: +187 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
|
Should the dragged block be removed? It's a bit weird to drag it but still see it in its original position. |
|
I think it should, yes, but I wonder if that's a good experience without a big refactor. I'll see what I can do with CSS, and whether that feels good. |
|
Just for quick testing, I was able to hack together this:
I actually think this works rather well, even in this extremely hacky state. Depending on feedback, we might want to do this, and use the animate component to transform the height of the block being lifted to zero so that the adjacent blocks rearrange themselves in a nice manner. |
|
That last mockup looks really nice. I think, design-wise, all it needs is a redesigned chip (pretty much exactly like the one at the bottom of the main post) and some animation so the blocks slide into place rather than instantly pop upwards when the block is removed. |
|
@jasmussen Whoa! I just tried this out. I do kinda miss seeing the clone, as it provides some context. But boy.. it feels much better. Way smoother. Less noise on the screen. Also! If we were to go in this direction. Your implementation wouldn't be too off! |
|
I was skeptical of this based on the GIFs alone, but trying it out has me sold. I really love how simple it is, and that I no longer have a bunch of text/elements following my pointer around the screen, nor do I have multiple focus states appearing at once. I'd love to see more work on expanding the dropzone when hovered for a second or two; Something to give me a sense of what will happen when I let go. |
|
This is lovely! I wonder why it still shows the block in the navigation block:
Other than that it feels very nice dragging that small symbol |
|
My first impulse seeing the animated gifs is that it is not enough only showing a drag icon when dragging content. I am thinking it would be nice to see the Block icon and name on dragging a block along with the drag icon. Testing through gutenberg.run. (I will need to create a local environment, as the site is often difficult to get into.) Drag works well. Not working: A dragged block still shows a border outline even when another block is selected. Suggestion 1. Example. I took a recording and brought it into Screenflow where I added a frame to give an idea what adding an outline around the Group block might look like while dragging child block. Animation mixed in with a blue border mockup.
Suggestion 2. Just a little thicker. |
|
@jasmussen This feels solid. What is remaining for this to be wrapped up for 5.5? I liked the above idea of swapping the drag handle for the block icon and name. Is that it?
@paaljoachim I think that would be a good future enhancement. I think that's indicative of a larger problem beyond this PR: It's not always clear where I'm dragging when parents and children are involved. Definitely worth exploring in another issue/Pr. |
Thanks Michael. What needs to happen is this:
I need help making those changes happen, and I've tentatively pinged @ItsJonQ for help if he has time. But I'm happy to work with anyone who has time, I know you all have so much on your plates these days. Potentially separate & followup PRs:
|
@jasmussen Haiii! So! I spent some time playing with this. I have some good news and some bad news :P. 🐻 Bad newsHeight animation (especially during drag/sort interactions) is really hard. We use
This is made more complicated by how we (currently) render Block/BlockWrapper components. ☀️ Good newsIt's not impossible. I've worked on these interactions before (from scratch even). I may be able to help here if that's the effect we want to achieve 😊 (I'm biased as I always love fluid interactions) I have a demo of a simple case of this working: Some things that will be needed to make this work:
I started playing around with drag/resort interactions. I don't think collapsing height is a common pattern. It's typically one similar to Gutenberg's (clone is attached to cursor, and original stays put). Notion appears to have something similar. Or something with a shifting placeholder dropzone, like this one: No action required! Just sharing my notes :) |
jasmussen
force-pushed
the
try/collapse-drag-item
branch
from
3b0ab2c
to
c062474
Compare
|
How important do we feel the animations are for this one? I looked again at this PR today, and it's trivially easy to remove the bit that clones the block. And in doing so, it fixes this issue which is rather frustrating. The only remaining part of this PR would then be to invoke whatever is causing the surrounding blocks to shuffle around when you lift and drop a block. The same that gets called when a block gets deleted, presumably. @youknowriad, I recall you working on the block animations — do you know what causes the blocks to move around when you delete a block? And can we do that when you "lift" a block in this PR? |
|
@jasmussen For performance reasons, the animation triggers when the "index" of the block changes, this means if you want the animation to trigger when you start dragging, you should actually remove the block from the block list. That's a bit impactful though and may have some unexpected consequences, so I think it's wiser to try separately. |
|
I pushed some fixes:
I think with this, we could actually merge this one because it's such a better experience. However some followup items would be nice to look at, whether as fixes to this branch, or separate PRs:
We should also change the handle being dragged to output the block type and name, a la: |
|
EDIT: A comment to: #23024 (comment) What I see is dragging a block a blue line shows up in various locations, but not the start location. The blue line should always show up as it gives a hint to where the user can drop the block (also in the default start position where drag began.) As the user might change their mind in relation to dragging a block, and need the visual hint to get it back to where it started from. EDIT 2: Blue line signals where the user can drop a block. (if that is back at the start location makes no difference.) |
This was part of the reason for going with the clone concept and the blue lines in the first place, which is in contrast to other forms of drag and drop where you instantly move a block, and adjacent blocks rearrange themselves. I used to be in the "blue line" camp for exactly the "what if I change my mind" camp, but have realized that we have big and visible undo buttons which means it's trivial to revert a change. Your idea, showing a blue line in the spot of the block you just "lifted", is something we can try — my instinct is it simply adds confusion, because the blue line is meant to indicate dropzone, not "here's where a block used to be". There might also be a different treatment which does not indicate dropzone, that we can try. But in any case, I think it should be a followup. |
|
Behavior-wise, I think this is a definite improvement over |
|
It seems there's some consensus this is worth trying. I obviously agree, and see this path forward:
|
| label = blockType.title; | ||
| } | ||
|
|
||
| return <BlockDraggableChip icon={ icon } label={ label } />; |
There was a problem hiding this comment.
Any reason this is a separate component?
|
Is it an idea to keep the block that is being moved and just add opacity to it? Then the content don't jump so much.
|
This is an experiment.
jasmussen
force-pushed
the
try/collapse-drag-item
branch
from
bac44fd
to
8b58379
Compare
|
I rebased and polished the chip to look like this:
What I realized was that the label is not that useful, and although I didn't initially think the handle was useful, it serves well to sit under the cursor that's dragging and covering. Per feedback in #23024 (comment), I'm unsure how to proceed. If @youknowriad or @ellatrix have time to take a look at this one and land it, feel free to push directly to this branch. |
|
|
||
| // This is only for testing. | ||
| .is-dragging.is-selected { | ||
| display: none !important; |
There was a problem hiding this comment.
did you try with opacity: .5 instead here? Would work much better with for example reordering columns.
There was a problem hiding this comment.
We tried with opacity: 0.7.
As I see it, there are two paths forward:
- Go with the more radical solution of pulling the block out of the flow, literally lifting it off the page. This benefits very big blocks which take up a lot of vertical space, but can cause jumpiness.
- Go with the opacity change, and the chip, which is still an improvement over what we're shipping, but does not have the space saving benefits.
Honestly I think we should get option 1 in good shape, try it in the plugin, and then go with option 2 if we find after using it that the jump is jarring.
|
Thank you for the help Ella, let's get this in and test it out, and I'll do any follow-ups based on feedback. |
|
Agreed, let's see how it feels. |
As of #22673, the mover control is now a permanent fixture next to the block switcher, and the entire unit is a draggable handle. One thing that effort helped surface, was that the fact that we make a clone of the block when dragging feels like it breaks with some physics — you duplicate the block when you're supposed to move it. This is because you don't actually move the block until you drop it.
This PR removes the clone, and hides the block being lifted, leaving only the draggable handle. Before:
After:
The drag and drop experience feels slightly more precise as a result, and less muddy overall.
This description was edited as the PR changed while working on it. You can see the edit history if you like.