Try to reduce the visual weight of the block

[jasmussen]

The cognitive load of the chrome we show around and in context of the block unit has been an ongoing topic for a while. Concerns have been noted that it feels heavy, there are many toolbars, options, and it gets in the way of writing.

As an experiment, in this ticket are some new mockups that try to touch on many different ideas presented, including:

• Fixed-to-the-top block toolbar
• Smarter auto-hiding of block chrome
• Clearer grouping of block controls
• More light-weight writing experience with a different block boundary design and selection model

What are the pros and cons? What are the accessibility implications? Are there flows that will regress in this design?

Please add your thoughts. To focus these mockups, the sidebar is toggled off. No change to that one — it's still on by default.

The basic editor

No blocks are selected.

Movers and block context menu

Hover near the edges of the block to surface the movers and the context menu:

This is similar to how Google Docs handles it:

You can also hover between blocks for a shortcut to insert a block there:

If the block has the cursor, you can still tab into these.

Editing

Clicking a text block does not activate the boundaries. But it does show the quick toolbar, docked to the top of the screen:

This toolbar can be accessed, no matter where your cursor is, or which block is selected using Alt+F10 or ⌘/Ctrl (see discussion in #2960).

Selected blocks

If you just put the cursor in text, boundaries don't show up to highlight the block. Boundaries are shown for every other block but the text blocks. But you can still select the block, for example when you use the movers to reposition the block, or if you click the context menu:

The context menu groups existing Delete, Configure options, and adds a couple of other block level niceties. See also #2980.

Selecting multiple blocks also gives you the option to convert multiple paragraphs to a list, or a quote:

Mobile

On mobile, the top-docked toolbar moves down a level and stacks:

[youknowriad]

I like the mockups here, I'll experiment some of these (fixed toolbar and right menu)

[mtias]

I like giving a block-less look a go. There are some things we can do previous to the toolbar repositioning, like the block-ellipsis menu as a popover.

[jasmussen]

Tracked the popover in #2984. See also #2980.

[jasmussen]

CC: @hedgefield @karmatosed

[karmatosed]

I really want us to give this a go. I think it solves a lot of issues and also will help with the niggly 'feeling' that many of us want to get to the bottom of with regards to how the editor feels. I am excited about seeing this into a PR.

[folletto]

Hover

While hover wouldn't work well on touchscreens, I think that the alternative mobile design you have should compensate that well. What's probably missing is just the "up" and "down" arrows tho?

Clicking a text block does not activate the boundaries. But it does show the quick toolbar, docked to the top of the screen

Massive +1,000

On mobile, the top-docked toolbar moves down a level and stacks:

Looks like a great improvement! /cc @iamthomasbishop

---

Overall, I feel this gets the editor in a really really good place in terms of overall experience. Seems more solid and consistent, and does a better job in not getting in the way of the writing + editing flows.

[hedgefield]

Love every bit of this. <3

[afercia]

As discussed on other issues, the toolbar fixed at the top has its accessibility concerns, but I see the benefits of cleaning up the UI.

Showing controls only when needed makes a lot of sense to me. Sometimes it comes to the cost of an additional click (for example on the context menu ellipsis button) but seems to me this is closer to a more modern approach where many UI controls are made available only when needed.

From an accessibility perspective, I'd tend to consider this something worth experimenting, but: we should really make the navigation and interaction between the edited block and the fixed toolbar at the top perfectly accessible. Shortcuts are not enough. Being able to navigate from the edited block to the toolbar is already addressed but there's also the need to be able to navigate back from the toolbar to the block being edited. This was already discussed on other issues, see for example #2148 (comment) and #2148 (comment)

We've already received some feedback from screen reader users completely confused by the current block toolbars appearing and disappearing without apparent reason. Also, the block toolbars force keyboard users to a lot of Tab key presses to navigate through blocks.

Removing the block toolbars and having just one "quick toolbar" at the top could greatly improve keyboard navigation. I'd like to propose to think at this looking also at the big picture and taking into consideration navigation with keyboard through all the blocks.

A first idea of "Edit mode" was mentioned on "Standardize the Tab/focus behavior across the blocks" #2031 trying to combine it with a new flow idea from @jasmussen in #1516 (comment)

tab highlights a block (same as cursor hover)
enter "clicks" it (block shows quick toolbar)
escape unselects it (showing hover again)

The "Edit mode" was further discussed on #2148 (comment)

As I see it, the only way to make keyboard navigation through blocks effective is that tabbing through blocks should focus only the block containers. They're already properly labeled, and this way users could quickly navigate to the block they want to edit:

Then, there should be some command (Enter/click?) to switch a block to "Edit mode": in this mode, controls are displayed and available for that block. Pressing Escape exits "Edit mode" and moves focus back to the block container.

If correctly implemented, with a very few Tab key presses users would be able to navigate the whole interface and that would be awesome.

Hover

Hover near the edges of the block to surface the movers and the context menu:

Personally, I have my doubts the whole idea of hover is still a thing 🙂 I'd like to hear thoughts from designers about this. I see @folletto is a bit doubtful too. Showing some controls on hover makes them less discoverable. As a user, why I should even imagine that hovering a certain area would make the movers and the context menu button available?

Aside: I'm not even sure why the formatting controls are moved to the top toolbar and the movers/context menu button stay on the block instead. Maybe worth experimenting moving everything to the top toolbar and have blocks be just blocks without controls floating around? A bit #riskylife maybe, but worth considering 🙂

Question:

You can also hover between blocks for a shortcut to insert a block

How that would be revealed to keyboard users? How would it impact on arrows navigation between blocks?

[melchoyce]

I like this a lot ✨

[iamthomasbishop]

I've gotta say, I really am continually impressed at the progress being made on Gutenberg!

I absolutely love the "hover between blocks to show the (+) icon" idea. While it might not necessarily translate as-is to mobile, I see it as a nice-to-have on desktop and I've already got a sense of how we can port this type of thing to touch devices.

I am generally wary at first of going down the path of tucking things in an ellipsis menu, but in this context, it's growing on me and I don't know if we really have a better option if we're to include all of those options (HTML toggle on a block-level is a beautiful thing, btw!).

In terms of the shifted visual style on blocks (light blue background), I'm wondering what the reason for the shift is here? I've always felt that a subtle gray outline made it very clear what you were focused on. I'm also somewhat concerned at only showing the special block controls (re-arrange on left, ellipsis on right) on hover. This definitely cleans up the UI, but I'd be concerned about discoverability. Maybe it's a non-issue in practice?

I love moving the active block toolbar to the top, and I'm hoping we can optimize in a way that's accessible as others have discussed above.

All-in-all, loving the progress being made. Y'all are killing it 👏

[anna-harrison]

@jasmussen: these designs are brilliant! In particular, I believe that your proposed direction resolves a lot of the "it does not feel good" nebulous issues raised by users, and analysed in #2279

@karmatosed @youknowriad: the toolbar accessibility question raised here look like they are almost resolved here - feel free to drop @ephox-mogran any outstanding tasks raised in #2960 (e.g. escape from toolbar + re-focus)

I think that in light of this direction, the link entry improvements proposed in #2715 are no longer relevant. @tg-ephox will wrap the tests and complete that work, incase we want to revisit the in-line/over toolbar link entry for mobile use cases. For the desktop, I imagine that going back to a floating toolbar adjacent to the current selection is preferable - @jasmussen would you agree? I would keep the consistency of link input across the blocks, but defer to your judgement for the finer-grained designs

The designs proposed here to me feel like a major turning point in the Gutenberg project! Onwards and upwards :)

[jasmussen]

Thanks all, for the feedback. Some quick points.

@afercia

addressed but there's also the need to be able to navigate back from the toolbar to the block being edited

Absolutely agree. Should I open a separate issue for this? What are best practices here?

Removing the block toolbars and having just one "quick toolbar" at the top could greatly improve keyboard navigation. I'd like to propose to think at this looking also at the big picture and taking into consideration navigation with keyboard through all the blocks.

Yes, improved arrowkey navigation, as well as shift-selecting multiple blocks seems pretty key in getting this to work well. See also #2990.

"Edit mode"
As I see it, the only way to make keyboard navigation through blocks effective is that tabbing through blocks should focus only the block containers.

This seems to make sense to me. Arrow key navigation lets you stay in the text, as you would in any editor, shift select works on inline ranges and multi select ranges. Tab in this case would unselect the text (remove the caret), and put you in select block mode, correct?

If correctly implemented, with a very few Tab key presses users would be able to navigate the whole interface and that would be awesome.

This sounds really good to me. It also seems like this could pave the way for additional accessible ways of selecting multiple blocks (something like pressing space whe a block is tab-focused to toggle selection perhaps), outside of just shift-selecting a range of blocks when the caret is in text.

Showing some controls on hover makes them less discoverable. As a user, why I should even imagine that hovering a certain area would make the movers and the context menu button available?

I'm a bit skeptical myself, and the mockups here represent a balancing act. The key reason these exist, is to provide additive enhancemets to desktop users. I have often received critique on heavily "mobile-first" projects, that often the desktop and its additional/different forms of interaction are often forgotten. And so the hovering to show items is an attempt to tread the balance between having these features present, but not distracting. This should definitely be ticketed and tried separately, and isn't absolutely necessary for the improvements in this ticket on their own.

Maybe worth experimenting moving everything to the top toolbar and have blocks be just blocks without controls floating around? A bit #riskylife maybe, but worth considering 🙂

Nothing is off the table. The key reason for separating formatting from block actions is that some blocks are unlikely to have any top toolbar at all. I suppose we could still show just the movers/ellipsis up there in this case — we'll have to on mobile — but certainly something we can explore.

How that would be revealed to keyboard users? How would it impact on arrows navigation between blocks?

Depends. First off, we've tried this feature in a few branches so far, merged and reverted once because the experience wasn't quite solid. It needs some thought. One option is to have it appear when you tab through blocks in "pick a block mode". Another option is to have it part of the tab circle for when you are in edit mode, and haven't entered the toolbar. A third, probably not kosher, option is to decide it's a desktop only enhancement, and require that keyboard users use the "Insert After" shortcut that's detailed in the block dropdown menu.

[jasmussen]

@iamthomasbishop

I've gotta say, I really am continually impressed at the progress being made on Gutenberg!

❤️

I am generally wary at first of going down the path of tucking things in an ellipsis menu, but in this context, it's growing on me and I don't know if we really have a better option if we're to include all of those options (HTML toggle on a block-level is a beautiful thing, btw!).

Definitely feel like ellipsis/overflow is a "last resort" kind of thing. However two benefits are that it's more scalable, and it allows us to show both icon, label, and shortcut keys in a more verbose way, without weighing the UI heavily. The danger is that it becomes a "kitchen sink" of features, but we must be brave and push back against that if/when that happens.

In terms of the shifted visual style on blocks (light blue background), I'm wondering what the reason for the shift is here? I've always felt that a subtle gray outline made it very clear what you were focused on.

The overall effort that led to this change was a desire to explore a simpler silhuette. A border, as such, is a slightly more complex silhuette than a background. But they key reason was deciding that when you are just editing text, there's no overwhelmingly compelling reason to ever show the block boundary all the time. In exploring that path, the blue background for a selected block became a callback to the blue selection range you get when you simply select text.

Imagine a flow where you are typing, and you want to delete what you wrote, as well as the next paragraph — you hold shift, select to the end of the paragraph block and continue pressing down to invoke the multi selector that then selects the entire paragraph block and the next, letting you quickly delete it with the del key. This remains to be implemented, but it's where the blue came from.

I'm also somewhat concerned at only showing the special block controls (re-arrange on left, ellipsis on right) on hover. This definitely cleans up the UI, but I'd be concerned about discoverability. Maybe it's a non-issue in practice?

Definitely a potential discovery issue, and something to be explored and evaluated separately for sure.

The reason for including this, however, was the realization that after using Gutenberg for 7 months, these controls are exceptionally useful when you need them, but that need is only occasional. And so it's an attempt to balance these features being there, with them requiring a little bit of learning.

Thanks for the feedback!

[afercia]

@jasmussen

What are best practices here?

See https://www.w3.org/TR/wai-aria-practices/#h-note15

For example, a rich text editor may have a menubar that receives focus when a shortcut key, e.g., alt + F10, is pressed while editing. In this case, pressing Escape or activating a command from the menu may return focus to the editor.

Escape is also how it works in TinyMCE. Our case is a bit different though because the editing area (the block) and the toolbar are separated. I'd say Escape is a good option, it would be nice to explore some additional mechanism too.

Tab in this case would unselect the text (remove the caret), and put you in select block mode, correct?

Not sure what select block mode is 🙂 I meant move focus back to the block container, the one with tabindex="0" nd the aria-label identifying the block, see screenshot in the previous comment.\

It also seems like this could pave the way for additional accessible ways of selecting multiple blocks (something like pressing space when a block is tab-focused to toggle selection perhaps)

Ah! nice, yes worth exploring. Basically like the checkboxes in the list of posts. Will need some testing with screen readers because JS events don't work as expected on non-interactive elements when using a screen reader (TL;DR screen readers use two modes: browse mode and forms mode).

[jasmussen]

select block mode

Sorry, bad phrasing. I mean when you aren't editing text, but are just tabbing from block to block.

[shaunandrews]

I'm diggin' this new direction. It feels, overall, much cleaner and simpler.

What implications does this new design (and specifically, the new context menu) have on the inspector sidebar?

[jasmussen]

What implications does this new design (and specifically, the new context menu) have on the inspector sidebar?

For the time being, this design does not change the sidebar/inspector. You can still have the sidebar enabled, and it is enabled by default. There's still a document and a block tab, and there's still a shortcut from the block to the Block tab from the ellipsis > settings item.

[shaunandrews]

Its totally possible I missed a discussion somewhere, but what's the thinking behind the ordering of the icons — and the new turned-ellipsis menu?

[jasmussen]

Its totally possible I missed a discussion somewhere, but what's the thinking behind the ordering of the icons — and the new turned-ellipsis menu?

The first discussions date back to this issue, #467, and the change was recently discussed in #2878. See also #2460 and #2797.

The short of it is that the rearranging addresses a variety of different smaller issues, and improves the accessibility slightly.

[jasmussen]

Super thrilled to see that there appears to be generally warm feelings towards this design. But this is an umbrella ticket, and there are a number of smaller issue that should all be handled/discussed separately, to implement this design. Here's such a list, and please add to this list if I missed anything:

Miscellany:

• Consider hiding block ellipsis and movers until mouse is near them Consider hiding block ellipsis and movers until mouse is near them #3044
• Adjust and redesign neutral, hover, active and focus states Adjust and redesign neutral, hover, active and focus states #3039
• Keyboard enhancements: Improve tabbing and focus in placeholder blocks Keyboard enhancements: Improve tabbing and focus in placeholder blocks #3016
• Improve the block settings menu, give it a background Improve the block settings menu, give it a background #2984
• Show keyboard shortcuts in menus and tooltips Show keyboard shortcuts in menus and tooltips #2980

These two feel related, see discussion for more info:

• Block Toolbar: Move the block toolbar to the editor's header Block Toolbar: Move the block toolbar to the editor's header #2998
• Handling overflow in the quick toolbar Handling overflow in the quick toolbar #2898

Keyboard things:

• Improve keyboard navigation across blocks Improve keyboard navigation across blocks #2990
• Thoughts on a navigation and edit mode Keyboard interaction: standardize the blocks behavior #2031 (comment)

[mtias]

Closing as done.