List View: Try expanding over collapsed blocks while dragging #56579
Conversation
andrewserong
requested review from
talldan,
apeatling,
ramonjd,
kevin940726,
tellthemachines and
a team
andrewserong
added
[Feature] List View
|
I've just done a bit of a wider ping for reviews on this one — I imagine finding the right balance of where to drag (and for how long) to auto expand collapsed list view items might feel a bit subjective, so I'll be keen to hear what folks think of how this feels to use. Very happy to explore different directions for how to achieve this, too 🙂 |
|
Size Change: +105 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
Did some quick testing:
I think we can go two ways on this one. In one avenue, we do auto-expand like this, and going down that route, this is working well for me. I might even halve the time lingering, because if you move the cursor rigthwards so the blue line already starts to indent under the parent, you've already established some intent. The main reason for potentially not going down that route, would be if we are able to do drag and drop displacement in the future. If we had that, would auto-expanding actually be intended or would that get too floaty? In the displacement use case (think moving jiggling icons on your smartphone), I would expect that adding one item into a container/group, I would drag my item on top of that container, perhaps have a blue background on the container when that's the case, and then So that's a bit of a crossroads question: would we want auto-expand if we were able to bring displacement in the future? |
I think we'd need to feel all of these details out in a prototype but I don't mind auto-expand + displacement in principle. I could see the following interactions:
The 'floatyness' might get a bit awkward if expanded groups collapsed again when you drag away, but perhaps it can just stay open until you drop? |
|
I agree with the interaction above from @jameskoster after testing this one. I don't think displacement-only is an option because it removes the ability to get into sub-nested items. I think dragging on top of a container would feel more natural, then having it expand as it does right now (maybe slightly less of a delay). I do think we need to try it out, because it might feel awkward on drop/cancellation. |
|
Sidenote: I would love to be able to press escape while still dragging to cancel the drag action. Currently it somewhat awkwardly closes the whole list view sidebar. |
Oh, that sounds like a bug. It should cancel on the first press without closing. I can look into that one separately! |
|
Great feedback, folks! Thanks for taking this for a spin. From the sounds of it, I think it'll be hard for us to make a call on this PR until we have a proof of concept to play with for displacing list view items, lots of great points there about the nuances once we start exploring that. For now, I'll place this PR on hold and switch it back to Draft mode. And separately I'll look into the following:
I'll ping again once there's stuff to play with 🙂 |
|
@apeatling, I'm not able to reproduce the issue of the Escape key not cancelling the drag mode. Here's a screengrab of how it's looking for me: 2023-11-29.11.53.54.mp4Do you mind re-testing that behaviour and sharing a screengrab if it's still not working for you? I've tested dragging selected and non-selected blocks in both the post and site editors, and while the mouse cursor is still down, press Escape and wait half a second until the drag mode is cancelled. |
|
Alrighty, I've started a proof of concept for displacing list view items over in: #56625 — it seems to be working pretty well to begin with, building on many of the different pieces we've been working on lately, so I'm pleased there wasn't too much refactoring required to get a POC working 👍 It does reveal the challenges with nesting without a drop indicator line and while displacing list view items. From my experiments so far, it's a little tricky to figure out when to move items out of the way, versus not — if we keep the space below the collapsed block, then it looks a bit weird when you go to nest. If we go to hide the space beneath, then the user can get stuck (I've added a separate screengrab of that in this comment: #56625 (comment)). I suspect we'll want to iterate further on the proof of concept before making a call either way, so let's continue the discussion over in #56625! |
I tested this again and it worked. I think the issue is the delay after pressing escape was longer than I expected and I pressed it again. What's the reason for the delay? My expectation was that it would stop the drag action immediately when pressing escape. |
Ah, excellent, thanks! I'm not sure why there's a delay, I doubt it's deliberate. I'll investigate 🙂 |
|
Update: I've done some digging on the issue of the delay when hitting the Escape key. It turns out it's a fairly complex problem and seems to be to do with the browser native behaviour of how |
Sounds good, thanks for digging in! |
|
Closing this out as the feature landed as part of #56625 |
What?
Fixes #33684
This PR explores expanding list view items within the list view while dragging over collapsed blocks.
It seeks to strike a balance between allowing a user to drag quickly over collapsed blocks, but if they linger over the bottom right side of a collapsed block (same position as if nesting within a collapsed block in
trunk), then we expand the collapsed block. It's fairly nuanced to find the right balance for this interaction, so I'm very happy for feedback on how this all works!Why?
Once a user has started dragging blocks, it can be frustrating if you have to stop dragging and go and manually click on a collapsed block in the list view in order to expand it. Also, this behaviour (expanding collapsed blocks on drag) is a prerequisite for further explorations into moving blocks out of the way while dragging, as raised in #56539
How?
insidedropPosition (this is the state for a nesting gesture in drag and drop terms) to flag that a block should be expanded.750msand is easy to change if we'd like to go with something different.Testing Instructions
Feedback requested
Testing Instructions for Keyboard
Screenshots or screencast
2023-11-28.16.04.39.mp4