Tabbed interface for Document/Block Settings sidebar is confusing

[ZebulanStanphill]

Tabs no longer make sense

The Settings sidebar uses tabs to switch between the document settings and the settings for the current block. However, this UI choice no longer makes sense. When you click the Document tab, the current block is unselected, and when you try to go back to the Block tab, it will just tell you that no block is selected.

It is confusing that the Block tab is still shown even though it is contextual and only has use when a block or multiple blocks are selected. One would think that a solution to this is simply hiding the Block tab when no block is selected. But what this does is make the interface even less tab-like.

So why are tabs still being used? They really do not fit this situation. It made sense to have the tabs back when blocks were not unselected when you switched to the Document tab, but now the tabs do not function as tabs. Something should change in the UI here.

My proposal

My proposal is this: use a breadcrumb-ish navigation for the Settings sidebar. Now, I know that a breadcrumb-style nav was used way back in the early versions of Gutenberg but was replaced by tabs; but back then it made sense to change to tabs because of how block selection remained when switching between them. But it no longer makes sense.

I also think a breadcrumbs approach would help solve another issue: accessing the settings of parent blocks. There are situations where selecting the parent block can be tricky. For example:

The above situation may be fixable with further improvements to the hover outlines. However, the problem may still exist for mobile users (where precision is a lot worse due to touch input as opposed to mouse input). And what about situtations where it is desirable to hide the visible UI of certain nested blocks? See #7414 and #7469.

A breadcrumbs interface (or something similar to one) may be able to at least partially solve these issues. Imagine something like Document → Section → Columns → Column → Paragraph. You could move up the hierarchy to easily select any of the parent blocks and access their inspector settings. This would be a lot easier to use on mobile than having to tap in the right spot between block borders, and would allow for block borders to be hidden in some cases to reduce visual weight while still providing a way to access the parent block.

Of course, the obvious issues with this approach are that breadcrumbs can look pretty bad if implemented in the wrong way, and they would have to be made obvious enough so that people would know where to click to get back to the main document settings.

Here is a GIF from version 0.3 showing what the old breadcrumb UI looked like:

I think the biggest issue with this UI was that it was not obvious that the breadcrumbs were a place you were supposed to click on to get to the document settings. Perhaps something like this would be better:

(Mockup made using this GIMP and this image: https://www.sketchappsources.com/free-source/attachment-1864-helium-ui-kit-sketch-freebie-resource-img1.html)

Breadcrumbs may also not be the only thing that could replace tabs. Other UI bits relating to hierarchy that come to mind are things like this in the Customizer:

I know it is pretty late to bring this up so close to the feature freeze in preparation for the merge proposal, but I thought I should point it out anyway, even if it ends up being discussed much later after the WordPress 5.0 release.

Related issues and PRs

• Opens the block inspector automatically when the block is selected #5882
• Show block breadcrumbs for selected block when inline toolbars are enabled #6459
• Locking a Block and Block Outlines #7469

[karmatosed]

Whilst I understand the motivation in this @SuperGeniusZeb right now this isn't an issue for many people using Gutenberg. I truly don't think breadcrumbs solve the problem this time. They are one technique that work well for actual breadcrumbs within content but they wouldn't here.

As there is already an issue exploring an alternative let's have the discussion there in #6459 (comment) and close the discussion here. We are all going to get a little confused having the same discussion in a few places.