Consider a subtler hover state for blocks

[kjellr]

When a user moves their cursor around their document, we currently trigger a dark blue outline around every block:

The prominence of this treatment can add unnecessary cognitive load to the experience, and I'd like for us to consider rethinking it.

Background

The action of hovering over a block doesn't necessarily mean that the user wants to interact with it: They could just be moving their mouse around. If that's the that case, triggering a series of dark rectangles can seem quite interruptive:

Our current blue border does a great job letting the user know where the boundaries of the interaction area are, but it's also a very heavy UI element. Dark elements like these (especially ones that repeat as frequently as this hover state) can build up to a relatively distracting UI.

This heavy UI can seem especially jarring for those who approach Gutenberg as a writing environment. I've heard this frequently when testing Gutenberg with those who work in publishing. Other editors (Google Docs, Dropbox's Paper, Notion.so, etc.) do not implement prominent hover states, and many don't include hover states at all.

Gutenberg's frequent use of horizontal rules (even just on hover states like this) work to visually reinforce the boundaries between each paragraph. This doesn't necessarily align with the more holistic way these writers think about a document. Functionally, it's helpful to have each paragraph be a separate block, but it's unnecessary to reinforce this paradigm so strongly when they're just trying to move their mouse around.

Possible solutions

It may be more natural to show a “hint” on hover, and then switch to a more prominent treatment once the user commits to interacting with the block. For instance, here's an idea from #13700 (comment):

Another possible solution (explored a bit last year) would be to add a delay to the blue hover state, so that it is less intense if someone's just mousing around the document:

---

A few considerations:

• Hover states do not exist at all on mobile, so users on smaller screens never see these blue borders. Since that's the case, hover effects like these should be treated as progressive enhancements. I think we have leeway to dial the borders back a bit with that in mind.
• I believe this blue hover treatment was chosen so that the hover state passes contrast tests. I want to be clear that that's important! We should not sacrifice contrast here. Contrast is an a11y concern, and so is cognitive load. I'd love for us to come up with a solution that solves for both.
• This should be considered in tandem with Make the selected block outline darker  #12254, which aims to improve the contrast ratio for the focus state of a block.

The design of the hover state has come up many times throughout the course of Gutenberg's history, but there doesn't appear to be a current issue for this problem. I wanted to open up this one as a place for discussion and problem-solving.

[sarahmonster]

👍 to reducing the weight of the hover interaction.

My understanding is that people don't seem to require a hover indicator in order to recognise that blocks can be interacted with, and so this effect is largely decorative. (Especially since this effect isn't available to users of touch-screen devices.) Dialling it back would be a great way to help reduce the cognitive load and feeling of heaviness in the current UI without sacrificing important functionality.

The single blue border on the left seems like a good approach here. What about reducing it even further, and showing only what's helpful and necessary here: the drag/move controls?

[afercia]

I believe this blue hover treatment was chosen so that the hover state passes contrast tests

No 🙂 That was a design choice by the design team. The accessibility team never asked for a so strong hover style. Actually, quite the opposite. We've always wondered why the hover state is more prominent than the focus/selected state. The latter needs to be at least 3:1. There are at least 2 PRs right now to address the focus state.

Also, in WordPress the color blue is used for interactive elements: links, buttons, etc. Never for hover, as far as I can tell.

[kjellr]

@afercia:

The accessibility team never asked for a so strong hover style. Actually, quite the opposite. We've always wondered why the hover state is more prominent than the focus/selected state.

Oh great! Thanks for the clarification — it's been hard to dig through the history on this.

Also, in WordPress the color blue is used for interactive elements: links, buttons, etc. Never for hover, as far as I can tell.

Excellent point. 👍

---

@sarahmonster:

What about reducing it even further, and showing only what's helpful and necessary here: the drag/move controls?

I think that'd go a long way towards toning down noise. Here's a quick GIF of that (paired with the focus fade effect from #13700):

[afercia]

Thanks for the clarification

You're welcome. I didn't mean to completely remove the border though 🙂

Also, the focus fade effect doesn't solve the original issue. Going to comment on the PR too.

Would be great to find a good balance. Color contrast is a simple requirement. NOn-text contrast needs to be 3:1. At this point of the project, after two years of development, there shouldn't be any contrast issue in the interface. May I suggest to try to invert the borders: personally I wouldn't have objections to use the lighter gray border for hover. Instead, focus could use the blue (matching the core pattern for focused interactive element). More importantly, focus needs to always be 3:1.

As noted in other comments in other issues/PRs, if users prefer a lighter UI, there's "Spotlight Mode" explicitly designed for that. Instead, the default should offer a sufficient contrast.

[alexislloyd]

My understanding is that people don't seem to require a hover indicator in order to recognise that blocks can be interacted with

This is my understanding as well, not only from Gutenberg usability testing, but from observing users using the other writing / publishing products that @kjellr mentioned that have no hover state or more minimal hover states.

The more simplified left border on hover seems to support any need for indicating the bounds of the block with lightening up the visual interference in order to create a more usable, less distracting UI.

[afercia]

Other editors (Google Docs, Dropbox's Paper, Notion.so, etc.) do not implement prominent hover states,

Not against the idea of lightening a bit the hover state, but I'd advise to not compare Gutenberg with other editors that are very different in terms of interaction and behavior by their own nature. Those are "full page" editors primarily meant to produce documents. Also, they don't have "blocks" 🙂In gutenberg, blocks need to be communicated and be discoverable.

For example, the "breadcrumb" (not sure why it's named this way) in the top right of the blocks:

It was introduced to communicate the block type because usability testing indicated users didn't have a way to understand what type a block is. Note: this wasn't an accessibility feedback. It was a design choice.

In the proposed design, this breadcrumb is a bit too much disconnected from the block and looks like something that appears on the page a bit unexpectedly. Not saying the breadcrumb is ideal but probably needs some more thinking.

Also, I'd recommend to test with some real content and not just with one-line paragraphs 🙂With real content, the need to have some hover effect is more evident: sometimes it's hard to understand where to click to select a piece of content. For example, if the "movers" become the only indication of hover, worth considering they could easily be out of view when blocks have some long content.

[kjellr]

In the proposed design, this breadcrumb is a bit too much disconnected from the block and looks like something that appears on the page a bit unexpectedly. Not saying the breadcrumb is ideal but probably needs some more thinking.

Agreed. This is certainly the sort of thing we can iterate on and solve together.

Also, I'd recommend to test with some real content and not just with one-line paragraphs

I've created a PR so we can do just that. To make it a more complete solution, I've also included a possible treatment for the focus mode, with improved contrast: #14145

[donpark]

I think the right vertical line is very useful to have. And having both left and right vertical lines moving in sync makes them more noticeable than only thick line on the left, even if the lines were thin and faint.

Also, fade-in/out transition effect can be used to both reduce the flickering problem, replacing delay with ease-in, as well as contrast issues, reducing contrast once the need passes. If user scrolls really fast, blocks will start to fade-in but immediately start to fade-out again.

[sarahmonster]

The breadcrumb seems like it would be more useful in the block's selected state, rather than its hover state. Is this something that users of touch-screen and other devices struggle with? Do we have a link to the usability testing that indicated a need for this? It'd be interesting to dig into that a bit to better inform our direction here.

[kjellr]

The breadcrumb seems like it would be more useful in the block's selected state, rather than its hover state. Is this something that users of touch-screen and other devices struggle with? Do we have a link to the usability testing that indicated a need for this? It'd be interesting to dig into that a bit to better inform our direction here.

That's a great question. @jasmussen may have more background, but if my digging is correct, I think those breadcrumbs were originally added in #5658 (comment). It sounds like they were likely added to provide clarity around nested blocks. They've morphed quite a bit since then. You're correct that they don't appear on mobile — it's worth considering whether they're needed in general.

[jasmussen]

The breadcrumb seems like it would be more useful in the block's selected state, rather than its hover state. Is this something that users of touch-screen and other devices struggle with? Do we have a link to the usability testing that indicated a need for this? It'd be interesting to dig into that a bit to better inform our direction here.

Kjell is correct that we added the breadcrumb in response to the nesting UI being confusing. Since then the UI has morphed a fair bit. For example, all blocks now have permanent block type indicators in their selected state — i.e. even though a YouTube video doesn't transform into anything, it has an indicator:

Given the great amount of change that the UI has gone through, and given the purpose of this ticket, we should probably not be afraid to ask the question: what problem does these hover labels solve, and is there a different way to solve that problem? In that vein, I'd like to echo your comment here:

My understanding is that people don't seem to require a hover indicator in order to recognise that blocks can be interacted with, and so this effect is largely decorative.

Before that, though, it may be worth trying out #14145 (comment) which seems like a radical simplification that may just be sufficient.

[kjellr]

Closing now that #14145 has merged. Thanks everyone!