Eui: [EuiButton] Remove hover state | translateY

[nickofthyme]

The first time I started to explore Kibana, long before joining elastic, the first thing I noticed was the button hover state and unfortunately, it was not because it was a pleasurable experience.

I wanted to open this discussion issue to see if there was a reason for the translateY on hover state.

⚠️ This is solely based on my opinion and I don't intend to offend anyone

Personally, I feel this hover state is very jarring to the user which is compounded with several buttons on the UI. This movement pattern also seems to be inconsistent with other hover states throughout EUI, if buttons move shouldn't all icons and other interactable elements move on hover too?

Proposed solution

My proposed solution would be to not move the "hit slop" of the button but add a _darker_ contrasting drop shadow on hover giving the illusion of movement without actually moving the button.

Screenshot

Thanks for the consideration 👍

[snide]

For better or worse one of the design principles we have on EUI's front page is

EUI is playful.
Consistent use of animation can bring life to our design.

I wrote that on day one because we knew very well that EUI itself needed to be extremely generic and almost boring as a UI that mostly surrounds the actual content (visualizations). At the same time there's a fine line between generic and "looks like everything else". That's generally why we use it.

We use animations on hover not just here, but also on the cards for example.

Or tooltips

Modals open with animations, flyouts, popovers. We animate "borders" on focused form elements. Toasts pop in with animation, accordions slide open and closed. These are all on click, but there's definitely a pattern to how we manage them.

A lot of this stuff also happens on focus. In small ways this helps with accessibility. The slight movement makes tabbing through buttons and form elements very clear. It's not primarily why we went in that direction, but it's something we know helps.

That said. Animation _is subjective_. There are some folks that simply can't stand it and find it distracting. And that's OK. For those folks Kibana has an advanced setting that limits it a bit.

The CSS file it loads is here. You're welcome to tweak it or adjust it. For some reason I notice it doesn't work on the buttons, but I think it just needs some more specificity (taking hover and focus into account).

Whenever someone brings this up (you aren't the first, so don't worry) I remember this setting and load it up. Personally I don't like it, but again, a lot of this is subjective, and I'm glad it's around for folks that feel strongly about it.

https://github.com/elastic/kibana/blob/master/src/legacy/ui/public/styles/disable_animations/disable_animations.css

Anyways. Thanks for your comment. That's at least some history and reasoning. None of this is set in stone, and we've gained more and more designers over time. Likely they have opinions on this as well, and I'll bring it up in our next review.

[nickofthyme]

Wow! thanks for the detailed explanation @snide!

To be clear I think animations, as done in EUI and in general, are FANTASTIC! The animations you pointed out including tooltip, modal, input, etc are all very different from the button hover state, mainly because none of those actually move the element being hovered.

The closest of those might be the tooltip appearing with a translation but the big difference between that animation and the button animation is that the tooltip is not "actionable" (that I have seen) it's just meant to show more information and not for the user to click on it. Nor is the tooltip the element being hovered.

The only issue I have with the button hover state is that the thing __moves__! Why does it move? 🤔 I would argue that this detracts from the overall UX and accessibility of the button. If we take the current hover state a "step" further, say 10px Y translation, the user almost has to fight with the UI to use it effectively, which is what this is doing at a much smaller scale. I'm am not privy to WCAG rules around this type of interaction but I think I could find something to say this is detrimental.

I've looked through a few UI design sites like dribbble as well as material guidelines and found no examples of hover movement, only hover emphasis. Like the _compose_ button on Gmail 👇.

This enhancement shows the user what is focused and without moving the element, by making it appear to be elevating of the page.

I feel like removing the animated translateY and enhancing the contrast of the animated box-shadow would be 1000x better button interaction. That means nothing in the UI moves on hover.

But it's up to you guys, thanks a lot for genuinely considering my ideas!

[snide]

Yep. I'll bring it up with the crew. They might agree. FWIW I stole the idea from Stripe originally so there are others out there doing it as well.

https://stripe.com/

[nickofthyme]

Hey just wanted to add to this discussion. I was at a 3PC (3rd party conference) yesterday and the user was using kibana and happened to get the mouse into an "infinite twitch state" because of the button focus y-transition. The video is not very clear but the cursor goes from pointer to default over and over on the button boundary.

[cchaos]

Related: #2544

[nickofthyme]

This also adds complications to overflow: hidden elements.

[cchaos]

Yep! And the fix from EUI for that specific instance is in Kibana master already 😉

[monfera]

Related: https://github.com/elastic/eui/issues/3975