Make none-pinned language status items more prominent

[jrieken]

Here is a suggestion about the visibility, sorry for disturbing. 🙂

We find abnormal severity (error or warning) for unpinned status (which is the default behavior) is not easy to find, compared to the pinned item.

pinned error:

unpinned error:

Users will find the status easier for the pinned item than the unpinned item, since the background is different. Can we consider changing the background color of the pinned item as well? (or another way to help users find this status)

Originally posted by @CsCherrYY in #129037 (comment)

[jrieken]

This is about warning and error states but it also came up with default severities

[daviddossett]

This is about warning and error states but it also came up with default severities

Does that mean there has been feedback that it's difficult to notice the language status in the first place? I.e. with no warning or error?

[jrieken]

I.e. with no warning or error?

Yeah, my understanding is that that was part of the python/powershell confusion. Users don't really notice the {} icon. One idea was to animate it a little whenever any of its items changed

[daviddossett]

Ah, right. So essentially when something changes, but isn't a warning or error, we need some indication of that happening.

I can think of a few approaches here. I think the main challenge will be making it something accessible if it involves any sort of visual ping. Adding to next milestone.

[andyleejordan]

We could also default to pinning the language status items (or allowing extensions to opt-in to default pin setting).

[jrieken]

@andschwa That's not part of this discussion and something we currently don't plan for

[andyleejordan]

It's definitely relevant, as the core issue is that extensions that have opted into the new API (like we did with PowerShell) now have their icons hidden by default, and therefore not prominent. We have users complaining about this and it's still in our extension's preview channel 🤷

[jrieken]

I am not saying that your feedback isn't relevant but you should file a dedicated issue and not jump onto an existing, related issue

[andyleejordan]

You got it! New issue filed.

[jrieken]

I have pushed an experimental change to wiggle the status item a little whenever it has changed. For now it repeats once for normal status and 3 times for warning/error status. This is now always on but we should consider to tune this back when a user has sufficiently interacted with language status (and/or add a setting)

---

Demo: I have an extension that updates a dummy language status item whenever "wiggle" is typed in the active editor

Screen.Recording.2022-04-01.at.16.07.51.mov

[jrieken]

This is now always on but we should consider to tune this back when a user has sufficiently interacted with language status (and/or add a setting)

🆕 I have fine-tuned this to stop the "single wiggle" when the user has repeatedly interacted with the language status item (hover has shown at least 3 times). The warning/error wiggle is still there

[bpasero]

It almost fees like we need the same animation now for the notification bell because it would fit really well for the bell ;)

[andyleejordan]

Love it!

[CsCherrYY]

looks great! 👍

[jrieken]

To verify:

• make sure there is the F1 > Reset Language Status Interaction Counter, run the command
• open files that have language status, like JSON and TS files
• make sure the language status icon animates a little
• hover a few times over the language status icon and make sure the animation eventually stop
• open files that have severe status, e.g rust-files on insiders.vscode.dev
• make sure the language status icon animates a little more and keeps animating independent on the hover count

[alexr00]

I was wondering why I hadn't seen this before. I have animations turned off at the OS level, which causes the VS Code setting workbench.reduceMotion's auto to evaluate to on. I guess the wiggle animation respects that setting.

[daviddossett]

I wonder if this animation actually needs to respect that setting since it's not a major layout shift animation. @JacksonKearl had some input there IIRC?

[jrieken]

the VS Code setting workbench.reduceMotion's auto to evaluate to on. I guess he wiggle animation respects that setting.

Yeah, that's how it currently works. The CSS rules respect the .enable-motion class

[alexr00]

Even though I have intentionally turned off animations, I wouldn't mind/would like to have this specific animation. Having some animations respect the setting and some that don't might be a whole can of worms though.

[JacksonKearl]

Showing small motions (in terms of both amount of screen moving and for how long) that convey information is allowed even under reduced motion mode, this is noted in the WCAG standards: https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html

Success Criterion 2.3.3 Animation from Interactions (Level AAA): Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Essential: if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

Thus if we do not use some other way of messaging the user, it is appropriate to invoke a small animation.