Reconsider the left/right block hover areas, at least for the selected block

[afercia]

Looking a bit into the details of the new UI behaviors introduced in #6101 / #6141.

I understand the intent of lighten up the UI, however I'm not fully convinced about some assumptions that were made with these recent changes. First, the accessibility issue:

This is what the UI shows now when a block is selected:

The block "movers" on the left and the ellipsis/remove buttons on the right are not shown by default. I appreciate keyboard accessibility has been taken into consideration and these controls appear when tabbing through the interface. However, I think the assumptions made here have gone a bit too far. There are a lot of different workflows users will adopt, lots of different abilities, different level of expertise, and so on, that the best thing an UI can do is to not make so broad assumptions. Why the UI should assume users need to see these controls only when hovering on the left/right areas or tabbing into them? Here's just one example where this pattern would be an a11y barrier:

• I'm a user with motor impairments
• I don't use the keyboard, or using the keyboard is extremely difficult and painful for me
• I use a speech recognition software to voice commands and control my computer
• in the scenario above, with a block selected, I see just the toolbar
• instead, I need to see all the UI controls to understand what the available actions are
• aside: I'd need to know also the accessible name of the controls: unfortunately there are no visible labels but at least there are tooltips
• when all the UI controls are visible, I'm able to voice commands to my speech recognition software, e.g. "Click move down"
• but, if I don't see the UI controls, I don't even know what the available controls are

I'd strongly recommend to not hide the side controls on the selected block. As far as I see, in #6101 the new behavior was first implemented only for the unselected blocks and then extended to the selected block. Can we please reconsider this and make all controls visible for the selected block?

== Other considerations

I'd kindly suggest everyone to consider that many considerations about things like "reducing the UI weight" or "reducing the cognitive load" tend to be highly subjective and risk to be assumptions. To me, cognitive load is not about how many things are displayed in the UI, unless there are literally dozens and dozens of controls. It’s more about the continuous appearing and disappearing. As I see it, now the UI controls continuously appear and disappear in a more frequent way than the previous implementation (which was already confusing for some users). So I wonder: does having “things” that continuously appear and disappear really lightens the cognitive load or increases it?

You may argue I'm making assumptions too 🙂and that's true, so I'd really like to see this new behavior A/B tested from users, including assistive technology users.

Note:
maybe a small bug, as far as I see when a block can't be moved because it's the only block or its the first or last one, the mover buttons should look "disabled" also when hovered or focused. /Cc @jasmussen

[afercia]

Looking a bit into this, seems to me there's something a bit weird going on. Simply dumping isHovered and isSelected in the render function before the return, I can see sometimes they're both false. Even when the editable area is focused and the mouse pointer hovers it:

(Grab transforms the mouse pointer style, please ignore that)

Seems to me this is in part because of the way maybeHover() works:

• when clicking on a block isHovered becomes false; not sure why, maybe because of the click itself?
• at this point isSelected is true so maybeHover() returns early and isHovered stays false even if you move the mouse on the block
• then this condition isHidden={ ! ( isHovered || isSelected ) || hoverArea !== 'left' } cant work reliably because isHovered is false when it should be true

Seems to me this is something that should be investigated and fixing it would allow to reliably modify the behavior, e.g. making the controls visible when the block is selected.

[afercia]

OK so seems to me that when clicking a block, hideHoverEffects() sets isHovered to false. /Cc @aduth

[ZebulanStanphill]

Having played around with Gutenberg 2.7.0 for a while, I agree that the side controls should always be displayed for the currently selected block. It can be rather tricky to use the side controls of the selected block when it is nested in another block and adjacent to another nested block, and I think having the side controls always displayed would make it less confusing.

[afercia]

I've read everything related to #5658 and the excellent GIF posted there #5658 (comment) clarifies very well what is the original issue 0d0c8e0 tries to solve.

That works well for nested blocks, as in when hovering a child block, the parent block is no "hovered". But it doesn't work so well for standard blocks, because as soon as you click in the editable area (which is the inner IgnoreNestedEvents), the block (the wrapper) itself is no "hovered" any longer.

To recap: isHovered and isSelected are used together in the logic to determine when the side controls should be visible or hidden:

• isHovered becomes false when clicking the block
• isHovered is also false (correctly) when hovering on a block other than the one that was clicked
• isSelected refers to the block current instance too (this), so when hovering on block other than the one that was clicked, it will return false

Basically, in the current implementation, there's no way to always show the side controls for the block that is currently "selected" (meaning the one being edited). For example. getSelectedBlock() does a different thing and it returns the actually selected block. Also, the terminology is a bit confusing as the meaning of isSelected in the block instance is different from getSelectedBlock().

[chrisvanpatten]

I was an early fan of the left/right side thing, but in practice I'm growing more irritated by it. I think it actually increases the cognitive load because you have elements constantly flitting in and out of view as you move a mouse around.

Perhaps this is too dramatic, but for the sake of playing devil's advocate… what if you could only access the side nav tools if a block is selected? And the hover functionality is removed entirely?

This would reduce some of the technical complexity (although it may add complexity in other ways… again I'm just playing devil's advocate, not promoting a fully-formed solution) because a block now effectively has just two states: unselected or selected. You don't have buttons and text flashing around as you hover around the editor. If a block is selected, that's an unequivocal way of saying you want to interact with the block in some way. It also unifies things with touch interfaces where hover isn't an option at all.

Again, to be clear, I am probably missing things — I don't want to sound like I think I have the answer! Just a feeling, or an ignorable opinion :)

[ZebulanStanphill]

@chrisvanpatten The first downside that comes to mind about making side controls only visible on the selected block is that you would no longer be able to quickly delete blocks without having to select them first, and of course other controls (arrows, ellipsis menu) would also become less convenient to access.

[chrisvanpatten]

@SuperGeniusZeb Yeah, it obviously places all controls beyond one level of interaction, but that's already the case for many of the block interactions and is already the case on tablets and mobile. My personal feeling (which of course should be taken with a grain of salt) is that it's worth that sacrifice in the interest of greater consistency and clarity.

It's also not that big a jump, since in a way, the Classic Editor/TinyMCE experience already requires you to interact with/select an element to move or remove it. Obviously Gutenberg is a lot more advanced/capable than TinyMCE alone so it's not a 1:1 comparison, but it's similar :)

[jasmussen]

I hear the issues, but would like to ask for some patience before we throw it out again. Aside from various implementation improvements the feature can receive, one immediate step to test would be to simply increase the size of the hoverable area — each side could be 50%, for example, as opposed to the (I think) 30% size it is now. Another thing to test is to simply always show them when the block is selected. I ask for patience as the feature feels like it's benefitting some of the aspects of try/alternate-hover-approach (still not ready to PR) a lot.

[afercia]

Another thing to test is to simply always show them when the block is selected.

Yeah, that's what I was considering in the first place, thanks @jasmussen

[ZebulanStanphill]

@jasmussen Wow, I just tried out the try/alternate-hover-approach branch, and showing the outline of a block on hover really helps a lot with figuring out which block you are hovering over and how big it is. It definitely improves the experience with the side controls. It also greatly improves the experience with multiple levels of nested blocks. I think you should definitely keep working on this... it makes the editor feel a whole lot better to use. 👍

I would say that increasing the hoverable area to 50% should definitely be done, but after trying out your branch, I do not feel so strongly about it anymore. The outline on hover really does a lot to improve the UX and reduce confusion.

I noticed that the hover block title is missing in your branch. I am not sure if that is intentional or not, but I think it would be helpful to still have the title shown on hover. The "Select parent block" button could stay gone, though, since it is being added to the block toolbar and therefore does not need to be shown on hover.

Additionally, as I have suggested before, the hover title could double as a drag handle (show a drag icon when you hover directly over the title or just always show a drag icon next to the title), making it even more useful and possibly solving the issue of drag-and-drop being difficult for small blocks and hard to discover.

The biggest downside I can see to having the hover title is that is covers up some of the space above a block, but if it is also a drag handle (and the "Select parent block" button is only shown on the block toolbar and not on hover, thus reducing the space taken up by the UI shown on hover), maybe that would make up for it.

[karmatosed]

With the alternative hover I think we can close this for now. Noting we can always reopen.

[afercia]

I'm not fully sure what the alternative hover is. However, the original proposal in this issue is to ''make all controls visible for the selected block". That means: click or focus within the block > block gets selected > the toolbar appears and stays visible. It doesn't have much to do with hovering.
Worth also noting #6224 proposes to display the "block tools" in a toolbar after the block. That would make the current left/right hover areas obsolete. Still, those tools should be always visible when the block is selected.

[afercia]

Discussed during today's accessibility bug-scrub: now that the Trash and Ellipsis buttons have been moved to the toolbar, this applies only to the buttons on the left:

We agree it would be best to display these buttons when the block is selected, at least initially. They should behave like the toolbar (disappear when writing, re-appear on selection)

[karmatosed]

This looks like resolved, unless I am mistaken for the movers. I am going to close but we can always reopen.

[chrisvanpatten]

@karmatosed still open for the movers but there are some broader mover issues that will likely need to be looked at for Phase 2. I think it's fine to leave this closed for now and consolidate mover issues into a new ticket.