User testing - Block settings hard to find

[webtrainingwheels]

Issue Overview

Block settings not intuitively findable.

Current Behavior

Throughout Gutenberg, when I mouseover or click a block, things change on the screen - a toolbar appears at the top, or symbols appear on the side.

However in the right side panel, Document settings are the default and that doesn't change when I click a block. Since the interface trains the user to find the toolbar at the top of the screen, one probably won't intuitively look to the right and click on Block to discover more controls.

Expected Behavior

While I actually hate that so many things move and show as I mouse around the screen (feels disruptive), I feel something should be happening to indicate Block settings exist. Perhaps Block settings should be visible by default when writing/editing content, instead of document settngs?

Or perhaps the content from that tab should be elsewhere? I don't know why I have controls for block content at the top and at the right of the screen.

[mtias]

Originally the inspector was focused whenever you selected a block. We changed the behaviour because people find it confusing. It might be worth revisiting after all the UI and interaction changes.

cc @jasmussen @karmatosed

[afercia]

See also #1182

Now that there are ARIA landmarks and the Ctrl+backtick to quickly jump through the main Gutenberg sections, is there still the need of the "cog" button?
Also, if the "navigation mode/edit mode" interaction model gets stable and if actual testing proves it's an improvement, maybe worth considering some smarter way to switch the sidebar?

[karmatosed]

I would +1 trying in a branch some indication of block settings in the inspector.

[jasmussen]

The inspiration for the Block Settings sidebar has been the Chrome inspector, as well as contextual sidebars like those shown in Sketch or Keynote.

As Matías alludes to, initially we would show you block settings if you had the Settings sidebar open, and then simply clicked a block. The idea being that at the document scope, you saw Post or Page settings, and in the block scope, you saw Block settings. By being completely contextual, all you had to do was select a block and you'd see the settings for that block, just like you would in Sketch or Keynote. But as Matías also noted, people found this either confusing (why is the sidebar changing all the time?) or annoying (same sentiment but with a ! instead of a ?).

Our solution was a tabbed sidebar. It's still a single sidebar that contains Settings — both for the document, and the block.

It's worth asking the question: how discoverable does this need to be? In the Chrome inspector, you can right-click any webpage and click "Inspect", and you immediately get into this advanced interface with contextual tools for analyzing the webpage. This is not so different from how it works in Gutenberg now, except you press the ellipsis menu to find the "Inspect" option.

Combined with design principles that state that you should never put anything into the sidebar that is necessary for the basic operation of your block, perhaps it's okay that it's a "power user feature"?

One of the benefits of having a separate tab for Block settings I just posted mockups for in #1224 (comment).

Would a better label for the action in the ellipsis menu be a good first step? Instead of "Settings", perhaps "Block Settings" or "Advanced Block Settings"?

Another idea I'm not too convinced of is an "unread" dot:

We also have a different layout for implementing the mover/trash/ellipsis on mobile, which we may expand to desktop as well, which could hold some potential for new ideas:

[afercia]

One thing I'd consider first is to try to improve a bit the tooltip text for the ellipsis button, as the "menu" doesn't contain just settings but also actions. Also, I'm not sure users should know what a "menu" is, so I'd try to rephrase omitting the word "menu".

The "dynamic" text in the tooltip made me think to the pattern used for many menu items in macOS where the label changes depending on the state. For example:

• Finder > View > Show View Options
• FInder > View > Hide View Options

So, in regard to the Settings menu item, would making it "dynamic" help? Perhaps, this could also help to solve the issue this control "does nothing" when the Settings sidebar is already open.

Would a better label for the action in the ellipsis menu be a good first step? Instead of "Settings", perhaps "Block Settings" or "Advanced Block Settings"?

• "Show Advanced Settings": would open or switch the sidebar to the block settings
• when open, the menu label changes to "Hide Advanced Settings"
• clicking "Hide Advanced Settings" closes the sidebar
• in the responsive view, the label change wouldn't matter so much because the open sidebar is a full overlay

From an accessibility perspective, I'd consider to keep things simple and not try to move focus or do fancy things. When clicking "Show Advanced Settings" users just need to be informed about what happened, they already have the tools to move to the Sidebar. Maybe a simple audible message would be enough, something like "Additional advanced settings are now available in the Editor settings sidebar".
Then, it would be important to think to a better label for the ARIA sidebar region, which currently is aria-label="Editor settings". Maybe something like aria-label="Editor advanced settings" ?

[jasmussen]

Those changes sound like stellar first steps to me.