Create breadcrumb bar for selecting parent block

[jasmussen]

An interface referred to as "clickthrough" was recently added to make it easy to select any layer of a block with nesting. You to click through each layer, parent block first: Columns → Column → Paragraph.

While this interface is useful as page templates grow in complexity, it also gets in the way if you just want to edit the text of a deeply nested item. In #17088 an idea is outlined for how to keep the behavior of clicking anywhere in text to edit it directly, while still providing an additional way to select the layers of a block.

However there is also potentially room for a more light-weight interface for selecting block layers; a breadcrumb bar could provide a child block first interface:

The bar would sit at the bottom of the screen. It would provide breadcrumbs on the left, and the word-count on the right could absorb the "Document Outline" interface. The keyboard shortcuts for selecting every layer of a block — use arrow keys to dig through layers — would remain in place in addition to the new breadcrumb bar.

[sarahmonster]

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

The overall consensus was that this seems like might be a good idea to add unobtrusive hints like this as to a user’s current position in the document, especially when/if there’s a complex nested structure. It would be good to determine if it meets an established user need (ie, have we seen evidence that people get lost and need additional help in this context?) since that may inform how we approach adding the functionality moving forward.

We'd also like to see some more explorations here around placement and presentation. How does it work on mobile? With longer breadcrumb strings? Is it better at the top? Or attached to the block itself? How does this impact accessibility? etc.

[azaozz]

The "selection breadcrumbs" was one of the more advanced, hard to grasp, unintuitive features n the classic editor. Most users had problems understanding how to use it. As far as I understand, that was caused mostly by the UI there: being at the bottom and presented as "breadcrumbs" (which don't show most of the hierarchy).

Thinking it would be great to have this for all blocks that support nesting, but the UI should be more intuitive and with better hints. A good example of a UI that would probably work better is something like a TOC. It should present the whole hierarchy of the container block and let the user "navigate" and select any of the nested blocks. Something like:

- Parent block
  -- Child clock
  -- Child block
   --- Grandchild block
   --- Grandchild block
  -- Child block

This can be a section in the sidebar (at the top?) for all nested blocks or possibly in a "Selected block" drop-down.

[jasmussen]

Yay, thank you for the excellent feedback, both.

It would be good to determine if it meets an established user need (ie, have we seen evidence that people get lost and need additional help in this context?) since that may inform how we approach adding the functionality moving forward.

Whether the breadcrumb approach meets the need is something to explore here, whether though additional mockups, discussion, prototypes or testing. But as far as whether the need is real, it is definitely an issue that has come up both for anyone who's used the editor for blocks that feature nesting layers more than 2 levels (try columns), it's been mentioned in humorous terms on Twitter as hunting for pixels, and it's been mentioned time and again in the Github archive. I'm sure the specific evidence can be dug up or we can record a video setting the width of a column if necessary. But largely the issue has been ongoing and tracked for a long time in #9628.

That ticket also includes a number of alternate approaches outlined, suggested, and even tried. The "clickthrough" method is currently merged, and although it definitely makes it easier to select layers, it's become clear that it gets in the way of text editing, which is why #17088 has been created exploring how to add nuance to that.

We'd also like to see some more explorations here around placement and presentation. How does it work on mobile? With longer breadcrumb strings? Is it better at the top? Or attached to the block itself? How does this impact accessibility? etc.

There are a number of breadcrumb mockups in the referenced thread. There's a version in the toolbar, there's one in the sidebar, there's an alternative that features an "up" arrow, there's one in the block switcher. As I created the fresh mockups you see in this new thread, I also explored adding an additional top-bar just for breadcrumbs:

In chatting with @iamthomasbishop in random conversations about the general challenge of selecting the right layer of a nesting container, he's also suggested some configurations that feature floating action button that appears when a child block is selected, and provides a mobile-finger-friendly interface for navigating upwards. If he's comfortable sharing aspects of those here, he should be very much free. I also linked the mockups @kjellr made above, but in case he's had new thoughts since then he should feel free to chime in.

I would encourage anyone to provide additional mockups or thoughs, including how this might impact accessibility beyond the thoughts already shared. Which is, there are in place keyboard shortcuts to navigate the hierarchy — press Up in a paragraph inside a group to select the group. Or to put it differently, arrowkeys through the entire document will run through every layer. The breadcrumb bar. whether at the top or bottom, would be a region you could hop to, and items there would be tab accessible. In addition, there remains in place the block navigation tool ^⌥O, which provides a means to navigate the layers:

The reason for an additional breadcrumb tool is to indicate your nesting level visibly at all times.

[iamthomasbishop]

he's also suggested some configurations that feature floating action button that appears when a child block is selected, and provides a mobile-finger-friendly interface for navigating upwards. If he's comfortable sharing aspects of those here, he should be very much free.

Very happy to share! Without going too broad (and not knowing the full background/context of this discussion), I'll specifically address the floating toolbar that we're exploring, and @jasmussen mentioned. The general idea is to provide a toolbar that provides shortcuts to both go "up-a-level" in the hierarchy, and quick access to the equivalent of "block navigation" that is shown above (a "map" of the land, if you will). It looks like this:

Fwiw, I think this sort of UI will be useful regardless of the parent/child-first selection approach, at least on mobile. So we're starting there.

[kjellr]

There are a number of breadcrumb mockups in the referenced thread. There's a version in the toolbar, there's one in the sidebar, there's an alternative that features an "up" arrow, there's one in the block switcher. As I created the fresh mockups you see in this new thread, I also explored adding an additional top-bar just for breadcrumbs:

Yeah, we do have a lot of iterations on this now. I think it'll help to see these all in one place, so I'm dumping them all here:

---

1. In the top toolbar

---

2. In the top toolbar, but with just an "Up arrow" icon

---

3. In a secondary top toolbar

---

4. In the sidebar

---

5. In the sidebar (Alternate)

---

6. In the block toolbar

---

7. In the block toolbar (Alternate)

---

8. In a page footer

---

[jasmussen]

Thanks so much, Thomas and Kjell! Really appreciate it.

I would like to provide a little color-commentary as to why I landed at the mockup shown top of this ticket, not to suggest it's the only action, just to ambiguate a little between the pros and cons. It is important to look at this feature in a holistic context of what other efforts are underway in the editor:

• There are efforts to improve selecting blocks with deep nesting contexts (Visually indicate navigation mode, and make mouse accessible #17088)
• Enhance the tools for selecting child/parent blocks #9628 went on for a long time exploring various tools along the same line
• There have been numerous discussions around how the UI feels clunky and gets in the way when you just want to write
• And on top of that, there have also been discussions around how the UI is insufficient when you want to insert blocks or rearrange them

The breadcrumb interface has popped up numerous times, as also evident above, as a tool to let you select layers of a block. But the discussion has never really resulted in anything quite yet, because while it may help selecting those layers, in some experiments it did so at the cost of the writing/editing experience. We did try such breadcrumbs as being part of a "hover label" very early on, but this was quickly abandoned as just additional UI.

So to simplify things:

• We want to reduce UI and not get in the way when you mean to edit or write.
• We still want to provide layout tools when that's what you mean to do.
• While Visually indicate navigation mode, and make mouse accessible #17088 provides a dedicated layout tool, we also want a light-weight version nearby when you're just editing or writing.

This is where the latest suggestion, a bottom-docked breadcrumb, came from:

• It is not heavy UI — it never gets in the way yet is permanently visible.
• It replicates patterns from existing editors of a "status bar" at the bottom, word count on the right and everything.
• By being always visible, it serves as a block type indicator in addition to nesting indicator, allowing us to remove the hover label.
• It accomplishes the goal of light-weight block layer selection; just click the breadcrumb.

Given that this UI is in addition to existing UI for navigationg blocks — the block navigator at the top:

And the arrow-key nesting navigation:

The bottom breadcrumb bar would serve more as additional indicators and explicit tools recognized from file managers to traverse a hierarchy, while at the same time being very lightweight.

That doesn't mean it's the only solution, but that's the background for how that design came to pass, based on all the other ones presented above.

[paaljoachim]

Just adding this issue in here. I briefly touched upon using the label system as a breadcrumbs. As we today see the label breadcrumbs it would be great to also make it clickable: #12515

[jasmussen]

@paaljoachim this is actually what we tried way back in the day, I think in the 2.0 version era, though that was a different visual styling issue. The problem with using that was that the breadcrumbs were not available when the block was selected.

[paaljoachim]

Today we are used to seeing this when hovering over a block:

Hover over Column 1 and see the label column -> Paragraph.

The simplest approach would be to just make Paragraph and Column label clickable.
But as you mention selecting the block the label becomes hidden. What if the label was still seen when a block is nested. Perhaps something similar to...

It would keep the existing breadcrumbs label system as seen on hover. The difference is that on a nested block the label would still be seen to show the relation and it would be clickable so that the user can easily move from a nested block to the parent block. No new learning is required as it uses the existing label system. One just mentions that these are now clickable.

[jasmussen]

That breadcrumb system is one I'm suggesting we retire as being "heavy UI". It doesn't serve an accessibility purpose, and personally I find it obtrusive in nesting contexts.

[paaljoachim]

What is good about the existing breadcrumbs system is that shows the hierarchy of a block when hovering over it. What I would like to see is an easy to notice "which block did I click into now" kind of breadcrumb system. As it can be hard to notice right away if I clicked into the paragraph inside column 1 or if I have the column parent selected. Glanzing around I then hope to get the visual clue to where I am. The hint to where I am needs to be very close to the experience of hovering over a block and clicking into a block.

Looking at Inspect in Chrome.

Shows various div tags on the bottom. Showing the hierarchy.
Here is something similar in Gutenberg.

The above is brainstorming/exploration. Looking at how we can easily work in a breadcrumbs system that does not become too complex. I do not know yet, as I feel the explorations I am doing is not hitting the target yet. As there becomes too many visual elements creating a visual noise. Perhaps one needs to click something close to the toolbar (or on it) to turn on the borders of the nested and parent blocks. Turning on the border lines and whatever else would clearly show the hierarchy between the various blocks.

[kjellr]

Thanks for providing more background into your process, @jasmussen

Given that this UI is in addition to existing UI for navigationg blocks — the block navigator at the top ... And the arrow-key nesting navigation

... The bottom breadcrumb bar would serve more as additional indicators and explicit tools recognized from file managers to traverse a hierarchy, while at the same time being very lightweight.

Definitely. It's also important to consider that neither of those existing solutions are very findable though. Whatever new solution we adopt will surpass those and be the most prevalent way for users to navigate block hierarchy (next to just clicking/tapping on blocks directly).

For that reason, I do really like the bottom toolbar approach: it's pretty clear and visible. It's also based on fairly standard existing patterns. My main concerns are:

• It is another toolbar. While the treatment is light, the "boxing in" of the writing area is definitely a concern. I think in terms of UI weight, I'd prefer to have another per-block toolbar button or sidebar control than another whole toolbar on the page (if all were similarly effective, that is). We could also consider keeping this placement the same, but removing the "bar": Perhaps it's just a floating element of some sort. Then again, that's probably adding in a whole new type of UI, which may not be a great option.
• I'm also unsure if this approach would work well on mobile. We could adopt something like @iamthomasbishop's approach here too though (it's quite possible that the best solution for mobile is very different than he one for desktop in this case).

Anyway, we're getting close, and I'm really enjoying the discussion. 🙂

[paaljoachim]

We could perhaps add an unique icon on the toolbar when nested blocks are present. Perhaps something like this. Containing two outlined squares on top of each other.

One clicks the icon to see borders/outlines around each block (and whatever else). One gets an overview of the relation as well as which block one is working with. Turning outlines on and off. It could perhaps even cycle through various views. Outlines on, next stage, grid on, next stage back to normal.

It would also be good to have a setting under the 3 dot general options (top right) with a check mark to turn on outlines/borders.

[jasmussen]

It is another toolbar. While the treatment is light, the "boxing in" of the writing area is definitely a concern.

Yep, this is the constant challenge. We have this UI that we need to fit in an obvious space for the user to find, while at the same time not getting in their way. And I agree, while this spot at the bottom feels like a good place for it, it is not perfect. But what speaks in its favor is that it's an existing pattern, and it is out of the way at the same time.

We've tried to solve this problem ever since block nesting was added, and we've tried and failed with a lot of things, all of which have either just made the UI heavier, or just made it overall clunkier to use. This separate UI that we remember from TinyMCE feels like the best fit for the desktop breakpoint so far, honestly, because it leans in to the editing flow less so than the layout flow, which is a flow that we can hopefully improve vastly on its own through #17088.

I'm also unsure if this approach would work well on mobile. We could adopt something like @iamthomasbishop's approach here too though (it's quite possible that the best solution for mobile is very different than he one for desktop in this case).

I definitely think we should! It's probably a separate PR, and the clickthrough should probably remain in place on mobile until it could come to pass. But definitely.