Add drag and drop in select mode

[draganescu]

Is your feature request related to a problem? Please describe.
When in select mode we can only select blocks.

Describe the solution you'd like
I would like to be able to move blocks around with drag and drop, as select mode is a great way to to layout arrangement.
Missing the bulk of UI of edit mode more screen is visible and therefore a good invitation to structural updates of a page or post.

[mapk]

+1 to this! I remember reading a comment, I think from @shaunandrews, about allowing the drag and drop function to happen by dragging from anywhere on the block in Select mode. It made sense to me.

[shaunandrews]

It might be interesting to explore the press-and-hold interaction, like from #23497

[mapk]

I created a prototype around this idea:

But if we were to allow clicking anywhere to create the drag function, we'd lose the ability to just drop right into highlighting text as it currently works.

So +1 to Shaun's comment about trying the longpress interaction.

[paaljoachim]

Using the Select Mode and perhaps also the longpress interaction could also
solve not being able to drag & drop with the Top Toolbar active:
#21407

[afercia]

I'm not sure click on longpress on the block content would be that expected and discoverable. I'd tend to think a visible drag handle would be way more intuitive and discoverable. Any argument against adding a drag handle to the block "breadcrumb" button (separated from the button itself).

[draganescu]

I've always seen the long-press as an alternative way to trigger dragging. On the other hand, being in select mode, we do not edit anything. We only need the press to be long because we want that click-through to edit behavior.

[ZebulanStanphill]

Long-press to drag-and-drop was already explored in #23497. It was found to be not feasible due to conflicts with mobile interfaces - specifically iOS, where long-press is supposed to select a word.

[mariohamann]

I like the idea of upgrading select mode as it could help a lot in different situations! I don't want to provide the feeling of some kind of "issue bombing", but again I have the feeling, that two different/upgraded modes ("layout" and "text") as described in issue #24751 would mae a lot much easier. There I described two different behaviors of long press which seem to be similar to those of @mapk

@ZebulanStanphill Selecting words on iOS only while being in some kind of "text mode" or "write mode" could work?

[jasmussen]

Here's a mockup that adds a new more legible "hand" icon instead of the "Select" arrow. It also shows how in select mode the entire footprint of the block is draggable, and adds a drag handle to the indication chip:

[afercia]

I'd agree the "arrow" icon isn't that meaningful and maybe worth exploring a better one. However, I find the new "hand" icon confusing, especially when hovering around it and when the menu is open:

I'd tend to think icons that resemble mouse cursor types shouldn't be used in the UI.

[shaunandrews]

It was found to be not feasible due to conflicts with mobile interfaces - specifically iOS, where long-press is supposed to select a word.

In the context of Select mode you can't highlight text, so I think the press-and-hold gesture actually doesn't conflict with anything there.

a new more legible "hand" icon instead of the "Select" arrow.

I love the idea of exploring a different icon — I'd even say we should rename the mode. I often hear people confuse Select mode with the idea of selecting text; Ironically enough, in the editor's Select mode you can't select text.

My first reaction to the Hand icon was that it reminds me of "panning" in most graphic-related software, like Sketch or Figma. Thats very specific to me and my background, so take it with a grain of salt.

I do wonder about an icon more associated with moving:

Maybe that's too specific to one aspect of Select mode, but its at least more obvious to me that this mode does let me move blocks.

[shaunandrews]

Oh, I wanted to point out the drag handle you show:

I think its fine, but the only way people will know its a drag handle is by moving their cursor over it — the pointer would change and I'd expect a tooltip. Otherwise, I don't think we can assume people understand that this series of dots is somehow an indicator to "drag me."

It also is very visually similar to the Cover block's position tool (not to mention the more menu):

[mariohamann]

I love the idea of exploring a different icon — I'd even say we should rename the mode. I often hear people confuse Select mode with the idea of selecting text; Ironically enough, in the editor's Select mode you can't select text.

Maybe that's too specific to one aspect of Select mode, but its at least more obvious to me that this mode does let me move blocks.

I totally agree! As mentioned above and in #24751, I think "layout mode" or "block mode" could fit better especially if this mode would get some more features in future (e. g. always showing borders of the blocks etc.)

Edit: As I proposed the modes as "block mode" and "text mode" in my very first draft, I used those icons:

The first icon (being the icon for "block mode") visualizes the idea of playing around with blocks, moving them etc. - maybe that could still fit?

[jasmussen]

I love the idea of exploring a different icon — I'd even say we should rename the mode. I often hear people confuse Select mode with the idea of selecting text; Ironically enough, in the editor's Select mode you can't select text.

I like that panning icon. That seems good to me.

I totally agree! As mentioned above and in #24751, I think "layout mode" or "block mode" could fit better especially if this mode would get some more features in future (e. g. always showing borders of the blocks etc.)

While the tools, just like tools in Photoshop, Figma, and many other layout apps, technically do invoke modes in that they change the interaction with the canvas, emphasizing the mode instead of the tool feels like the wrong approach to me. In the end you're manipulating content, whether it's text or blocks. You just interact with it differently, which is why "tools" feels more appropriate. Thank you for your energy, by the way!

It also is very visually similar to the Cover block's position tool (not to mention the more menu):

Good thought, in fact when working on #24852 (comment) I updated the icon to have the dots be closer, adding verticality to it.

Here's an updated mockup that uses the updated icon, and includes your omnidirectional mover:

[mariohamann]

I wondered how to make blocks moveable with keyboard.

Here is a - once more low fidelity - sketch (I'm so sorry for my current lack of better equipment... I'm on vacation in Denmark :)):

User flow:

1. Initial situation (while being in "Selection/Layout/Move/[...]-mode"!): Paragraph; Columns block with single columns, having a paragraph either; image at the bottom → the image should be moved to the top of the right column
2. The image block is being focused
3. A key (e. g. "M") is pressed and the block is being transformed to an inserter with the move-chip in the middle.
4. Up-arrow is pressed, the parent columns block is being focused (no inserter at the moment)
5. Return-key is pressed and the first column is being focused
6. Right-arrow is pressed, right column is focused
7. Return-key is pressed, inserter with chip at bottom of column is showing up
8. Arrow-up to move inserter to top
9. E. g. "V" is pressed to finally insert the block.

Things I'm wondering about:

1. Which are the best keys to activate the movement and to finally insert the block(s)? Do they interfere with anything else while being in Select-Mode?
2. While proceeding from parent to child: Is it better to focus the first or the last child? And when appearing: should the inserter become visible at the beginning or at the end? (Edit: I think I have to check how it is implemented in the moment when I have access to a keyboard. :))
3. How could you proceed from child to parent? shift-Return? Esc should be avoided as it should end the movement.
4. What do you think about "left/right arrow" focusing always the previous/next block and "up/down arrow" always going one level up or down? After being used to it, it could work pretty well. (Or "up/down" for "previous/next" and "left/right" for "level up/down" to make it more usable with the block navigator? again: I have to check the current implementation.)
5. The current keyboard options could be shown in a snackbar at the bottom left while movement is activated.

[mapk]

I wondered how to make blocks moveable with keyboard.

It appears we already have a way to move blocks with a keyboard. AND in Select mode, the ellipses dropdown options are still relevant, IMO. Maybe we should explore adding the ellipses options back to the toolbar in this mode too?

[mariohamann]

AND in Select mode, the ellipses dropdown options are still relevant, IMO. Maybe we should explore adding the ellipses options back to the toolbar in this mode too?

A very promising idea - it would emphasize that the selection mode becomes the mode for creating layouts and interacting with blocks (instead of text). Next week I could try to explore some designs in a new issue?

[jasmussen]

Maybe we should explore adding the ellipses options back to the toolbar in this mode too?

I don't think we can do that. The genesis of select mode was to enable you to tab to block number 5 using only 5 tab-stops. Although the tabbing interface has changed, you still press shift tab to go "backwards into the toolbar", which means if we added button controls to the select mode toolbar, that would break.

[ZebulanStanphill]

@jasmussen I think you're incorrect. In select/navigation mode, the thing your focus is on in the first place is (at least visually) a single button toolbar, which is already one tab stop and would remain one tab stop even if you added more buttons to it.

[jasmussen]

But you'd still need to be able to tab backwards to select the previous block, no?

[ZebulanStanphill]

@jasmussen Oh, I just remembered that you're supposed to be able to use the arrow keys to navigate from one block to the next as well. If the toolbars had more buttons, that would no longer work, because the arrow key navigation would be used for the toolbar.

With that in mind, you can't really have any block controls in Select/Navigation mode. So... why are we trying to fit drag-and-drop into Select/Navigation mode? I would think that drag-and-drop should be available in the same mode that provides movement controls, so perhaps we need a dedicated Move tool/mode. That would be less confusing than telling people to use a mode called "Select" to use drag-and-drop. Because Select/Navigation mode was never meant for block manipulation... it was designed for getting from one block to another in a quick and simple fashion.

[jasmussen]

Select/navigation mode was not designed just for block navigation, it was also, and initially, for selecting. Drag and drop fits that like a glove, doesn't add any tabstops, and because you'd never select text you can use the entire footprint of the block as the draggable area.

[ZebulanStanphill]

Ehhh... I don't see how drag-and-drop "fits that like a glove"; in fact, I see the opposite. Conceptually, I think moving a block has as much to do with selecting it as editing a block's text has to do with selecting it... which is to say it's not really related at all. Moving a block is an action that edits the document and changes the relation of one block to the all the others. Selecting/navigating is the user trying to get to the block they want to edit; it's not the same as actually editing the block.

The whole difference between Edit and Select mode right now is that one is for choosing a block, and the other is for manipulating the block. Putting drag-and-drop inside the select/navigation mode doesn't make sense for the same reason that putting any other editing control in the same mode doesn't make sense.

From a technical perspective, you could have drag-and-drop implemented in Select/Navigation mode without breaking existing functionality, but it seems tacked on and confusing to explain. Drag-and-drop is inherently related to the standard up/down/left/right movement buttons, and should be presented in the same mode, should it not? They're just two different interfaces for the same action.

[shaunandrews]

Drag and drop fits that like a glove, doesn't add any tabstops, and because you'd never select text you can use the entire footprint of the block as the draggable area.

I tend to agree with this.

Drag-and-drop is inherently related to the standard up/down/left/right movement buttons, and should be presented in the same mode, should it not? They're just two different interfaces for the same action.

I think you answered your own question there; Drag-and-drop and the movers buttons are very similar actions, presented with different interfaces. The main reason why I see drag-and-drop working well in Select mode is because the entire block's footprint becomes the drag handle.

putting any other editing control in the same mode doesn't make sense.

I can currently select one (or more) block(s) in Select mode and copy them. I can't paste, but I honestly think that might be a bug — I expect to be able to copy/paste and drag blocks around in Select mode with a more minimal UI.

[afercia]

Select/navigation mode was not designed just for block navigation, it was also, and initially, for selecting.

I'd argue this is not correct. The first explorations of the idea of having two block modes, "Edit" and "Navigation", were exclusively made for accessibility reasons, to solve the problem that navigating through the list of blocks with all their UIs required dozens and dozens of Tab key presses.

So "Navigation" mode, then renamed in "Select" mode, was initially designed for accessibility and then used also for other purposes.

I'd like to remind that allowing keyboard navigation from one block to another with just one key press is the main goal ov Navigation/Select mode. Adding more controls, so that the tab stops amount would increase, would defeat its purpose.

I love the idea of exploring a different icon — I'd even say we should rename the mode. I often hear people confuse Select mode with the idea of selecting text; Ironically enough, in the editor's Select mode you can't select text.
My first reaction to the Hand icon was that it reminds me of "panning" in most graphic-related software, like Sketch or Figma. Thats very specific to me and my background, so take it with a grain of salt.
I do wonder about an icon more associated with moving:

For the reasons above, I'd totally agree on renaming the "Select" mode. To me, "select" doesn't make much sense. This is a mode where the list of blocks is presented to users without the blocks UI, in the simplest possible way: a "barebone block" with just one actionable control. I'd tend to think the concept that can better illustrate this mode is a list.
I don't think the moving icon would be appropriate because, again, the main goal of this mode is keyboard navigation through blocks.

emphasizing the mode instead of the tool feels like the wrong approach to me. In the end you're manipulating content, whether it's text or blocks.

I never fully understood why Edit an Select are considered "tools". To me, a tool is a specific instrument that I can use for a specific purpose. Instead, Edit and Select are modes that provide users with several tools. Also, the button that opens the menu is labelled "Modes" but then the descriptive text at the bottom of the menu says "Tools offer different interactions...". To me this is inconsistent.

why are we trying to fit drag-and-drop into Select/Navigation mode?

I'd agree that conceptually drag-and-drop doesn't fully belong to Select mode but I wouldn't be opposed to add it as an "enhancement" for mouse / touch users.

[ZebulanStanphill]

I suppose as long as we don't rely on using Select mode for drag-and-drop, it's okay to add it as a bonus enhancement. But it's not the appropriate "primary" interface for the feature, in my opinion.

I think the "Modes" versus "Tools" labeling inconsistency was caused by #24304. It was previously "Tools" everywhere. I agree that "Modes" makes more sense, however.

[draganescu]

Closed by #28815