New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a delay to the block type label on hover #9197

Merged
merged 4 commits into from Aug 30, 2018

Conversation

Projects
None yet
7 participants
@kjellr
Contributor

kjellr commented Aug 21, 2018

(Note: This is an alternate to #8836. It includes the block label hover delay but does not change the blue outline.)

Description

Currently, if you move your mouse around a Gutenberg document, each block will quickly present you with a dark blue outline and text label:

screen shot 2018-08-10 at 10 15 55 am

As noted in #8524, this can get jarring when you're just casually moving your mouse around the document. Additionally, I've wondered if that text label is a case of Gutenberg going to a little too far to answer a question the user hasn’t asked yet: "What type of block is this?"

Small, prominent UI elements like these contribute to an overall "heaviness" in the UI of Gutenberg. Especially when they're repeated on every block — these bits of UI add up quickly.

This branch adds a slight delay to the breadcrumb. This accomplishes a few things:

  • Eliminates the "flashing" of heavy UI when a user moves their mouse through their document.
  • Helps lighten the editing experience by lessening the appearance of a repetitive, heavy UI element.
  • Shows the label only when a user has made a more deliberate action (a slightly longer hover)

It does that without sacrificing discoverability of the label — the delay is short enough that the user is likely to trigger it during normal usage. They'll still know it exists.

How has this been tested?

Mac OS 10.13.6, in Chrome 68.0.3440.106 + Firefox 61.0.2
Windows 7, IE 11.0.9600.19080
iOS 11.4, in Safari (This PR has no effect on iOS, but I checked to be safe. 🙂)

Screenshots

Current:

Proposed:

kjellr added some commits Aug 10, 2018

Adding a delay to block hover animations.
When a user mouses over a block, they're currently presented with a dark blue outline and text label. This can be jarring, and add to a feeling of Gutenberg being "heavy" with its UI. This PR explores replacing that blue outline with a light gray outline initially, and introducing the blue outline and label after a short delay.
@tofumatt

I love it, I feel like the delay could even be longer, but that's me. I think I also prefer the extra changes in #8836, but I get there are some issues with them.

@karmatosed karmatosed self-requested a review Aug 21, 2018

@karmatosed

I really like this! It reduces the noise a lot.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 22, 2018

Contributor

CC: @nosolosw for draggable handle. I don't imagine this changes anything other than having to wait a millisecond for the drag handle to appear.

Contributor

jasmussen commented Aug 22, 2018

CC: @nosolosw for draggable handle. I don't imagine this changes anything other than having to wait a millisecond for the drag handle to appear.

@folletto

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Aug 22, 2018

This seems a good one for noise reduction.

I know the gif rendering is not ideal, but also seeing this I'm wondering if we should get away from the delay entirely. Fade in/outs are nice, but in certain contexts might introduce a feeling of "sluggishness" that is subtle but perceivable. What if we reduce the animation time or remove it entirely? Would it feel more snappy?

folletto commented Aug 22, 2018

This seems a good one for noise reduction.

I know the gif rendering is not ideal, but also seeing this I'm wondering if we should get away from the delay entirely. Fade in/outs are nice, but in certain contexts might introduce a feeling of "sluggishness" that is subtle but perceivable. What if we reduce the animation time or remove it entirely? Would it feel more snappy?

@chrisvanpatten

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Aug 22, 2018

Contributor

I know the gif rendering is not ideal, but also seeing this I'm wondering if we should get away from the delay entirely. Fade in/outs are nice, but in certain contexts might introduce a feeling of "sluggishness" that is subtle but perceivable. What if we reduce the animation time or remove it entirely? Would it feel more snappy?

I totally might be missing something but isn't adding the delay the entire point of this PR? 😅 Removing it would just revert to the behaviour that's live in 3.6.2, right…?

Contributor

chrisvanpatten commented Aug 22, 2018

I know the gif rendering is not ideal, but also seeing this I'm wondering if we should get away from the delay entirely. Fade in/outs are nice, but in certain contexts might introduce a feeling of "sluggishness" that is subtle but perceivable. What if we reduce the animation time or remove it entirely? Would it feel more snappy?

I totally might be missing something but isn't adding the delay the entire point of this PR? 😅 Removing it would just revert to the behaviour that's live in 3.6.2, right…?

@kjellr

This comment has been minimized.

Show comment
Hide comment
@kjellr

kjellr Aug 22, 2018

Contributor

I totally might be missing something but isn't adding the delay the entire point of this PR?

😄 @folletto is just referring to the animation speed. Right now, there's a 0.5s delay, and then the label fades in over the course of 0.1s. So he's just suggesting we remove/trim that 0.1s fade in. I'll give it a try and see what it's like.

Contributor

kjellr commented Aug 22, 2018

I totally might be missing something but isn't adding the delay the entire point of this PR?

😄 @folletto is just referring to the animation speed. Right now, there's a 0.5s delay, and then the label fades in over the course of 0.1s. So he's just suggesting we remove/trim that 0.1s fade in. I'll give it a try and see what it's like.

@folletto

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Aug 22, 2018

Argh sorry yes, it was very ambiguous. It's not about delay, thanks for the clarification.

folletto commented Aug 22, 2018

Argh sorry yes, it was very ambiguous. It's not about delay, thanks for the clarification.

@kjellr

This comment has been minimized.

Show comment
Hide comment
@kjellr

kjellr Aug 22, 2018

Contributor

I sped up the animation from 0.1s to 0.06s. This feels nice and quick. The GIF frame rate isn't quick enough to really represent the change, but here's a GIF anyway. 😄

hovers

I'd recommend giving the PR a spin to see it in realtime.

Contributor

kjellr commented Aug 22, 2018

I sped up the animation from 0.1s to 0.06s. This feels nice and quick. The GIF frame rate isn't quick enough to really represent the change, but here's a GIF anyway. 😄

hovers

I'd recommend giving the PR a spin to see it in realtime.

@gziolo gziolo added this to the 3.7 milestone Aug 30, 2018

@gziolo gziolo merged commit 346bdec into master Aug 30, 2018

2 checks passed

codecov/project 50.91% (+0.04%) compared to 3ee6407
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@gziolo gziolo deleted the try/block-label-as-tooltip branch Aug 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment