Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration for diagnostic icons #12060

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

smbroadley
Copy link

This is to aid accessibility.

Some themes are not great for colourblind people. With this configuration, they can easily change the icons that appear around the editor (gutter, status bar) to make them easier to distinguish!

Stephen Broadley added 2 commits November 13, 2024 01:27
This is to aid accessibility.

Some themes are not gread for colourblind people. With this
configuration, they can easily change the icons that appear around the
editor (gutter, statusbar) to make them easier to distinguish!
This is to aid accessibility.

Some themes are not gread for colourblind people. With this
configuration, they can easily change the icons that appear around the
editor (gutter, statusbar) to make them easier to distinguish!

small fix
@nikitarevenco
Copy link

thanks, this is fantastic!! #1 rule in design is to not rely on color (well, there are a lot of #1 rules but this is one of them) :)

@the-mikedavis
Copy link
Member

the-mikedavis commented Nov 13, 2024

I'd like to see the defaults changed rather than introducing more config especially if it's for accessibility - we should shoot to have something that reads well out of the box. Instead of reusing the same circle glyph for all diagnostic levels we should be able to find different simple glyphs. Maybe a triangle for warnings, square for errors, circle for hints.

@smbroadley
Copy link
Author

Interestingly, those glyphs are what I have set my custom cut to. 😄

@koolfy
Copy link

koolfy commented Nov 13, 2024

We could progressively more eye-catching glyphs as we move from "INFO" to "ERROR", so that even with a dense file with lots of LSP information, one might be expected to visually find the important ones and ignore the noise.

  • HINT: ⋅
  • INFO: ○
  • WARNING: ●
  • ERROR: ✕

edit: I edited down my obnoxiously long comment because omg I am bad at getting to the point

@smbroadley
Copy link
Author

You shouldn't have edited your message! It was heartfelt and important. It is only when we hear about a product experience that we can start to find a way to improve it.

I have been taught many a time that my designs do not work for everyone; AND while making something for everyone is hard, it is seldom impossible.

We have maintainer alignment, and we will have improved the experience for everyone! Go team!!

@nikitarevenco
Copy link

nikitarevenco commented Nov 13, 2024

Having complex symbols can add clutter and I really like what the-mikedavis suggested, so here's my take on it:

  • circle for info
  • triangle for hints
  • square for warnings
  • pentagon for errors

I really like this approach because there's a clear design here. The sharper the symbol, the more severe it is:

  • Info has 1 side
  • Hints have 3 corners
  • Warnings have 4 corners
  • Errors have 5 corners

Usually sharp and pointy things are associated with danger. So having it be on levels like that sounds like an idea to think about

@nikitarevenco
Copy link

Imo it's important that the design is consistent. We can't just have one icon try to convey meaning and another is an abstract shape. Or one is filled and the other one isn't.

@smbroadley
Copy link
Author

Thankfully, I have a build where I can easily change them at runtime, and sit with those choices for a bit. I would love it for you to do the same and see if you still feel like those work! (I will!)

@smbroadley
Copy link
Author

One additional wrinkle for this that I'm not sure of is which glyphs are we leaning towards that we expect will render consistently across platforms!

@the-mikedavis
Copy link
Member

I don't have strong feelings about most of the glyphs but I would prefer triangle for warnings since it looks like a simpler '⚠️' (https://emojipedia.org/warning).

Similarly I think a square works nicely for error because of similarity to '⏹️' (https://emojipedia.org/stop-button).

I'll try these for a while and see what I think but I am running with:

  • error:
  • warning:
  • info:
  • hint:

locally.

Info severity doesn't seem to be used often so I think it's ok that info and hint are somewhat harder to distinguish than the others.

I'd like to keep these glyphs as simple as possible since monospace fonts can be a bit unpredictable - more complicated symbols like https://symbl.cc/en/2297/ can look quite busy on some fonts. And anything with more than 4 sides can be hard to recognize at a glance IMO.

@smbroadley
Copy link
Author

There is one other thing that irks me: currently in the status line we render warnings, then errors. For some reason my brain hurts seeing it that way. (Hello arbitrary bias!) 😆

@koolfy
Copy link

koolfy commented Nov 14, 2024

@nikitarevenco I like the logic of more pointy = more priority intellectually, but I realized the flaw when I found myself squinting and getting my face closer to the screen to notice the difference between the info circle an the error pentagon (coincidentally the worst possible confusion of opposite priority levels)

swappy-20241114_010402

It may be because of my dark mode, my browser font or like @smbroadley suggests how my system renders these glyphs

Also a file rich in these indication (that ugly code it fell on you to refactor ahem ahem) might initially be a shapes-soup, where info is as visually-heavy as warnings and hints look like high-priority/danger road signs

Before landing on the very distinct cross, I was going to suggest a triangle for "ERROR" for this exact reason, in all cultures the triangle is the ultimate priority because the roadsign conventions are universal and commonplace

The "more corners" rule might be confusing in a file with only hints and warnings: without context one might reasonably assume most attention should be payed to the "caution triangle" than to the "square whatever" and

  1. not realize the triangle is not an error and can be safely ignored
  2. exactly invert the priorities of INFO and WARNING

I also find that in hidpi environments with large screens that might not be that close to the eyes, small similarly-sized shapes might become harder to distinguish. A solid square and a solid circle can look alike in these situations.

The smallest ⋅ can never be mistaken with another symbol, the ○ is the only hollow shape (and that's easy to distinguish in any font and any size) , the solid ● is effectively the only "solid" shape and the ✕ is both un-ambiguous in its meaning and so far from all other shapes that no confusion is possible no matter the font, size distance or visual acuity

I have 20/20 vision but only this proposal can still be worked out standing very far away or squinting, without relying ot making the glyphs bigger and more visually distracting (it also works if you don't realize/pay attention to the "more corners" logical rule)

However, the original intent behind this PR is to adress color-blindness, and for that any shape would do :) so I won't argue further
If it remains configurable on top of better defaults, I can live with setting these glyphs I like on my config file.

@smbroadley
Copy link
Author

smbroadley commented Nov 14, 2024

I'm currently rocking:

[editor.diagnostic-icons]
error = 'x'
warning = '▴'
info = '•'
hint = '•'

and

[editor.diagnostic-icons]
error = '!'
warning = '▲'
info = '•'
hint = '•'

@smbroadley
Copy link
Author

Also:, this isn't terrible:

[editor.diagnostic-icons]
error = '≡'
warning = '▴'
info = '•'
hint = '•'

@koolfy
Copy link

koolfy commented Nov 14, 2024

I've been using the glyphs I suggested for a day (got tunnelled into my work and forgot to switch them around), but I only encountered hints and errors, no warnings or info!

I noticed the ⋅ for hints really works well to de-clutter with un-obtrusive icons for such low priority diagnostics.
Often I noticed underlined text first, and only then did I look for the diagnostic icon to see it was a hint, it never distracted me away from the code right away (because it's so small and stealthy)

Errors with the ✕ worked very very well, I had zero doubt about what they were, no hesitation and they always stood out.

I think it might make sense to have the same symbol for hints and info levels, as they are both almost equally "less-relevant", whatever we land on I would agree that the first priority for hint and info is to be "non-distracting"

The problem I have with mixing triangles, "!", crosses etc for warnings and errors, is that it will never be immediately clear which one is the "clearly broken" one.
If we set warnings to triangles and errors to an exclamation mark, and when you open the code you see either, they both look severe enough that they might be errors.

I think the warning glyph should be visually noticeable but avoid any "threatening" symbolism. Exclamation marks, crosses, triangles and anything culturally associated with danger should be reserved to actual errors

For example:

[editor.diagnostic-icons]
error = '✕'
warning = '●'
info = '⋅'
hint = '⋅'

works very very well for me and allows zero confusion in any direction (as long as we consider it's okay to conflate hints and infos. If it remains configurable., someone who really cares about hints vs info day-to-day might be okay overriding it. To me it feels like an uncommon enough usecase.)

Any of the ▲ ! or ✕ would work equally for errors I would say. Maybe "!" a bit less so as the glyph being aligned to the left of the window a slim vertical shape might not be spaced enough from the window border to stand out, but I'm nitpicking.

My only gripe with ≡ is that it misses any of the visual clues commonly associated with danger/warning signs, so a new user might think this is the hint/info/warning "less-threatening" symbol and would need to mentally learn this symbol.

But again, this is just feedback, at this point a distinctive glyphset solves the initial issue raised and I'm perfectly happy overriding sane default with my preferred symbols, so this opinion should not stand in the way of merging another proposal ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants