Size Change: +760 B (0%)

Total Size: 1.12 MB

_{compressed-size-action}

It's a really promising prototype.

The improvements that make it possible to select nested blocks (#20732) in navigation mode work really well, and I think it'd be great to see them in a separate PR so that they can be shipped more quickly.

And in terms of the Move To option, I've seen some similar systems for moving items around that work pretty well. Android TV uses a similar system for reordering apps, where an app is grabbed, moved and then dropped.

There are a few things I found in testing (though I realise this is currently a prototype, so I understand they might already be part of the thought process):

• I became easily confused over whether to use space or enter to move the block. I feel like both should be allowed.
• It'd be cool if the block actually moved as part of the visualisation.
• Some indication of when it's not possible to drop a block into a location will probably be needed, e.g. moving a paragraph block into columns isn't possible, the user has to move to the column block instead. Potentially there shouldn't even be drop zones for columns, though it may also be confusing if moving a block bypasses a level.
• Possibly some indication of when left and right can be used to nest and unnest might be helpful.

Hi @tellthemachines 👋

This is really cool! The keyboard interaction feels natural. I too have similar feedback as @talldan's:

• I was expecting enter to work, instead of spacebar. Maybe allow both?
• On a group block with two child paragraphs inside, it wasn't visually clear to me that the child block had moved outside. I think this is because there was no visual reference to compare to. Maybe if the containing block could also be somehow highlighted, this would be more obvious?

What I did was reference the block breadcrumbs at the bottom of the editor to be able to tell when the paragraph was outside the group.

Overall, this is really promising! 👍

@talldan I've addressed all your comments except:

• moving the block visually: attempted it but wasn't happy with the result. Because the block is being moved with the keyboard, the effect is very static, so it looks a bit sad/broken:

• Indication of when left/right can be used to nest/unnest: I'm not sure what type of indication would be appropriate here? But as we now have that interaction pattern for navigate mode, perhaps it won't be necessary.

@enriquesanchez I have added an outline to the parent block, when focus is in an inner block, but when a root block is focused there isn't a good way to do it - it might be a bit weird to outline the whole document. What do you think?

Excited about this PR so I took the liberty of taking it for a spin. It's really impressive, nice work!

The blue line works well, insofar as it appears to use the same style (perhaps even classname? 🤞 ) as should be visible in #21475.

An indication for the "target nesting container" can work, but I agree the dotted isn't ideal. We probably shouldn't create a new treatment for this actually — can you try simply reusing the same style we use for indicating block focus? I.e. this one:

The semantics of "focus" are a bit muddy here, since It's not actually what has focus. But it's in the same ballpark — if you press enter, that's the parent container it lands in. I think it can work.

So the difference is that you wouldn't be dragging, but instead, clicking on where you want the block to be placed. Does that make sense?

@enriquesanchez that makes sense, yes! I like how it behaves in that mockup. One question: when you click "Move to", in the mockup all the neighbouring blocks get an outline, but currently only the parent block (if the selected block has a parent) is outlined. Wouldn't it be confusing to have parent block and all children outlined at once?

Whatever we decide, I think that the improvements to mouse behaviour should be addressed as a separate PR, because trying to do it in this one would add considerable complexity to what is already a non-trivial change 🙂

I agree @tellthemachines that a followup PR to improve on mouse interaction is best.

Reading the code I am still not convinced by isBlockMovingMode returning a clientId. Can't we have two things, one that tells us we're in that mode, true or false, and one that tells us the clientId of the block currently about to be moved?

One question: when you click "Move to", in the mockup all the neighbouring blocks get an outline, but currently only the parent block (if the selected block has a parent) is outlined. Wouldn't it be confusing to have parent block and all children outlined at once?

@tellthemachines Ah, that is a great point that I overlooked. I agree with you, only the parent should get the outline. We could also try doing something similar to #22508, to make it easier to identify the block structure.

Reading the code I am still not convinced by isBlockMovingMode returning a clientId. Can't we have two things, one that tells us we're in that mode, true or false, and one that tells us the clientId of the block currently about to be moved?

Hmm, I'm not too keen on having extra return values as that will add unnecessary complexity to the code. Rather than that, I'll try to think of better naming for these functions.

Good progress @tellthemachines One nit I picked is that in both Firefox and Chrome the editor does not scroll to where you are moving focus except after the moving mode is exited by pressing the Enter key:

One nit I picked is that in both Firefox and Chrome the editor does not scroll to where you are moving focus except after the moving mode is exited by pressing the Enter key

That is a navigation mode bug, reported in #22420. It should be fixed separately. I'll likely pick it up soon if no one does it in the meantime 🙂