Skip to content
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

Hover state of Top Toolbar buttons do not match #17337

Closed
mapk opened this issue Sep 4, 2019 · 3 comments · Fixed by #17581
Closed

Hover state of Top Toolbar buttons do not match #17337

mapk opened this issue Sep 4, 2019 · 3 comments · Fixed by #17581
Assignees
Labels
Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Design Feedback Needs general design feedback. [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@mapk
Copy link
Contributor

mapk commented Sep 4, 2019

Describe the bug
The hover state of the Top Toolbar items do not match between the "Options" button on the far right, and the 5 buttons on the far left.

To reproduce
Steps to reproduce the behavior:

  1. Hover over the "Block navigation" button in the Top Toolbar.
  2. Observe the hover state.
  3. Hover over the "More tools and options" button in the Top Toolbar.
  4. Observe that its hover state is different.

Expected behavior
I expected the hover state of the "More tools and options" button to match that of the other buttons on the left side.

Screenshots

Block navigation button (hovered)

Screen Shot 2019-09-04 at 4 27 21 PM

More tools and options button (hovered)

Screen Shot 2019-09-04 at 4 27 06 PM

Desktop (please complete the following information):

  • OSX
  • Firefox 68.0.2
  • Gutenberg 6.4
@mapk mapk added [Type] Bug An existing feature does not function as intended Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Design Feedback Needs general design feedback. labels Sep 4, 2019
@Seniru
Copy link

Seniru commented Sep 14, 2019

Seems no problems with mobile phones .
But it has completely another style (check the screenshot below)
Screenshot_20190914-221335

My opinion is that there should be one style for all the platforms

@sarahmonster
Copy link
Member

💯 to normalising these hover patterns throughout the interface. There are actually a number of different hover styles that happen across the top toolbar:

2019-09-16 17 36 05

From left to right, I'm seeing:

  1. Soft border + slight depth created by a box-shadow:
    2019-09-16 17 39 58

  2. Slide up/down to a different icon entirely:
    2019-09-16 17 40 12
    This interaction seems to be limited to the transform menu alone—it would be interesting to test whether this interaction provides valuable information for users, since it's a rather aggressive animation.

  3. Hard border, no shadow:
    2019-09-16 17 40 28

Interestingly, we also seem to use different patterns for selected hovers. In some cases, they'll use the hard border:
2019-09-16 17 42 43

But other selected items won't change at all to indicate a hover state:
2019-09-16 17 40 48

Switching to a single, unified hover state for these interactions seems like it would be an easy win in terms of reducing some code inefficiencies and creating a more consistent and understandable user interface.

@Seniru
Copy link

Seniru commented Sep 16, 2019

@sarahmonster the effect with the settings, preview and publish button are OK (as they are for entirely a different purpose). But I agree with you with the other parts.

EDIT: I prefer to have soft bordered buttons for many parts. What are your ideas?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Design Feedback Needs general design feedback. [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants