Exploration: moving options

[karmatosed]

The toolbar does a lot right now, the right side specifically is a quite intense combination of different interaction types.

• Yellow: status
• Blue: publishing actions
• Red: sidebar / settings
• Green: options

It makes sense to me to explore reducing this. For now, I wanted to start by examining where options could go.

Reducing back to positions, the following graphic shows how they fall right now:

• Top left: block library
• Right: forward-moving actions such as publishing
• Bottom right: a proposed new place for options

The new position I wanted to investigate draws on other apps such as Figma, which uses a drawer for keyboard interactions.

A little note, the work explored here does bring in some elements from #18667 to see what could be. Specifically, the pop-menu uses the style from that Figma file.

This moves options to the bottom and has the same icon. It could be great to explore what icon works here. I think some options could be:

Another option is a smaller strip.

Other panels could be:

I explored a full panel that is open, it could reduce back to a menu and modal that we have, however, I think to grow this and be more useful progressing past the modal could be worth exploring, particularly as this opens to extensibility.

What do people think? This is very early-stage sketching out the idea for now so would welcome some feedback.

[shaunandrews]

I think moving editor-related settings to the bottom-right makes a lot of sense. I'd push to continue exploring with a menu, rather than a full pane with tabs and the like — the pane is just way too much UI for what should be a really simple thing.

I think the ellipsis icon should likely still live at the top-right though, and should be focused on plugins which add their own sidebar — think of it like an overflow menu for icons that open sidebars.

With that said, I think a cog or wrench icon could work for the editor settings on the bottom-right. And we could change the current inspector sidebar icon to an ( i ) info icon, removing the current document outline icon.

Here's a visual explanation of the above:

[shaunandrews]

Changing the current document/block inspector icon might be too much. I explored using a different icon (wrench) and a simple text label for the bottom-right editor settings as well:

[karmatosed]

A variation then could be to rather than have modal take this approach:

[melchoyce]

Changing the current document/block inspector icon might be too much. I explored using a different icon (wrench) and a simple text label for the bottom-right editor settings as well:

Combining these two could be good — we have so many icons that essentially all kind of mean the same thing (settings cog, settings wrench, more ••• ... all kind of the same idea, more stuff in a menu) that reinforcing with a label would go far to improve clarity.

[enriquesanchez]

This is very early-stage sketching out the idea for now so would welcome some feedback.

Loving these early explorations @karmatosed!

I agree with @shaunandrews, I feel like the tabbed pane feels a bit too much and think that the menu exploration might be worth pursuing. I wonder if we can even take inspiration from list menu patterns found in mobile and the Customizer?

As for accessibility feedback, I understand these are early explorations and nothing is set in stone yet, but it's also a great tine to think about topics such as document structure and keyboard navigation. We might find that having the options placed at the bottom right corner might prove to be hard to find and get to for some users.

[karmatosed]

@enriquesanchez is there anything we can do about order to help that? I know it's been said before being at top might also be a problem because forcing an order and being in area of publishing flow.

[enriquesanchez]

@karmatosed What I do is to try to imagine I'm using a screen reader and then ask myself "how would I know this element exists and how would I get to it?".

As you can see from the Landmarks selection modal in VoiceOver, we have a few editor-related landmarks or regions in Gutenberg. Where would I go if I wanted to get to this Options menu? My natural reaction would be to try the 'Editor top bar region' or 'Editor settings' region.

It would be frustrating and tedious to go to any of them, tab through all the options and realize it's not there. And this is assuming I know this menu even exists.

And to clarify, it's not that 'Editor footer region' would be the wrong place for this menu, it's just that given all the regions we already have—and how they're named—that it gets confusing to figure out where would it be.

I do think that the simplification and logical grouping you're exploring on this issue is important and if we take a holistic view at this and how we can make use of regions and grouping to bring more logic to the interface, it has the potential to make navigating around the editor easier.

[chrisvanpatten]

One other element that I want to toss into the ring is that the number of options in that top right area expands greatly as you get into very complicated Gutenberg implementations.

For example, this is our top right UI:

Each of these icons is for a sidebar panel which offers important features to our editorial and production teams. We're trying to do our best to expose the sidebars only when necessary, but ultimately we have to balance having fewer sidebars that do more and don't tell cohesive stories (e.g. mixing unrelated options) and having many sidebars, which are each clear in their purpose.

While our case is maybe on the more extreme end, as we have many, many stakeholders across our brands interacting with the CMS and each group has competing needs, I'm sure we aren't the only ones with a UI like this. It would be nice to see explorations take these cases into account. Implementers such as us have very few options for exposing "document metadata settings" in the UI, and it would be nice to have a better way to visualize the available options such that they aren't buried in a menu or you get icon soup like our current approach.

(Happy to give a tour of our implementation as well, if it would ever be helpful!)

[jasmussen]

The challenge Chris shows here is worth thinking more about. Currently any sidebar can be unpinned (click the star), which should mean that the sidebar only exists in the overflow menu on the right.

For example, install Yoast and you can open the sidebar from the button, or the item in the ellipsis menu. Unpin it, and it can only be opened from the item in the ellipsis menu.

If we remove/move the ellipsis menu, how does this interface work? It was inspired by how Chrome extensions work:

It arguably hasn't been intuitive or as successful as we hoped, but we still need to address how sidebar pinning works. Unless a user can explicitly opt out of these buttons some day we'll end up in a very bad UI place.

[rickybanister]

The points from Chris and Joen resonate with me. I was thinking about Slack's information architecture the other day. All of their 'top bar' icons open and populate their sidebar when clicked, and the ellipsis is a menu of less important sidebar content. It feels right that if the ellipsis sticks around it would have the same behavior, providing access to sidebar content. Display options/editor settings could simply be another sidebar content panel.

[shaunandrews]

which should mean that the sidebar only exists in the overflow menu on the right.

What if we take this further and and keep the ellipsis menu only for plugins:

For people without any plugins, the menu would be reduced down:

[karmatosed]

For people without any plugins, the menu would be reduced down:

What about using '...' or an arrow to denote more plugins?

[jasmussen]

Keep the explorations going! I do worry about a single ellipsis button splitting into two, though — that feels like more UI and complexity, going against the initial goal.

[chrisvanpatten]

Instead of an ellipsis button, perhaps a down chevron similar to the button to view all RichText formats, would be more appropriate?

One thing I really dig about @shaunandrews' mockup is that it effectively promotes plugins to being standalone first class citizens, with their own interface.

Also as an update to this comment, we've since finished converting our "legacy" metaboxes to Gutenberg sidebars, and are now confronted with this:

(This is obviously a worse case scenario, partly due to our enterprise scale and the amount of metadata we need to catalog for every piece of content we publish.)

We have the luxury of being able to devote resources to iterating on that now that the initial conversion process is done (consolidating sidebars, figuring out where we can conditionally show/hide fields, thinking about what can be placed in pre/post publish panels, etc) but many users won't, because the sidebars are registered in third party plugins they can't control.

As such it might be nice to think about this alongside #20336, #14457, and similar "plugin experience" issues.

[ZebulanStanphill]

@chrisvanpatten

Instead of an ellipsis button, perhaps a down chevron similar to the button to view all RichText formats, would be more appropriate?

Firefox has something pretty similar to this:

[richtabor]

Re the ellipsis more menu, we should get clear on what are options/settings vs. what should be high priority actions within the More menu. For example, the "views" at the top of the more menu are options - not actions. Whereas the remaining items are actions.

[paaljoachim]

We discussed this issue during a Gutenberg Design Triage:
https://wordpress.slack.com/archives/C02S78ZAL/p1594742741070300

An idea that come up was having an Interaction Design review going through the various main areas. We also need to think about how Full Site Editing will also affect the general UI. A lot of ideas came up such as removing the X in the sidebar. Moving the ellipse into the sidebar. Removing the Document and Block Tab. To just show the Block title when a Block is selected and the Document when no block is selected. (Would likely be a discoverability issue.)

Check the above link for the discussion that we had.

[afercia]

Any new position of the options should be considered not only visually but also as position in the DOM order. Please consider that for keyboard users and assistive technology users content navigation is a linearized experience.

That said, the current placement of the options isn't ideal as well. Any improvement welcome :)

This also brings us back to conversations made in a very early stage of this project, related to general organization of the main sections, especially the "Publish" panel in relation to the other sections. In a logical, linearized, flow, the ideal order would be:

• post title
• content area: add blocks, edit blocks, etc.
• after user created their content: options
• publish/save/schedule

This mental model appears to be the most reasonable one and ideally it should be reflected in the UI.

Adding the Accessibility label as general layout of the main section in the block editor is one of the main features that affect an accessible user experience.

[afercia]

One more thing to consider:

At the bottom of the block editor page there's already the meta boxes area. This area appears only when plugins add their own meta boxes in the "legacy" way. Any new design should take into consideration the bottom part of the page is already "taken" by the meta boxes area.