Hover effect timings
Open, Needs TriagePublic

Description

We currently use a mixture of instant hover effects and 150ms hover effects.

Using a non-zero duration for hover effects generally produces a feeling of lag, especially during fast mouse cursor movement. When moving the cursor fast, using a fade for hover effects delays the "feedback completed" time in response to the cursor to an extent where the animation can barely progress before it needs to fade out again, producing the feeling of an unresponsive interface. Additionally, there's non-trivial implementation cost to adding hover animations & keeping them all consistent with each other is a hard task. Hover effects are our most common effect, as virtually every control has a hovered state. All the Behaviour on, the Transitions, and in the more complex cases, tens of lines of C++ scenegraph code (and hundreds of lines of QStyle) add up to a lot of easy-to-remove complexity in our codebases for an unappealing visual effect.

Therefore, I would like to propose that we move the controls still using hover animations to instant hover animations to first and foremost remove the sense of lag pervading some of our hover effects, secondly to increase visual consistency, and thirdly to remove the surprisingly large amount of code dedicated to implementing something that worsens the user experience.

cblack created this task.Mar 30 2021, 2:52 AM
cblack updated the task description. (Show Details)

In general I agree, and I think that "hover lag" is indeed a part of what makes our stuff sometimes feel slow. Now that Plasna and QQC2 apps have gotten rid of their hover animations, I feel like the overall UX is a little bit better. I haven't missed the hover animations..

However the devil is in the details: perhaps the issue is that our hover animations were simply too slow. I think you did some work to introduce a shorter-duration unit that we could universally apply to these animated hover effects, right? Another alternative would be to set a duration of 16ms, which would result in an instant transition for people with standard 60Hz screens and standard animation timings, but users with 120Hz or 144Hz screens or who had increased their animation durations (i.e. people who are signaling with their choices that they like bling-bling visual effects) would get them.

However your point that removing all hover animations would eliminate a lot of code that can be buggy is well-taken.

Removing all the animated hover effects is the path of least resistance and probably offers the best bang for our time buck IMO.

@mart VDG

ndavis added a subscriber: ndavis.EditedApr 5 2021, 11:11 PM

IMO, It's best to enter the hover state quickly (or instantly) an leave it more slowly but still pretty quickly (shortDuration == 100ms). In order to make the QStyle match, the Breeze animation engine would need to be redesigned (it already doesn't match our Qt Quick animations), but this is easy to do in Qt Quick.

The reason why I think it's useful to have a transition after leaving the hover state is to prevent the effect from flickering rapidly, which looks a bit glitchy, annoying and unpolished.

Yeah that could work too. However even the leave animation duration can't be too long IMO. When any hover animation has too long a duration, it created this really weird effect when you hover move the cursor over multiple adjacent hoverable items, like in a list or a grid. IMO the status quo we have right now of no hover animations for our QML lists and grids is way better than what it used to be. If we do bring back some hover animations, I'd want them to be really fast and subtle.