Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Try to reduce the visual weight of the block #2983
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:
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.
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).
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:
On mobile, the top-docked toolbar moves down a level and stacks:
referenced this issue
Oct 11, 2017
referenced this issue
Oct 11, 2017
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?
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.
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.
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.
Personally, I have my doubts the whole idea of
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
How that would be revealed to keyboard users? How would it impact on arrows navigation between blocks?
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
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
@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 :)
Thanks all, for the feedback. Some quick points.
Absolutely agree. Should I open a separate issue for this? What are best practices here?
Yes, improved arrowkey navigation, as well as shift-selecting multiple blocks seems pretty key in getting this to work well. See also #2990.
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?
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.
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.
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.
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.
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.
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.
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!
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.
Not sure what select block mode is
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).
referenced this issue
Oct 12, 2017
referenced this issue
Oct 12, 2017
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.
The short of it is that the rearranging addresses a variety of different smaller issues, and improves the accessibility slightly.
This was referenced
Oct 13, 2017
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:
These two feel related, see discussion for more info: