Show block breadcrumbs for selected block when inline toolbars are enabled

[ZebulanStanphill]

Issue Overview

Currently, navigating from a parent block to a child block and vice-versa via a mouse is not as easy as it could be, and if #6408 is merged, then it will become even harder. Currently, the title of a block is shown when you hover over it, and a button to select the parent of that block is shown as well. However, once you select the block, that title and button disappear. The block title is at least shown in the inspector, but the "Select parent block" button is nowhere to be found.

I propose that when the block toolbar is set to be shown inline, the block breadcrumbs are shown in the top bar of the editor. This would make good use of the otherwise unused space while also making nested block navigation easier for mouse users.

Of course, this raises the question of what to do when the block toolbar is fixed to the top bar. My suggestion for that scenario is that hovering over the currently-selected block shows the block title and "Select parent block" button. (These would both be hidden while typing and when the block is not being hovered over.)

As for touch input and mobile, I have no idea what to do there... the hover title and "Select parent block" button are currently not usable there anyway right now since there is no hovering with touch input.

Mockup

Here is a very quick and rough mockup of what the block breadcrumbs could look like. You would be able to click the titles of the parent blocks to select them. Perhaps each level in the breadcrumbs could even have a dropdown menu to select between all the sibling blocks at that level.

[karmatosed]

Firstly, I do agree there can be a problem of discoverability in child blocks. That said, I do not feel adding a breadcrumbs indicator to the top like this resolves that.

One reason I say that is there are a great many users like in this image who use the toolbar by blocks. When in a child block their view is 'there' not above. Another issue is being beside the information icon throws the meaning. What does it stand for? Breadcrcumbs do a very specific UI job and this isn't being used for that exactly. I get you're adapting it but for many this could cause a little hitch in the experience.

I would recommend we look at other ways to solve this issue.

[ZebulanStanphill]

@karmatosed Those are good points. Here are some other ideas:

• Show a link to select the parent block in the Block inspector above the block title/description.
• Always show the "Select parent block" button in the block toolbar in the spot where the block transform button currently is (but will soon be removed by Removed block transforms from the toolbars. #6473).
• Add "Select parent block" as an option in the More Options ellipsis menu.

Which of these do you think would work best?

Side note: the breadcrumbs being next to the information icon may not be relevant as that feature may be moved to the right side of the top bar and change to use the plugin sidebar/pop-up APIs in the future. See #4287 and #6278.

[chrisvanpatten]

I actually reeeeally like the idea of breadcrumbs. Maybe the traditional look of breadcrumbs isn't the best, but I think the underlying issue — an easy way to visualise a block's context — is going to be very important as things like the potential Section, Row, Column, etc. blocks come into play that involve nesting.

Even cases like the theorised "slideshow" block with "slides" inside could benefit from this, especially if you imagine a world where the slides are themselves a container for arbitrary blocks.

What about using the block inspector for this?

Another idea could be a dedicated panel that visualises the block nesting hierarchy using a UI similar to the Document Outline panel:

Block Hierarchy is far too technical a name (perhaps Block Parents? or Block Nesting? Hmm…) but that could be iterated on.

[ZebulanStanphill]

@chrisvanpatten Both of those mockups look pretty neat! The first one seems like it would be quickest to use, but the dedicated panel is probably the more flexible idea (though both could be implemented).

Actually, I think the dedicated panel idea could be expanded some more. There could be a dedicated pop-up/modal/sidebar that could show the complete block hierarchy of the entire post. It could be accessible from the ellipsis menu in the top bar but pinnable to the top bar next to the Document/Block Settings icon (since it would presumably use the plugin sidebar/modal/etc. APIs.

[karmatosed]

Thanks for exploring this @chrisvanpatten. I feel that we still have perhaps the discoverability and disconnect issues when it's in the sidebar? The sidebar is meant to be for 'secondary settings' of a block and this kind of doesn't fall into that as a pattern.

I also would caution against the weight of adding another panel or dedicated area. To go back, what issue are we trying to solve? If it's one of discoverability and knowledge where you are, does a panel to the side really do this? When would that panel open to be discoverable? If that panel is open does it then impact negatively the discoverability of other settings?

[chrisvanpatten]

I think for me the core issue is that navigation around nested blocks is cumbersome without context. So far, most of the navigation solutions (such as what's being worked on in #6471) don't include context about where you are, what you're moving to, etc.

That said, I really like what I'm seeing in the try/alternate-hover-approach branch (which doesn't have a PR yet, I think?). It does a great job of surfacing what you're looking at and how it relates to the blocks around it.

[jasmussen]

That said, I really like what I'm seeing in the try/alternate-hover-approach branch (which doesn't have a PR yet, I think?). It does a great job of surfacing what you're looking at and how it relates to the blocks around it.

🎉

It doesn't have a PR yet because it's super duper work in progress, but glad to hear you like the initial work. I'll keep pushing some changes to make it more presentable, and then PR it when I feel it's ready for more eyes. Until then we're in stealth mode :D

[mtias]

Going to close this as the new outlines / hover styles surface the breadcrumb. If we think another layer is needed, we can revisit.

[ZebulanStanphill]

@mtias I think @chrisvanpatten's mockup would still be pretty useful in situations where the parent block is the same size as its children, like the aforementioned example of a slider block with slide blocks as children, or a section block with no inner paddings which contains a columns block.

As things currently are, it is easy to tell the block you are hovering over and what its parent is, but it is not necessarily always easy to select the parent. Recent hover outline changes have helped make this less of a problem, but there are still cases where the clickable are to select a parent block are rather small, sometimes only consisting of a small sliver of padding on the top and bottom, with no place to click on the sides. (This can be seen when you have a Paragraph nested in a Columns block nested in another Columns block; the Paragraph extends to the left-most edge of its direct parent.)

Breadcrumbs in the sidebar inspector would help negate this issue on both desktop and mobile. (In some cases using the breadcrumbs in the sidebar may be the easiest way to select parent blocks on mobile.)

[jasmussen]

@SuperGeniusZeb

useful in situations where the parent block is the same size as its children, like the aforementioned example of a slider block with slide blocks as children, or a section block with no inner paddings which contains a columns block.

In what situations would that be? A recent refactor to the block paddings (visual only) mean that parent blocks will always have a wider padding than nested blocks, exactly to make sure that it's easy to select the parent.

[ZebulanStanphill]

@jasmussen I am talking about situations like this:

This is a Paragraph block nested in a Columns block nested in a Columns block. The nested Columns block is barely clickable as its children extend to its borders on the left and right. There is still some space left on the top and bottom, but it is rather small and hard-to-click, and I was not sure if that space would always be there or if that was just caused by padding that actually takes up space. Could you clarify on what kind of padding that is on the top and bottom?

Notably, the outermost Columns block is always easily clickable, as its visual-only paddings extend far enough beyond the borders of its children on the left and right.

[jasmussen]

Indeed, thank you for clarifying that. I'll definitely take a look and see if I can improve things there, but this may also be one of the situations where a full fix won't arrive until the customization phase.

Also wrote some tangential comments in #7414 (comment).

[jasmussen]

Coming back to this, although we have a solution in master that is good for top level parents and immediate nested children, it's becoming clear that as soon as blocks start to nest more than one level deep, the interface can sort of fall apart. While it also seems a noble goal to try and avoid deep nesting as much as possible, there's no doubt that plugins can do things here we need to accommodate. Even before that, a paragraph nested inside a quote inside a quote is not an uncommon use case.

We have a solution for keyboard users — arrow keys traverse the block tree, and a solution for mobile — first click selects the parent, second click selects the child and so on. But it seems prudent to reconsider a good solution for desktop users.

Although not ideal, breadcrumb trails does seem the way most applications have solved this, including Illustrator, TinyMCE and others.

One of the downsides of showing breadcrumbs only in the sidebar is that you can toggle off the sidebar and not see them, or you might be using a different sidebar provided by a plugin.

Is there a design that has us keep the breadcrumb in the block toolbar itself? Here are a couple of mockups. In this mockup, a paragraph inside a quote has been selected:

In the next one, the user clicked the small quote icon next to the switcher to select the parent:

The ultimate goal in explorations here should be to make it simple and obvious how to select the parent block in nested contexts. Padding buffering as we have in master is fine for the top level, but we need a solution for deep nesting also.

[jasmussen]

Here's another mockup that shows an "Up one level" button, instead of a breadcrumb:

[folletto]

I think there's a solid benefit in having something in the toolbar as it manages to scale well regardless how crowded the nesting can get.

Iterating on the latest ideas above, and trying to incorporate both an accessible way and also show the full hierarchy as pointed out by Chris, what if we shift slightly the mental model of the dropdown from "Transforms" to "Chip Actions"?

Here's the idea that combines Chip and Breadcrumb:

I think this could be a viable approach as with one click the full hierarchy becomes accessible, allowing easily to jump to any level of it, and at the same time it doesn't add extra elements to the toolbar.

Even if we want to still include the "Back" approach as the latest mock above, the two approaches can coexist.

[karmatosed]

I really like the idea of chip and breadcrumbs combined. This makes the dropdown section the block interaction point and really works well. This approach also avoids the visual clutter and complications of surfacing.

My issue with showing block chips together as breadcrumbs really comes down to using something for a different meaning. This chip and breadcrumbs option solves that.

[chrisvanpatten]

I really feel like text labels are a necessity — or at least should appear on hover — but that does seem like a good placement.

EDIT: And maybe the block chip you're hovering would have its corresponding block outline appear?

[ZebulanStanphill]

@folletto I am confused about what exactly “chip” means, but I really like that mockup of putting the block hierarchy in the same spot as the style variations and transforms. I agree with @chrisvanpatten that there should be at least labels on hover for accessibility. Additionally, I think the hierarchy should have a header that says “Block hierarchy” or maybe “Select parent”, since the block style and transform sections have headers, and also to make it more clear what it is.

[designsimply]

@SuperGeniusZeb a block chip is the little icon that represents the block type (e.g. columns, quote, or paragraph) and they are used in several places such as the block library, block toolbar (can be used to change a block type), and in the block settings sidebar next to the block description.

[westonruter]

As I've commented on #7694 (comment), facilitating blocks being nested 3-levels deep is something needed for implementing blocks for the AMP Story format. It consists of nested structure as follows:

We've found it difficult to be able to select the desired ancestor blocks. The issue could be even more challenging in the case of AMP Stories because the amp-story-grid-layer blocks will need to be layered on top of each other, so they they'd be arranged via z-index not spatially by x/y coordinates. We've considered that when selecting an amp-story-page that the list of layers could be presented in the sidebar, and that upon selecting a layer you could then select and edit the blocks inside of it. The sidebar is also how such layered blocks could be re-ordered in the z-index stack.