Speed up all the animations

[melchoyce]

They all feel just little bit slow, IMO.

Maybe cut the animation time in half?

[celloexpressions]

I generally find around .15-.18s to feel best, anything faster is hard to tell there's an animation at all. It's tricky here because they're completely inverting the text, so if anything they need to be longer than normal and the slowness could be a result of such a drastic change happening quickly but not instantly. Is there a reason that some properties have different durations than others? That might be contributing to the problem.

If it feels too slow, or IMO, a bit off for some reason, the timing function might be the issue. ease-in-out tends to be used a lot, but may not be the most appropriate answer here.

[ntwb]

Copying my comment from #247:

In stylelint we have a rule time-no-imperceptible:

"Disallow animation and transition less than or equal to 100ms."

The human eye supposedly can only see animation > 150ms

So, with the PR #247 @josephfusco just submitted changing many instances of transition to 100ms are these transitions actually noticeable at all from applying that PR?

Instead of 100ms / 0.1s should these be 150ms? Or removed all together?

[melchoyce]

Keeping comments in here for now, rather than #247, in case we spin off into a different direction.

Instead of 100ms / 0.1s should these be 150ms?

Yeah, makes sense in light of "The human eye supposedly can only see animation > 150ms"

If it feels too slow, or IMO, a bit off for some reason, the timing function might be the issue. ease-in-out tends to be used a lot, but may not be the most appropriate answer here.

I think this might be the case. I feel like I generally have a poor feeling and understanding of animations — I can tell it doesn't feel right, but I'm not sure what right is. Going to ping some folks I know are good at animations to get more feedback and thoughts here.

[folletto]

The human eye supposedly can only see animation > 150ms

Human eye can perceive beyond the standard 60hz (16ms) and up to 200hz-300hz (5-3ms) if I'm not mistaken, this is one of many sources you can find on the topic. The issue is not the human eye, but:

• Rendering: some rendering situations just can't render that fast (engine + screen refresh rate + frame rate combo).
• Perception: you see the animation, but you don't realize it's there. The effect however exists. I don't have any study but I'd guess the effect is felt given the brain can process it.

Even considering low standards of 45hz we are still on a boundary of 20ms.

[folletto]

I guess this ticket is talking about the links transition? In the past I did some transition research for inversion, and I found that "skewing" the transition rules helped. See this codepen.

The basic idea is to have the text to swap faster, then the background catches up. In the codepen it's slow-ish (300ms + 150ms) and with a standard ease to make the effect more noticeable.

Also note that in links we need to take care of links that go on multiple lines, which makes :before not a good choice. The solution I found to animate underlines was to use box-shadow with no blur.

[folletto]

I prepared three possible alternatives, based on the initial ideas I've seen (I hope I haven't missed any, sorry about that in advance).

Here's the codepen.

The three proposals:

1. Basic color inversion, faster, and with skewed speed tweaks to have crisp text.
2. Line animation, faster, using box-shadow, same skewing transition technique.
3. Without inversion, just going to black and adding a light transparently shaded background.

Gif rendering for quick reference, but don't refer to this for smoothness of animations :D

---

[folletto]

Added a fourth option to the codepen above that doesn't rely on background, and uses thickening of the underline plus a darkening of overall color. It's a bit different from the original design tho.

[joyously]

Out of the 4 options, I like the 4th best and the 3rd second best.

[celloexpressions]

Options 3 and 4 rely primarily on color, so aren't great for accessibility. I found option 2 to look fairly blurry for some reason (testing in MS Edge). I do think the different techniques in the first codepen help a lot as well.

[folletto]

Option 4 enlarges the shape, so it's not pure color. But I agree it might not be enough. :)

I'd leave to Mel's feedback since it's her design and I don't have full understanding of all the implications. :)

[melchoyce]

I like Option 4 a lot. Let me play with it a bit today and see if I can make it a little more obvious.

(I love 3 as well, but I don't think it has sufficient color contrast?)

[hugobaeta]

I think the 4th option is the most pleasing one from a visual design point of view. I experimented a bit to address the accessibility concerns, by extending the box-shadow down/out instead of up/in - effectively increasing its visual weight. I also increased the speed a tad and made the final stroke thicker than what @folletto had. Check out the codepen and let me know what you think.

[folletto]

✓ change direction of animation ✓ more visual weight ✓ faster — I think it's a good solution! 👍

[melchoyce]

Same. We might need to tweak it a little on some of the smaller links without underlines, like in widgets, but this seems like a good improvement to links as a whole. Someone want to make a PR using @hugobaeta's codepen?

[davidakennedy]

To clarify, would the :focus styles the same on :hover? Would there be any kind of outline on :focus? I think having the :focus styles the same as :hover would be okay from an accessibility standpoint.

[melchoyce]

What if we darkened the text and the outline a little on :focus?

[davidakennedy]

Well, I think it could stay the same as :hover. I was just asking about the outline. The larger box shadow should be enough of a visual indicator. Bu I'll check on that.