Gutenberg: Drag and Drop: Consider threshold of adjacent blocks when moving

Created on 19 Apr 2018  路  10Comments  路  Source: WordPress/gutenberg

  1. I think it is somehow better if it behaves following way. When you drag Block say down, and critical threshold is passed. Then block what is meant to be above dragged Block has to jump automatically above. Still holding dragged Block with mouse. Not like gray block as it is now.
    It can confuse beginners. Did I make it right ? Is my dragged Block now under, or what ?

Demo here: https://bevacqua.github.io/dragula/

  1. ~Maybe it would be better not to show Block's top toolbar when clicked / used mouse hand for dragging. And not to show top toolbar when dragging is finished, and Block is on desired place. It can also confuse beginners. Even to me personaly is a bit to much information. All I need in this moment is to change position of Blocks.~ (Edit by @aduth 2019/04/29: This is no longer valid, as the requested behavior has been implemented)
[Feature] Drag and Drop [Type] Enhancement

Most helpful comment

For a bit of context here.

I explored different solutions including live drag and drop like suggested above (and most drag and drop examples/libraries out there) in this PR https://github.com/WordPress/gutenberg/pull/16457

There's an issue that I was unable to solve and AFAIK I didn't find any concrete solution in the community (JS).

  • It's the fact that we have nested blocks and with live DnD, there's no easy way to distinguish between moving a block after the last block in a container or moving the block after the container.
  • Another challenge I had is how to keep the dragging happening if the Draggable element is unmounted/remounted. This remounting is inevitable when you change the "parent" block, for example when moving a block from a container to another.

I believe that in order to solve this, we need some design thinking and prototyping about how DnD would ideally work in different situations before moving to implementation.

All 10 comments

This was raised in today's Gutenberg triage session (link requires registration):

https://wordpress.slack.com/archives/C02QB2JS7/p1556546100056500

I've updated the issue:

  • The second request appears to be the current behavior, and is no longer valid
  • I've updated the title to reflect the proposed action for the first item
  • I've added the "Needs Design" label to prompt for design help
  • I've closed the related #13068 as duplicate

Relevant notes from #13068:

Example:

https://cloudup.com/cqIjLo3Qvrf

Example of Dropbox Paper (notice how no matter where the cursor is dragged, there is always an option to drop it somewhere.)

https://cloudup.com/cUZ-kah2W0o

Describe the solution you'd like
I'd like the blue inserter line to be present most of the time, ideally 100% of the time.

From a design perspective, this seems like a good call. It would be great to get a PR up and running and see how it works.

A major point point is that if you use the drag handles, you can't just drag straight down, as you'd expect. You have to drag down but also inwards towards the middle of the editor.

drag problems

Linking to related comment: https://github.com/WordPress/gutenberg/issues/18667#issuecomment-564505114

I'd expect that it would find the right spot to place the block without the need to drop it exactly on the thin blue line that appears between blocks. Maybe updating the UI automatically while dragging with a blank space or a translucid preview of the block (like the Dragula demo) where the block would be placed.

For a bit of context here.

I explored different solutions including live drag and drop like suggested above (and most drag and drop examples/libraries out there) in this PR https://github.com/WordPress/gutenberg/pull/16457

There's an issue that I was unable to solve and AFAIK I didn't find any concrete solution in the community (JS).

  • It's the fact that we have nested blocks and with live DnD, there's no easy way to distinguish between moving a block after the last block in a container or moving the block after the container.
  • Another challenge I had is how to keep the dragging happening if the Draggable element is unmounted/remounted. This remounting is inevitable when you change the "parent" block, for example when moving a block from a container to another.

I believe that in order to solve this, we need some design thinking and prototyping about how DnD would ideally work in different situations before moving to implementation.

Is this still relevant after the drag and drop improvements? @talldan

@ellatrix I think the main thing this issue requests is for blocks to re-order while dragging. I'm not sure if that's still really a goal or feasible.

I think it will result in content moving around unpredictably.

Some of the demos show a simple vertical list of block like elements, but blocks aren't really like this anymore. For a start they work both vertically and horizontally (buttons, social links), or in submenus (navigation), and when moving a block from one of those contexts to another, content would suddenly shift up and down as the block is removed or added to the flow.

@jasmussen What do you think?

I think there are some open questions around how drag and drop can work overall. Although many things improved with 5.5, it's still not the most intuitive, and we need a solution that allows one to drag and drop a block even with the block toolbar set to "top".

However all those aspects are higher level drag and drop issues (worth tracking if they aren't already), and I'm not sure the remaining issue, rearranging while dragging, is strictly necessary to address in the current interface, where as soon as you "lift" a block, it collapses into a chip and only gets moved when you drop it.

We tried the reorder while dragging, but it wasn't clear how it should work with nested contexts, so I think we should close for now.

Was this page helpful?
0 / 5 - 0 ratings