Persistent block navigator panel

[MichaelArestad]

Now that there is precedent for a left side persistent panel with the iteration on the inserter, I thought it would be a good time to try something similar with the block navigator.

Try the prototype.

The appeal of this to me is in the ability to have a persistent way of navigating blocks in complex scenarios. I find myself frustrated with the current block navigator in that it:

• only shows a limited list of blocks
• covers the editor
• disappears when used (my biggest frustration)

I see this side panel as a way to resolve those issues. Perhaps it could even remove the need for the breadcrumb bar at the bottom.

Screenshot

Source figma file

[mapk]

Looking good!

Having a consistent location and interaction for the Block Navigator can promote stronger usage with it. This reminds me, as @enriquesanchez noted, of the Outline panel in Google docs which brings a good familiarity to it.

1. Will the sidebar width grow if nested blocks need more horizontal room? Or will it just be horizontally scrollable? Currently the new Inserter is 350px wide. Should we stick with that width?
2. The existing tree structure shows a clearer relationship between child(nested) and parent blocks. Let's keep that structure.

3. How important do you feel the Search field is here? Can we get rid of it?

Working this alongside the other Navigator improvements (ie. block movers, drag and drop, ellipses options) could make for a great experience, and removes the need to have it inline with blocks altogether. This panel is a good step in that direction.

[MichaelArestad]

Will the sidebar width grow if nested blocks need more horizontal room? Or will it just be horizontally scrollable? Currently the new Inserter is 350px wide. Should we stick with that width?

@mapk It will not grow. It would be the same width and styling as the new inserter panel. If the list gets too nested, we could explore horizontal scrolling.

The existing tree structure shows a clearer relationship between child(nested) and parent blocks. Let's keep that structure.

I didn't even realize I did that. There's no reason to change from the current design so I'll fix my mocks.

How important do you feel the Search field is here? Can we get rid of it?

No idea. Will remove for now.

[MichaelArestad]

@mapk updated screenshot, gif, and prototype.

Changes:

• removed search
• fixed icon
• fixed nesting styles

[ZebulanStanphill]

I really like the idea of being able to use the block navigator as a persistent sidebar. That would certainly make it way more useful than the current popover that closes every time you select a block.

However, there is one important disadvantage to a sidebar approach: it reduces the width of the content. For people doing site building, having the viewport width squished like this is annoying. It's alright in the context of the inserter, where you're likely to only need the sidebar open for a brief period. But the block navigator would be needed far more often when dealing with many nested blocks... especially if features like moving/inserting/removing are added to it.

A persistent, floating, and movable block navigator would solve this viewport width issue. However, this approach has its own disadvantage: the floating modal would always be covering up part of the content. Mouse/touch users could drag it to another part of the canvas, but keyboard users would not be able to do this.

Therefore, I believe the best solution to cover all use cases and solve both problems is to use a hybrid approach: a persistent sidebar that can be "unpinned" into a persistent, floating, drag-movable modal. The toggle between sidebar/modal mode could be presented as a button in the header of the block navigator (similar to the pin button in the block editor plugin sidebars), or else, the choice could be a simple on/off toggle in the Options modal. Another way to handle the switch would be drag gestures: pulling on the sidebar header could "pop" the sidebar out of its fixed position and turn it into a floating modal, and dragging it into the left (and maybe also right) side of the canvas would "snap" it into place as a sidebar.

This same hybrid approach would also be useful for the block inspector for the same reasons. As it turns out, this approach is already in use by existing page builders, including Divi Builder, Beaver Builder, and Fusion Builder (Avada).

A friend of mine has criticized the editor for being difficult to use, with one of his issues being that it is difficult to see/manipulate the structure of complex content. People he's shown the block editor have expressed the same discontent. The block navigator would be a solution to this, but he also doesn't want something that reduces the viewport width, since he wants to be able to easily see how things look at the full widescreen width on desktop. That's why he prefers Divi over Elementor.

I think that enhancing the block navigator is the key to getting more people to use it over existing page builders. I think that converting the block navigator to a hybrid sidebar/modal and adding block manipulation controls to the navigator will make the block editor incredibly more useful in the context of page building.

Side note: Divi and Beaver Builder both have online demos, so I recommend checking them out to see how the sidebar/modal behavior works in each.

[ghost]

Hello. I am going to make a similar comment as the one I did on #22319, because I created a mockup of the persistent block navigator panel positioned on the right side of the screen, which is an alternative to the proposals on this thread which show the persistent block navigator panel on the left. If you consider the hot actions of a editor being +/- reunited on the left and settings/smaller actions/block navigation on the right, I think we can achieve great ease-of-use improvements and balance between sidebars.

On #22319 I proposed bringing block panels, tabs and settings currently scattered on 2 sidebars under 1 single sidebar: on the left, because this is the sidebar closer, immediately below to the "Add Block" inserter button.

This change has one particular benefit: to free up space on the right side of the editor, to receive a sidebar related to secondary actions, in this case, the persistent block navigator panel, that handles blocks once they are added.

We can then consider moving the Block Navigator icon from the left to the right on the top toolbar, to occupy the space left by the previous sidebar icon (gear), and to represent again the sidebar below the pressed button, to avoid confusion:

The first button inside the block navigation is "Document" as an improvement on the Block Navigator, for users to achieve on it complete control over the page/nested blocks structure. Clicking on "Document" button on block-navigation-sidebar is the same as clicking on "Document" on the footer: it opens up immediately the "Document" tab on the left sidebar. Then you nave a cohesive organization of left/right sidebars and interaction between them. Isn't that great?

This change enables the removal of the breadcrumb bar at the bottom as highlighted by @MichaelArestad without losing its "Document" feature.

Persistent block navigator panel on the right, keeping its icon on the left:

[paaljoachim]

Thanks for sharing @marceloaof

Having the navigation to the right on top of the sidebar settings is interesting as it would make it possible to have the Block Inserter panel open at the same time.

@talldan added the following screenshot/wireframe here: #22319 (comment)

This adds a Block Inserter button to the bottom of the Block Navigation panel.
The question that comes up for me is where and how would the Block Inserter panel show up?

---

Here is a prototype that uses the existing methods, and in a sense extends what Michael shared. Having the Block and Block Navigator panels both persistent.
Figma prototype 2 On/Off - Inserter and/or Block nav panels

Screenshot:

Having the Block inserter and Block navigation beside each other can also make it a lot easier dragging a block from the inserter and dropping it into the navigation area.

[richtabor]

Having the Block inserter and Block navigation beside each other can also make it a lot easier dragging a block from the inserter and dropping it into the navigation area.

I'm not sure about having them both persistent, as the actual page content is mostly hidden on most viewports and you're loosing context of the page itself. What if both of these were persistent, and the settings sidebar is opened?

Perhaps the block navigator should be a part of the Settings Sidebar, beside "Document" and "Block", and if no block is selected, the navigator is the active panel (instead of switching back to "Document" or an empty block panel?

[MichaelArestad]

I'm not sure about having them both persistent, as the actual page content is mostly hidden on most viewports and you're loosing context of the page itself. What if both of these were persistent, and the settings sidebar is opened?

I share this concern.

Perhaps the block navigator should be a part of the Settings Sidebar, beside "Document" and "Block", and if no block is selected, the navigator is the active panel (instead of switching back to "Document" or an empty block panel?

That's not a bad idea. Here's a quick/dirty mockup of what I designed some time ago:

I think the biggest problems are with it is its location, the use of space, and the hierarchy. For example, it really is a document level thing so it could exist in the document Inspector tab, but then it wouldn't be visible at the same time as the block tab. If it's above both, it's kind of funky in that it's taking precedence over the items in the inspector.

I'm also hesitant to make it floating as floating items add a bit of unpredictability to the UI and also we don't yet have precedent. I'm not ruling it out, but I don't think it's something we need for a first version of this.

[richtabor]

Just running some thoughts here, but does the navigator need to be in view when editing a block? I lean toward manipulating/navigating being a separate function than editing a specific block. But if you are not selected on a block, the navigator tab is active (instead of document). 🧐

[ZebulanStanphill]

Keeping the block navigator visible while editing is useful because it makes it easy to see the complete block tree at a glance. It's like the breadcrumbs in the footer bar, but more useful, since it shows siblings and cousins, rather than just the direct hierarchy. (I think the footer bar should be removed if we make the block navigator persistent.)

[mariohamann]

@MichaelArestad Thank you for linking the issue I raised (#22319).

I would like to summarize the thoughts I have made in the linked issue, I hope that's okay:

Current Problem

1. There is a space problem due to a floating block inserter on the left side – in fact both panels (Document/Block-Settings) are never used at the same time so there is no reason why they should be both visible at the same time as @richtabor mentioned above.
2. What would be much more likely to be used simultaneously would be the Block Inserter and the Navigator Panel, so that you could drag and drop something from the Block Inserter into the Navigator Panel. As @ZebulanStanphill metioned, it is important, to see navigator and Settings at the same time.
3. In trainings I made the experience that the "Plus-Button" on the upper left side is overlooked and is even "forgotten" after hints.

Idea

1. Use a Floating Action Button to display the Block inserter to make this important interaction more visible. Place the FAB at the bottom right corner (at least every Android-User knows this place for "important" actions). Let the FAB show the block inserter instead of the settings panel.

2. Make it possible to hide the right sidebar completely. The FAB should still be visible when the sidebar is deactivated. If sidebar is closed, show the inserter temporarily as an overlay.

3. Make it possible to display the navigator permanentely in the highest possible height to make it usable. Make it possible to Drag and Drop blocks from Inserter to Navigator. Furthermore you see the "complete block tree at a glance" as @ZebulanStanphill metioned above.

More Thoughts
There seem to be different issues and ideas discussing the placement of inserter (#21080 (comment) or #21080 (comment)), menu bar (#20877 (comment)), navigator (#21080 (comment)) etc. As shown above, everything is connected and depends on other functions. I think it could be very promising to look at the relationship between these elements as a whole.

[talldan]

I still think the Navigation on the left is worth trying. The extra space is really valuable, and the extra features (Block Movers, Block Settings Menu, Block Appender) that we eventually plan to enable in the post editor would be more usable here.

I don't think the panel is something that a user would have permanently open, but it could be an occasional help when the user needs to reorganize some blocks.

I notice at the moment when opening the inserter menu on narrower screens, the right hand sidebar closes, but then doesn't reopen when the inserter menu is closed. That could be something to improve, and would make this kind of sidebar more usable.

[MichaelArestad]

Just running some thoughts here, but does the navigator need to be in view when editing a block?

@richtabor That's a good question. I would say yes because that's my primary use case followed closely by selecting parent/child blocks. That said, I may be an outlier in how I use Gutenberg.

I think the footer bar should be removed if we make the block navigator persistent.

@ZebulanStanphill Big +1 to that, but maybe in a separate issue/PR.

in fact both panels (Document/Block-Settings) are never used at the same time so there is no reason why they should be both visible at the same time as @richtabor mentioned above.

@mariohamann What led you to this conclusion?

What would be much more likely to be used simultaneously would be the Block Inserter and the Navigator Panel

I do think that could be handy, but I'm curious if folks would think to do that over dropping them in the editor. I've never tried doing something like that in any of my design applications.

In trainings I made the experience that the "Plus-Button" on the upper left side is overlooked and is even "forgotten" after hints.

I think that's a side effect of the location. Not many folks spend much time looking at that area. The same goes for the location of the floating action button. At least on web applications.

I think it could be very promising to look at the relationship between these elements as a whole.

Absolutely!

I notice at the moment when opening the inserter menu on narrower screens, the right hand sidebar closes, but then doesn't reopen when the inserter menu is closed. That could be something to improve, and would make this kind of sidebar more usable.

@talldan That's true. It's a bit of a compromise because with them both open at those screen sizes, the editor itself is pretty dang narrow. Perhaps they switch to be overlays (instead of switching the content), but that has it's own set of issues.

Thank you all for the interest and comments. I'm digging the rapid iteration and explorations taking the holistic experience into account.

[richtabor]

Just running some thoughts here, but does the navigator need to be in view when editing a block?

@richtabor That's a good question. I would say yes because that's my primary use case followed closely by selecting parent/child blocks. That said, I may be an outlier in how I use Gutenberg.

I'd say if directly selecting blocks were easier, it likely wouldn't be a primary navigation flow.

I think the footer bar should be removed if we make the block navigator persistent.

@ZebulanStanphill Big +1 to that, but maybe in a separate issue/PR.

Agreed. I don't personally find the footer bar useful as its out of context from the editing activity entirely anyhow.

What would be much more likely to be used simultaneously would be the Block Inserter and the Navigator Panel

I do think that could be handy, but I'm curious if folks would think to do that over dropping them in the editor. I've never tried doing something like that in any of my design applications.

Again, I think we're leaning towards a semi-solution to the actual issue(s). It's difficult to add blocks in-between other blocks, and its difficult to directly select blocks (mostly nested blocks). We should try to focus a bit more on the inherit issues at hand instead of adding alternative solutions such as dragging blocks into the navigator.

We should maintain that the direct manipulation of content will win out usability wise, instead of directing attention to various facets of the UI.

In trainings I made the experience that the "Plus-Button" on the upper left side is overlooked and is even "forgotten" after hints.

1. It's hard to know where the + inserter at the top left will actually add a block. 2. So many folks think this is how you add a new page (there's so much prominence to it, and no other way to add a page currently). I'd say this "+" is also a semi-solution to the real issue that its hard to add blocks where you want them. That's why I thought of Inserter: Reveal surrounding block inserters on block hover/selected states #22867.

I think that's a side effect of the location. Not many folks spend much time looking at that area. The same goes for the location of the floating action button. At least on web applications.

I think it could be very promising to look at the relationship between these elements as a whole.

I think the floating + looks great, and I like how it opens up in the same sidebar space as the settings sidebar, though again, it'll be challenging knowing where a block will be inserted on a page once you find the one you're looking for. The current solution is to find a spot, press enter to add an empty paragraph block (hopefully), then go back to the library and select your block.

[paaljoachim]

Drag and drop from inserter to post
#1511

[enriquesanchez]

I'm not sure about the use of a FAB. At least on the Web, the bottom-right corner is one of the last places most folks look at, which will make it hard to find. I imagine this would be even worse for folks with visual impairments.

In trainings I made the experience that the "Plus-Button" on the upper left side is overlooked and is even "forgotten" after hints.

I think this same effect could happen with a FAB on the bottom-right corner and probably it'll be overlooked even more.

[mariohamann]

Just running some thoughts here, but does the navigator need to be in view when editing a block?
@richtabor That's a good question. I would say yes because that's my primary use case followed closely by selecting parent/child blocks. That said, I may be an outlier in how I use Gutenberg.

+1!

I do think that could be handy, but I'm curious if folks would think to do that over dropping them in the editor. I've never tried doing something like that in any of my design applications.

I think it's a different concept for design applications, since it's usually an empty canvas with free positioning. There it makes sense to group different elements later. In design applications it still works if you do strange groupings, it may not be very scalable and may feel unorganized, but it still looks the same.
With Gutenberg it's completely different and much more structured. Especially when using child blocks or even restricted child blocks, you have to place the element in exactly the right place for it to work the way you want it to.
Example: Many blocks use child blocks, for example accordion blocks. You must insert the element into an accordion child element to have it in the right position.

But...

Again, I think we're leaning towards a semi-solution to the actual issue(s). It's difficult to add blocks in-between other blocks, and its difficult to directly select blocks (mostly nested blocks). We should try to focus a bit more on the inherit issues at hand instead of adding alternative solutions such as dragging blocks into the navigator.

We should maintain that the direct manipulation of content will win out usability wise, instead of directing attention to various facets of the UI.
The current solution is to find a spot, press enter to add an empty paragraph block (hopefully), then go back to the library and select your block.

...yes. That seems to be completely right. And maybe that's the main problem?

I think this same effect could happen with a FAB on the bottom-right corner and probably it'll be overlooked even more.

Perhaps this should be tested. Since it floats and therefore always "disturbs" the content view, it might be okay. Maybe I'll find some time in the next few days to do some tests, with people being unused and used to Gutenberg.

[afercia]

Before re-designing the Block navigator, I think it's important to know why it was originally introduced in #10545 in the first place.

Since #2031 (July 2017), then followed by many other related issues like #5694, #11581, #13663, and #15314, it was pointed out that one of the main accessibility problems for keyboard users was the difficult navigation 1) between blocks and 2) between the selected block / inspector and back. Also selecting parent / child blocks was a big concerns and, in a way, still is.

So the Block navigator was introduced mainly as a tool to navigate / select blocks meant to help all users, including keyboard and screen reader users. At the point that #5694 was closed as "addressed by #10545".

Worth noting that the accessibility team disagreed that #5694 was actually solved, though acknowledged the Block navigator was a nice-to-have. See #5694 (comment)

Discussed this issue during today's accessibility bug-scrub and the team agreed the “Blocks navigation menu” implemented in #10545 is a nice-to-have and may help in some workflows but doesn’t fully address the issue. The fundamental problem still stands, not going to reopen this issue because there's now #11581 with a detailed proposal to improve keyboard accessibility.

The main point stands though: the Block navigator was mainly meant as a navigational tool that also helped keyboard users.

In this light, I'm not sure that changing the current popover to a sidebar respects the original purpose of the block navigator, as the Sidebar pattern is way more difficult to understand and navigate for keyboard and screen reader users. This is currently being discussed by the accessibility team and I think the best place for a more in-depth discussion is #24975, focused on the new Inserter sidebar introduced in WordPress 5.5.

More importantly: the Block navigator was designed to be a simple navigational tool. That is:

• originally, it was a simple list of blocks: a <ul> unordered list
• a list is also the simplest way to semantically represent nested levels
• clicking a block navigates to the block
• that's it: no other functionality, just navigation

As mentioned in other issues, one of the limitations of the current Block navigator is that it doesn't show all the blocks (e.g. when it shows nested blocks). I guess this can be improved. My point is that the Block navigator works because it's simple to understand and to use.

I'm very, very, hesitant about the idea of adding extra features like Block Movers, Block Settings Menu, Block Appender. To me, this would defeat the purpose of providing users with a simple navigational tool. Additionally, for keyboard and screen reader users the new UI would be terribly complicated to use because:

• it lives in a Sidebar
• it shows way too many controls that are difficult to navigate with a keyboard

While I do realize the value of providing users with a UI that represents the whole structure of the content and allows several actions on the blocks, I'm not sure destroying the ease of use of the current Block navigator goes in the right direction.

To me, the idea of a "List view" suggests a completely different "mode" of the blocks list. An alternate, simplified, view of the content where users can quickly perform blocks-list-level operations (reorder, add, remove, etc.) and also edit a block content by switching to edit mode.

I know @ZebulanStanphill has some thoughts on expanding the concept of "modes" and I'd be curious to hear about them.

[ZebulanStanphill]

Great points by @afercia. I know I was initially in support of the sidebar-list-view, but having thought about it more, I now think it would be more appropriate to take advantage of the existing editor modes (also called tools for some reason right now) system. List View could simply become another mode of the main canvas area... a "List Mode", I guess. Using the main editor canvas would give us plenty of space to show not only full block titles and multiple controls, but perhaps even excerpts of the contained content.

But there are also other ways of addressing the problems that the List View is trying to solve. "Select"/"Navigation" mode already solves the keyboard navigation issue for the most part, so what else is List View trying to do?

One thing it tries to do is make it easier to move blocks in-and-out of nested containers. But there are other ways to approach this problem.

I've suggested a dedicated "Move" mode in the past, designed for moving blocks not only up or down (with full-size buttons, not the weirdly stacked ones we have right now), but also in and out of nested blocks. (Which is currently only possible with drag-and-drop.) Additionally, a "Move" mode could expand the inner padding of blocks and add dashed lines around every block to assist with drag-and-drop across various levels of nested containers. (Some page builders like Beaver Builder already do something similar.) This "Move" mode could also add always-visible labels to every block (or only during drag-and-drop), making it even clearer which block you're dragging into and out of.

The more I think about it, the more I think modes are the answer here. Perhaps once stuff like the "Move" mode is in place, we could even remove List View altogether, if we don't turn it into a "List Mode".

[mariohamann]

If someone wants to jump in with the different "mode" ideas, here are some related issues:

• While moving a block: Show border and block name of hovered blocks: (Show "ellipses dropdown options" in select mode #25275
• Show outlines of all blocks in select mode: Show outlines of all blocks in select mode #25133
• Another comment of @ZebulanStanphill related to modes: Cursor doesn't change to indicate block can be dragged #24506 (comment)
• Show block-related meta-actions in select mode: Show "ellipses dropdown options" in select mode #25275
• Finding a balance between focus on text and focus on layout: Upgrade current modes/New modes: "Layout", "Text", "Preview" #24751

And I'm sure, there are a lot of more issues, I'm not aware of. @ZebulanStanphill I will try to create a compilation of the related issues in Figma and Github in the two weeks and I would be happy if you (or anyone else!) would DM me on Slack, if you have something to add or even if you would like to join?

[ZebulanStanphill]

I'd be happy to help provide feedback on other people's issues and PRs when I have the spare time, though I'm already quite busy with a number of my own PRs trying to improve the "document settings" part of the editor.

I'd also like the note the referenced comment by me on #24506 is a bit outdated. I now don't think we should be adding any more buttons to the Select mode, since there's no way (that I'm aware of) to do it without compromising the original main purpose: to make block keyboard navigation fast and simple. Currently, you can use Tab or the arrow keys to navigate from one block to another in a single keystroke. Adding any button whatsoever would break one of these interactions. Therefore, I now believe a separate "Move" mode is the answer.

[afercia]

the referenced comment by me on #24506 is a bit outdated. I now don't think we should be adding any more buttons to the Select mode, since there's no way (that I'm aware of) to do it without compromising the original main purpose: to make block keyboard navigation fast and simple

+1 to this 🙂

Using the main editor canvas would give us plenty of space to show not only full block titles and multiple controls, but perhaps even excerpts of the contained content.

Also importantly, there wouldn't be any need for additional UIs to "slide in" in the page thus making the UI inherently more complex and reducing the space for the content. Conceptually, I think the blocks canvas that transforms itself to suit specific needs for specific flows is a pattern that better matches the idea of a modern web editor, also thinking at the future of Full Site Editing.

[Copons]

Hi folks!
I completely missed this issue, and worked on something similar to this in #28637.

Basically it's a Persistent List View, but only enabled in the Site Editor, as a way to experiment with it without affecting all the production users.
The initial PR was merged with some rough edges still to sort out (#29467 the most important), including some keyboard navigation issues (e.g. #29466).
You can check out all the next steps (as of the time of writing) with this totally clever issues filter.

The idea is to fix the rough edges, play around with it in the Site Editor, and if it feels right, we'll eventually enable it in the Post Editor as well (#29470).

[slomeli79]

Is there currently a way (even via code snippet) to force List View to always be open by default?