List View: Try a WYSIWYG drag chip (make it feel like you are really dragging the item) #58103
Conversation
andrewserong
added
[Type] Enhancement
|
Size Change: +1.21 kB (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
|
@andrewserong great work driving this along! Can we try not having a box at all so it works in both white and dark (that's the main value of displacement, you are not lifting up but reordering), and then try to switch to the chip we use in canvas if you drag into the canvas? |
|
I'm also curious about not selecting the block when dropping it, so we remain in the "hover" state where the block outline is highlighted but it's not yet selected. It could feel lighter and go through less state changes overall. |
|
@mtias @jasmussen what do you think about a treatment more like this below? Where the list items are displaced, but only the lifted draggable block resembles the list view item. This prevents of the "ghost" item that's visible inline, and the lifted item both looking like the list item. A quick mockup below: Proposed
Current
|
|
I'm into it. |
|
Oh, both are interesting ideas! I believe we already tried not showing the text within the drop indicator for a little while in the earlier PR (from around this comment: #56625 (comment)), but happy to give it another try if we can come up with a way to solve the nesting levels problem. One of the challenges we have is that the list view needs to allow folks to drag to different nesting levels (as flagged by Riad in this comment on the earlier PR: #56625 (comment)). Previous to #56625 we signalled the nesting level via the indent of the blue drop indicator line. With that PR we now signal the nesting level via the preview of what the block will look like in its final position via the text of the block within the list view row. If we hide the preview text, then there'll no longer be a way for users to see if they're dragging to the end of a Group block or just after the Group block until they let go of the mouse cursor. In discussion on the earlier PR, the preview text seemed like a good solution for the nesting level problem. Here's the comment from @jameskoster that proposed communicating the nesting level via previewing the content within the drop indicator: #56625 (comment) — to me that was the solution that kind of unlocked displacement feeling more usable than the previous state we had. All that said, I'm happy to hack around on any of these ideas! I might see if I can set up another branch (or branches) with the ideas discussed so far, so that there's usable examples we can play with. If I don't get to it today, I'll have a play early next week 🙂 |
|
Update: I've played around with the idea from @richtabor to remove the preview within the drop indicator of the row in its final position, and to make the background of the drag chip opaque. I think I might have been overly cautious in my assessment about the nesting levels thing — with an opaque drag chip, it actually feels pretty good to me dragging to the end of a Group block, and feels more solid to me over what we have on trunk. Here's a demo of how it's currently looking now (this is the current state of this PR): 2024-01-25.15.16.05.mp4Conversely here's how it would look if we hid the drag chip and just used the displacement with the preview text in the drop indicator: 2024-01-25.15.27.10.mp4Let me know what folks think! Right now I'm leaning toward Rich's idea as it feels more solid to me in the actions of picking up and dropping the list view item. It's only hacked in for now — if we wind up liking that direction, we'll need to figure out how to style the drag chip for the dark mode (used in the Navigation menu in the site editor's browse mode) as the white background looks quite stark there: 
Thanks again, everyone (and just a soft CC to @talldan for visibility since he's been helping out with each of these PRs, too)! 🙇 I'm off tomorrow but will continue hacking on this next week. |
|
Flaky tests detected in efbee86. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7795661172
|
I think it's important to maintain tangibility by having a visible item you're "holding on to."
I would expect the same treatment as the focus state (the same rule as the light version). You're essentially picking up and putting down the list item. |
|
A combination of these last two videos could be version 1 but restricting drag on the x axis (so it's not free flowing horizontally) and make it instead snap to nested levels. |
Oh, I think that could work really nicely! Here's a quick demo of how it could look, hacked in manually (this hasn't been pushed to this branch yet): 2024-01-31.16.36.06.mp4Note: the current APIs in |
|
This looks good! |
andrewserong
force-pushed
the
try/list-view-wysiwyg-drag-chip
branch
from
4d5c6ca
to
efbee86
Compare
|
Update: thank you for your continued enthusiasm for this PR, everyone! TL;DR — I think the ideas in this PR are very much worth exploring, but I think it's likely to miss 6.5 at this stage. While the overall direction feels promising, the path to get there is nuanced and I think will probably want longer in the plugin before we attempt to roll it out into core. I've hacked together locking the x-axis to the indent level in efbee86 and it presents a couple of challenges. While the locking looks pretty good at a root level of indentation, it winds up feeling a bit jumpy / snappy when we go to nested blocks: 2024-02-06.17.33.02.mp4Also, since we now need the draggable chip to be aware of indent levels, it wasn't possible to feed that into
A couple of cons of the approach of bumping the x-axis to meet the nesting level:
I've pushed my latest attempt in efbee86, and will continue chipping away at the task. Feel free to have a play and add any feedback! At this stage, I think it's unlikely I'll be able to work through all the fine-tuning and edge cases to meet the Beta 1 cut-off for 6.5. |
Any chance we could split this presentation in a separate smaller PR then? It's much more refined than what's in trunk.
|
Unfortunately no, with the feature freeze tomorrow and the scope of changes here, I won't have time to get a PR over the line at this stage, I think it's trying to change too many things for 6.5. So far, I haven't (yet) gotten any of the prototypes with the WYSIWYG drag chip to a point of stability that I'd be comfortable with in core. While what's in trunk isn't as refined as the drag chip idea, it's still an improvement over 6.4 and is stable in terms of nesting behaviour, etc. |
What?
Follows on from: #56625, resolves: #56539
In the List View, when dragging a block, make the drag chip resemble the list row that is being dragged.
Why?
It creates a smoother experience (🤞) while dragging if we keep the thing that the user is dragging visibly similar to what the user clicked on — it means the UI has less "jump" and it hopefully feels like the user is really dragging that item, rather than an abstraction (the former drag chip)
How?
Borrow the last working state of the code from #56625
useMovingAnimationso that it always looks at the rect of where the element really isuseMovingAnimationto accept a selector for the element to match the position ofidof the element to be used for the drag chip, so that that element can be copied for the drag chip, and so that it can be referenced when animating the item in to its final positionTesting Instructions
Try dragging and dropping within the list view:
Screenshots or screencast
Light mode is looking pretty good:
2024-01-23.15.45.15.mp4
Dark mode could use some work:
2024-01-23.15.53.20.mp4