-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List View: Displace list view items when dragging (a bit more WYSIWYG) #56625
List View: Displace list view items when dragging (a bit more WYSIWYG) #56625
Conversation
To expand on the issue of nesting within a block, if we attempt to remove the space when hovering over to perform a nesting gesture, we can get stuck. The following is an example of this if we were to remove the space (this PR does not currently remove that space): 2023-11-29.16.17.12.mp4As a result, I think I'm leaning toward the idea of expanding over collapsed blocks while dragging as in #56579 🤔 |
Size Change: +1.65 kB (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
I'm trying to think about it in my head which is difficult, but here's what I imagine:
Kind of like one of those sliding puzzles 😄 I guess that means don't move the surrounding blocks when dragging starts. Or maybe if you have to, only ever move them downwards to create the space. |
Nice! Outside of fine-tuning the drop interactions. I did have some trouble invoking the drag and drop, though, simply clicking and dragging invokes a text selection, I have to press and hold for a bit: Getting the basics of this interaction right will no doubt be the majority of the headache, so I'll let you focus on that, but this seems to have great potential. If we can get it right, though, there are a couple of visual refinements that could be nice to do, such as the grabby hand cursor, the right drop shadow instead of the border, and a 2px radius on the dragged item. Also probably a doozy, if you are dragging an expanded tree, it would be nice to collapse that in an animated way before dragging, and then not open it on drop. |
My first reaction as well. I wouldn't expect them to move when first invoking the drag. |
Agreed, this was my first reaction as well. 👍 |
Wonderful, that's super helpful first impressions and early feedback, folks! 🙇 I'll dig in and look at that first interaction / movement when you start dragging. I'm also keen to hear what everyone thinks about the desired behaviour when going to nest within collapsed blocks, but the feedback already gives me heaps to work on, so absolutely no rush on re-testing at this stage 🙂 |
I really like the displacement!
I think it would, because:
2023-11-30.14.32.27.mp4
I do miss the line and was wondering if there could be a visual indicator of the drop zone. I just spent 30 mins trying to demo one before realizing that
Not for me personally, though I think a drop indicator would help mark the drag chip target
No transitions? I wouldn't miss them personally. |
I've pushed a tiny update, still not ready for re-testing yet, but slowly getting closer to the desired pick up and drop states. It now looks closer to all the blocks moving down to create the space. Note to self: I just need to make the first transition (from starting to drag) instantaneous rather than animated to give it the appearance of creating a space where the original dragged block was. Technically, the space needs to be half "above" and half "below" so that dragging within the space is balanced between upward and downward gestures. There's a few different ways to handle that, so I'll try out a couple more next week. For reference, here's the current state of the PR (I still need to tweak / remove the animation when starting to drag, and when performing a drop): 2023-12-01.16.25.48.mp4Thanks again for all the feedback thus far! I'll ping again once this is ready for another round of reviews. |
// const animationRef = useMovingAnimation( { | ||
// isSelected, | ||
// adjustScrolling: false, | ||
// enableAnimation: true, | ||
// triggerAnimationOnChange: path, | ||
// } ); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is commented out for now while I figure out the right way to handle smoothly moving the dragged item into its final position.
Small update: still not ready for a re-review just yet, but I've made some good progress on the behaviour when you initially start dragging. It now only moves things out of the way when you start dragging, making it altogether feel more solid (this is achieved by keeping the dragged item around, but hidden via opacity and left position, rather than 2023-12-04.12.58.25.mp4It also smoothly hides the gap when dragging outside of the list view area now. Still to be done before a re-review:
It's coming along! |
Looking good! |
Feels very nice. ✨ |
Looking really good @andrewserong!! |
Thanks for the continued encouragement, folks! Another quick update: I've merged in the prototype for dragging over collapsed blocks to expand them, and I've had a go at collapsing multiple block selections down to a single row, to make it easier (and more accurate) when dragging. I'm not 100% sure on these behaviours, and it'll most likely need a fair bit of refining. Here's how those two things are currently looking: Multiple selection dragI think it'd likely be a bit hard to use if we tried to have the dragged item be all the blocks in the selection, so for now, I'm trying collapsing the selection down into a single row while dragging. Happy to explore other ideas if this doesn't feel nice to everyone: 2023-12-05.16.36.01.mp4Dragging over parent to expandI've merged in the changes from #56579 so that we can drag over collapsed blocks to expand them. I think it still needs a bit of tweaking, but it feels better to me than without the feature: 2023-12-05.16.36.26.mp4That's it for today. I have a bit more to do before switching this over to "ready for review" — namely correctly animating the drop action when a user releases the mouse button. I think at this stage that's probably the last thing for me to implement before moving this out of draft. As always, happy for any feedback or ideas along the way, though 🙂 |
Just had a little play with this and it's very smooth. I especially love that we're now able to drop into closed containers! One thing I noticed is that if dragging multiple blocks the space where they were doesn't close up like it does with a single block: multiple-block-drag.movIs this intended? It's not terrible either way (I'm thinking if one regrets the action half way through, the space closing up means it's harder to find the previous position, but there's always undo for that so it's probably not an issue 😅 ) |
How do you make a different between dropping at the end of a container and dropping after the container. It seems that it might be a bit confusing visually to make the distinction? |
… if adjacent block has selected branch
…we can nest for any block
92d3ffb
to
c397ce1
Compare
Thanks for the approving review @jasmussen! I'll merge this in now, and happy to tweak any peculiarities in follow-ups. Let me know if anyone runs into any further issues or things that need tending to. First up, I'll look at opening a WIP PR to explore re-adding the WYSIWYG drag chip of the list view row 🙂 Thanks for all the help and reviews on this, everyone! |
Update: for anyone following along, I've opened up a follow-up PR that explores the WYSIWYG drag chip that was in earlier commits in this PR. The WIP PR is over in: #58103 It's mostly working, but I'll need to do a little more tweaking before it's ready for review. One of the main issues design-wise is coming up with a background color for the drag chip that can work in both light and dark modes 🤔 (see the PR description for demo videos) |
What?
Partly addresses: #56539, follows discussion on #56579.
Note
🚧 This PR is still a bit of a hack — for the moment, let's focus on the usability issues, we can tidy the code up later.
This PR explores one potential approach for displacing list view items when dragging within the list view. Or, to put it another way, while dragging blocks in the list view, move the other blocks out of the way.
Why?
The goal is to create a more WYSIWYG experience while dragging blocks in the list view. By displacing items, and using a drop indicator that effectively previews what the list item will look like when a user finished dropping their item, the list view should feel a bit more "solid" to use.
How?
While dragging over the list view, move existing list view items up or down to make room for a drop indicator that looks like what the block looks like once it's dropped. I.e. a drop indicator that is a bit like a preview. Details "how" follows:
clientId
containing the global index for all blocks within the list view.is-above
oris-below
classname.transform: translateY()
rules to offset the blocks so that they move out of the way. By using CSS for this, we get nice and smooth animations which disguises the fact that the dragging behaviour only really updates every200ms
. This hopefully gives the appearance of smoother drag and drop, without (again hopefully) degrading performance.To-do
Smooth dropping of list view items doesn't appear to be working in the site editorKnown issue, unrelated to this PR: https://github.com/WordPress/gutenberg/pull/57133/files#r1444129276Testing Instructions
In a post, page, or template with many blocks, try dragging up and down the list view. How does it feel to use? Also, try dragging and dropping on collapsed blocks — while hovering, the block should expand. Where do you get stuck in using this?
Try a post, page, or template with heavy nesting. How does it feel to drag to the end of a nested block, and adjust the hierarchy of where you're dropping?
Screenshots or screencast
2024-01-15.15.33.01.mp4