Should we remove hover animation?

[illright]

I really don't think this is even desirable for a datatip since it leads users to believe that the datatip is interactive, while in reality we have #60. If we want to make the datatip prettier, I think a good way to do that would be to follow VS Code's approach to simply animate the appearance/disappearance of a datatip.

And certainly not have it as an option. The fewer options, the better.

but but accessibility...

Yeah, of course, some users prefer reduced motion. However, the way to do it on the web is with the browser and media queries. I'm not aware of a way to make Atom make Chrome send out a "prefers reduced motion" signal and use the corresponding media queries, but the most we can do is to simply put that animation behind a media query such that if in the future there will be an option to signal the preference of reduced motion, we'll have this working out of the box.

[aminya]

The glow option helps the datatips to be visually different from the surrounding code.

[illright]

As I've mentioned in #109, in my opinion, it really doesn't, for these reasons:

• the datatip should be visually different from the code all the time, not only when it's hovered
• the shadow does a good job at distinguishing the datatip from the surroundings
• on hover, the datatip background becomes lighter, which on light themes makes the datatip even less distinguishable

And it brings issues, such as:

• being a rather questionable and not well-described settings entry (if this is important, it should be the uncustomizable default)
• misleading users into interactivity that the datatip doesn't provide

[aminya]

The glow design is inspired by Twitter and the old ide-ui package by Facebook. This is a nice little animation which makes the editor look alive.

being a rather questionable and not well-described settings entry (if this is important, it should be the uncustomizable default)

We just want to make it possible for those who don't like this to be able to disable it.

misleading users into interactivity that the datatip doesn't provide

The selectability/copyability of the text inside the datatips is fixed now. The buttons, hyperlinks, trees, etc are all interactive.

I think there is nothing more to discuss here. Comment if you think this should be reopened.

[illright]

I think it should.

We just want to make it possible for those who don't like this to be able to disable it.

There is always a custom Atom stylesheet for that, where people could easily override this behaviour. I believe this shouldn't be a config option, otherwise it invites a lot of other style options into the config, something that Atom already allows tweaking easily.

We can still make it easier for users to disable it though, by adding a snippet of code to add to the stylesheet in the README.

[calebmeyer]

on hover, the datatip background becomes lighter, which on light themes makes the datatip even less distinguishable

This is the strongest argument I've seen, but seems more like a bug (should go darker on light themes) than a reason to throw it out.

if this is important, it should be the default

This I do agree with, but I also prefer code already written. If it's already a setting, I don't think it hurts to leave it one.

[UziTech]

There is always a custom Atom stylesheet for that, where people could easily override this behaviour. I believe this shouldn't be a config option, otherwise it invites a lot of other style options into the config, something that Atom already allows tweaking easily.

I agree, Atom allows changing styles for a reason. When something can easily be changed by a style it probably should to keep the settings cleaner.

the datatip should be visually different from the code all the time, not only when it's hovered

I feel like this invalidates the only point I have seen for the glow.

[aminya]

As discussed in the discord chat,
I have a couple of utility functions for retrieving the styles. I should move it to atom-ide-base, so we can use it in other packages too. We can use that to check if the background color is lighter or darker than rgb(128, 128, 128).
https://github.com/atom-minimap/minimap/blob/master/lib/dom-styles-reader.js

That means we can have a isThemeDark function and use that to adjust the animation and styles.

[DeeDeeG]

Is there a screenshot or animated screen capture to consider? That would help me understand what this is about. Thanks.

[aminya]

Is there a screenshot or animated screen capture to consider? That would help me understand what this is about. Thanks.

You can install atom-ide-base and atom-ide-javascript to get datatips.

[aminya]

To make linter tooltips look similar to the datatips (#117), whatever decision is made should be applied to linter tooltips as well. e.g. the same animation should be added to the linter tooltips.

[UziTech]

I haven't heard a good reason to have the glow. What are some arguments for it?

[aminya]

1. This animation is an artistic effect.

If you want to know why humans like animations, you can see this article.

Why animate?

2. It makes the editor look alive.
3. The responsiveness makes it apparent that it is interactive (e.g. buttons).
4. The glow option helps the datatips to be visually different from the surrounding code.
5. The glow design is inspired by Twitter and the old ide-ui package by Facebook.

The above arguments don't mean that the animation can't be improved. If there is a bug (e.g. in the light theme) it should be fixed. So, please keep the focus of this issue only on the existence of the animation, and open other issues for the bugs.

[DeeDeeG]

Here's a screen recording with the default style (on macOS):

Screen.Recording.2021-02-07.at.10.55.29.PM.mov

[UziTech]

For the record I am neither for or against it.

1. This animation is an artistic effect.

Seems like unnecessary complexity.

2. It makes the editor look alive.

I don't see why that would be a good thing.

3. The responsiveness makes it apparent that it is interactive (e.g. buttons).

But if there are no buttons (interactivity) then it is just confusing.

4. The glow option helps the datatips to be visually different from the surrounding code.

Seems like @illright point about it always being visually different mutes this pro.

5. The glow design is inspired by Twitter and the old ide-ui package by Facebook.

Doesn't seem like a pro or con.

[DeeDeeG]

I am also not strongly for or against.

I can agree the "glow" hover animation probably breaks some design guidelines. I find it tolerable, and kinda nice, but it's arguably distracting. (It all balances out to being about "neutral" for me.) I do think a large corporation with a designer on staff would probably remove the highlight animation. But this is a community project and there's maybe more room to bend the rules for stylistic flair.

More thoughts on design principles at work here

Copyable text is not traditionally a kind of interactibility that you would make a highlight animation for. A highlight animation usually means if you click, something will pop up, or you will follow a link to other content, or jump to somewhere else. Otherwise the focus it draws is considered to potentially be distracting or confusing, and not worth it. It makes more intuitive sense for me in the Twitter example, in a "design guidelines" way, because the hover animation is associated with clickable links. So the hover animation used for the datatips is really just an arbitrary style choice. There's pretty much no hard rules in design, but this is a fairly established convention I think.

(If clicking the datatip would copy its content to clipboard, or do some relevant action, then I think the hover animation would make more sense.)