Reordering of blocks inside block navigation

[earnjam]

Similar to #5301, it might be nice to be able to move blocks up and down by dragging to reorder inside the block navigation menu.

The most obvious downside to this I can see is that it's not necessarily clear which block is which, but it could help with things like left/right aligned images which can't be moved after their alignment has been set to either side.

[ZebulanStanphill]

I think this is a duplicate of #10918, but this issue is clearer, so maybe the other one should be closed in favor of this one.

Oxygen has something like this:
https://oxygenbuilder.com/documentation/visual-editing/editor-overview/

Elementor also has something like this called Navigator:
https://elementor.com/blog/introducing-navigator/

Divi has something similar as well called Wireframe View:

So I think it would be a great idea to add this kind of functionality to Gutenberg.

[garciaalvaro]

In this plugin it is addressed this, being able to drag blocks from the navigation and show an initial snippet of the content (to easily know which block is which).

[jwold]

For this issue, perhaps combined with the sidebar issue, having a bit more room might allow for an interface where we could have a dragging icon (similar to how Gutenberg blocks work today), to make it obvious that the elements can be draggable. And, I'm guessing makes it more accessibility friendly.

cc @afercia

[karmatosed]

I took a little bit of time to explore this. I ended up looking at what we have now and then what possible other iterations from plugins could be used.

I found the Block navigation plugin here:https://wordpress.org/plugins/block-navigation/

Now, this takes it all to the sidebar which I understand but I don't think we need to travel that route or at least I wanted to explore what could happen in the UI we have now.

Moving on from our current UI, I began to explore what could be. I'll note there are some gentle adjustments in these sketches, but I am exploring what could be.

On targeting the block (tab, click, keyboard or mouse), movers show up. This will need iteration, testing and work, but is based on existing iterations and patterns.

One possible edition would be having opening/closing for child blocks:

The Block Navigation plugin has a more complex menu, I think having it simpler makes sense but throwing into mix of ideas just incase.

A few potential points here and I stress this is at early stage of sketching, I wanted to put something out though. If all this does is serve as fuel for better ideas, that's great. It does mean we might have to increase the navigator size to make sure the movers aren't too tiny to interact with.

This design does open up to being used for navigation, a pattern discussed in #16974

I am going to loop in a few people to get some feedback on at least the idea here and add a lable too. cc @mapk @mtias @jasmussen

[sarahmonster]

The design team discussed this during a triage session in Slack today (Note: You may need a Slack account to log in.)

For this functionality to be effective, we need a few different pieces:

1. Better identification of which block is which (ie, snippets of the text rather than just the name of the type of block, see More detailed list inside the Block Navigation #11010)
2. A way of clearly visualising and understanding nested structures, so that users understand where they are in the hierarchy at any given time, especially when there are multiple levels of nesting. (This becomes more relevant when the pattern is applied to other blocks, like the navigation menu block.)
3. A mechanism by which users can rearrange items in the list.

Let's start by focusing on #3, although it seems as though we may need to address #2 here as well, which it looks as though some of the explorations above are addressing.

Right now, we're seeing the controls used to manipulate blocks in Gutenberg are proliferating. In addition to the "standard" move controls, we also have:

• horizontal movers (Navigation menu block: Explore horizontal move controls #17093)
• full-wide block movers, which are a slight variant on the standard vertical movers
• potentially a new pattern for the gallery block as well (Align Gallery block movers with the standard block mover style #17316)

Let's try to use an existing pattern here, so as to avoid introducing yet another variant of the same pattern. In the design chat, we identified that following the full-wide movers pattern might be our best choice, if they'll fit in the available space.

Let's see what that might look like:

This could be a good approach since it wouldn't require us to reinvent the wheel here and introduce another new pattern for the move functionality. We'd want to test it to be sure that it's accessible for users on mobile devices, assistive devices, and users who have motor control issues (the touch targets are a bit small, but if we've tested them and found them usable for the full-wide block this shouldn't be an issue here).

[mapk]

@sarahmonster, I do like the full-width block movers here, especially for the reasons you've stated. These movers are for moving "blocks" whether you're in the editor or the Block Navigator, so it makes sense.

Along with the a11y label, maybe we can bring this up in this Friday's Accessibility Team meeting in slack too!

[sarahmonster]

👍 It would definitely help reduce complexity, both of the user experience and in terms of development cost, if we can reuse an existing pattern here. Let's make sure it doesn't present an accessibility problem and then see about exploring how it might work with nested and super-nested structures, but from an initial exploration it looks as though the existing pattern should be able to support this pattern relatively easily. 🤞

[karmatosed]

For me, I am 👍 on full width and that's totally what I explored in my iterations, so totally agree. How would this wrap-around text, specifically longer blocks or translations?

[jasmussen]

How would this wrap-around text, specifically longer blocks or translations?

Speaking of

I would say that the mover stays where it is, and the text wraps. I.e. top right corner has the mover. Ascii mockup:

__________
Text label that               [mover control]
wraps to two lines

Another text label            [mover control]
__________

[mtias]

This is looking good. Can we try a case where we don't need the drag handle and the whole item is draggable instead?

[sarahmonster]

Text wrapping

Let's take a wee look at our options for text-wrapping first:

The wrapping option could be improved, visually, with a different line-height setting, but we'd be deviating from the typical line-height used by elements, which is definitely something we're trying to get away from, as it creates visual inconsistency and disharmony in the vertical rhythm of the page.

Questions to consider here:

1. Since the navigator pattern isn't intended to be used to edit text, is it neccessary to show the entirety of a text label to users here?
2. How do we handle wrapping in the navigator right now? Can we extend the pattern when the movers are shown, and rely on the rest of the text being shown when the movers are gone?
3. Should wrapping behaviour change between the selected (movers shown) state and the unselected (no movers) state?

Drag handles

I love the idea of simplifying the complexity of this component by removing the drag handle, but I'd definitely be careful with that sort of change. It means that we're effectively introducing yet another move pattern to our collection, and we're changing how drag and drop works. We've taught users to look for those dots as a signifier that an element can be dragged, and without it, they may not understand that an element can be dragged.

Here are two different approaches: one with no visual signifier at all, and one with a signifier that's more common to web applications and apps: the drag handle to the left of the text.

We might want to usability test any new pattern here with existing Gutenberg users, to ensure they can easily find and understand the drag behaviour.

[Mahjouba91]

Definitely a +1 on this, it would be a really nice feature to have.

[ZebulanStanphill]

Divi just got a new Layers View, which is even more similar to what the Block Navigation UI could be updated to include:

https://www.elegantthemes.com/blog/theme-releases/divi-layers-view

[ZebulanStanphill]

Linking #20719 (comment) here as I think it is quite relevant to this discussion.

Similar to the feelings expressed in the linked post, I also tend to forget that the Block Navigation exists, partially because it only really has one use right now: selecting blocks in nested contexts. I really think the Block Navigation could be expanded to be way, way more useful. I very highly recommend looking at what Divi has done with their new Layers View feature. The Block Navigation menu could become a simple alternative for moving blocks in and out of complex nested contexts.

I've heard of several people complaining about the lack of clear borders on parent/child blocks in the block editor. They want to be able to clearly see the hierarchy of blocks. I don't think the solution is to add visible borders/padding to everything; we already tried that and it made the UI overly jumpy and complex.

I think that the best solution to this problem is increasing the functionality of the Block Navigation menu. It could become the prime interface for viewing the block hierarchy and moving stuff across the page, without the content getting in the way.

The Block Navigation interface could even become pinnable as a sidebar, providing desktop users with a clear view of not only the immediate parent blocks, but also all nearby children and sibling blocks.

I also think the Block Navigation name is a bit confusing since we have a block called Navigation. The name does technically make sense at the moment, since block navigation is all you can really use it for, but I think a name like Divi's "Layers View" would be better suited for the interface if it was expanded with more useful functionality.

[noisysocks]

For WP 5.5 let's focus just on being able to reorder blocks within Block Navigator using buttons. We can add drag and drop later. #18014 does this.

[ZebulanStanphill]

Since the movers currently only exist in the Navigation block's special version of the Block Navigation interface, I don't think this issue should be closed yet.

[talldan]

@ZebulanStanphill Thanks for pointing that out @ZebulanStanphill, I've made a separate issue #22287 to cover enabling them in the main block navigation.