Moving blocks on non-consecutive multi-selection.

[senadir]

related to this PR #16811

@swissspidy is working on a non-consecutive block multi select, an important question that was raised in the core editor chat by @mtias was

How would it handle “moving” once you select a bunch of non-consecutive blocks?

I started with a simple approach & a visual prototype to demonstrate it

I think they could collapse before the last selected element, so any non selected element between them will move up the selected list, it makes sense when refactoring sides of the articles to different sections

moving down:

moving up (fixed version):

I'm hoping this can open a discussion to see how we can take this design wise

[chrisvanpatten]

I like those explorations and I tend to agree — if you select non-consecutive blocks and move them (via drag and drop or buttons), I would expect them to move as a consecutive group.

The only suggestion I would have is to explore moving them as a group without the interim “place consecutively” step. In other words, your current gifs demonstrate a flow essentially like

1. Select non-consecutive blocks
2. Press move
3. Blocks join together and “outer-most block (in the direction you are moving)” stays in place
4. Press move
5. Blocks move as a group

I’d be curious to see the above, but with that third step removed so that initial move step joins the group and moves the entire group in one step.

[senadir]

it actually does but in the moving down (first gif), and that was my intention, the moving up (second gif) seems to have a problem, but then again, this was a hacky prototype done in codepen at lunch break

[chrisvanpatten]

@senadir yep I see it now in the moving down example. I love it — I think that makes a ton of sense and feels very intuitive.

[talldan]

That's a nice visualisation. I had a slightly different thought, I imagined that when using the block-mover buttons with a non-consecutive block selection, all the selected blocks would still move by one.

For example, in the moving down animation, the first time the button is clicked, 6 would end up between 2 and 4. The next time the button is clicked 7 ends up between 2 and 4.

Drag and drop is a bit harder to imagine. For that, I think all the blocks would have to collapse together as there's only a single drop destination.

[swissspidy]

Now that you mention it, that makes total sense to me! 👍

[senadir]

@talldan yes, I can see how this approach assumes that the selected element are now a group and are treated in that way, it also raises another two questions:

1. what is the use case for non-consecutive multi selection?

in consecutive multi selection, the elements are assumed to be a closely related group and are handled that way, how about non consecutive

2. what will the grouping behavior be? where will be the new group placed after grouping? first element selected? last element selected? highest element on the list? I will try to explore this in a separate issue.

[karmatosed]

Thanks for the visual. In looking at this I wonder is assuming they would all want to be grouped together an assumption that people would want? I can see why that's being made, perhaps though by selecting they are wanted to all move down the same number of blocks and maintain the order, spacing. It's a hard point as we have to decide the expected behaviour here.

[kjellr]

I think the proposed behavior above makes sense. As an (admittedly not totally related) analog, I was thinking about how this works when you rearrange something like Bookmarks:

In general, the items you select are reordered together into the same space. I think that makes sense here too.

[mapk]

I would agree with some of the other sentiments here. The way they are moving in the gifs is exactly how I imagined they would move. The gifs work wonderfully when clicking a block mover icon. When dragging and dropping they would all align together similarly to Kjell's gif above. This is pretty standard layer ordering in graphics programs like Photoshop, Sketch, etc.

[karmatosed]

If we all agree this is good, do we need design feedback on this still?

[talldan]

Relabelling. There's quite a bit of technical feedback in the now closed PR #16811, so removing that label and considering this as an enhancement request.

[talldan]

Although having said that #16797 is still open, so I think I'll close and link to this discussion.