lobsters score: 1 · tags: a11y, design
Disclaimer here: this is from our company blog and it abstractly relates to a coding agent but it really doesn’t have anything to do with AI.
Interestingly what I learned from this is that there is no good contrast algorithm available today so we are trying to get people to do the survey so that we can get some good real world data points to get an open source algorithm for the contrast that is freely usable by anyone.
Survey is here if you are willing to take it: https://contrastsurvey.earendil.com/
score 5 · canonical
I think that survey is too long. It says “about 60 taps”, but I did a fair bit before getting to a section with 50 rounds of squares and words, which felt like a lot already, and then it went on to 8 rounds of animated/swapping squares, and that’s where I threw in the towel.
[edit] Oh, I see you addressed that in the sibling comment.
score 1 · canonical
Pi has around 60 color roles, from body text and dim text to panels behind tool calls and red text on a red error panel.
Perhaps I’m going to sound like a curmudgeon, but imho this is the problem that should be getting addressed, not figuring out how to eke out a few more readable contrast combinations.
The recentish trend to making every new tool spew its own custom blend of unicorn puke has me about ready to resign myself to setting a global
NO_COLORonce and for all.
score 1 · canonical
I don’t have enough recent experience with pi to really offer a specific critique, so this will be somewhat general (and more than somewhat opinionated.)
First off, to the original point… color (or other emphasis) should be used as a callout to highlight the most important things. When everything is important, nothing is. I struggle to comprehend how I could conceivably gain value by having up to 60 different color coded elements on my screen. That’s just too much to be memorized or fit any intuitive framework. I’d lose track of what they mean far before 60, and just start tuning them all out. (not to mention that ‘roles’ like “red on red” border on nonsensical.) Maybe you have 60 different semantic roles that are valid, but it seems like the default for the vast majority should be no custom color as it’s not adding anything. Let the user go all Pollock on it, if they must, with custom config.
Some other miscellaneous points wrt TUIs:
- Decide if you actually want a tui, or if you’re trying to build a web gui in the terminal (because it’s “easy”, “trendy”, “l33t h4x0r”…) and importing all of that baggage. I suspect a lot of the trends I’m seeing (and railing against) are at least partly the result of importing web design aesthetics and approaches to tui and cli tools.
- Don’t lean on panels/panes/frames/windows where you can avoid it. You likely need far less of that than you think or want. They can be useful, but in moderation, and hopefully without lots of excess decorations.
- Ruthlessly strip out chartjunk (tuijunk?) in general. Can you do without something? Can you do it with less ‘ink’? Can you do it without extra emphasis/colors? Can you do it without emoji or dingbats?
score 1 · canonical
I struggle to comprehend how I could conceivably gain value by having up to 60 different color coded elements on my screen
You don’t. That’s how how this system works at all. You can run Pi yourself and you will discover that Pi is very conservative when it comes to colors.
score 1 · canonical
For many months, Pi annoyingly insisted on a light/dark theme duo, with no option at all to disable the machinery that sets its own colors. Thankfully there was https://github.com/mavam/pi-terminal-theme.
But I can’t help but feel that this is needlessly complex. Typically a terminal application with a “native” palette maps its colors to terminal colors in a best effort manner. But I understand that it’s quite awkward to map a set of 60 elements to a set of 18 elements.
I believe that the contrast problem is better solved on the terminal emulator’s end. kitty has
text_fg_override_threshold, Ghostty hasminimum-contrastand iTerm2 has a minimum contrast setting as well. This detail is frustratingly missing from the discussion around Pi’s system theme design. I commend the enthusiasm of the survey but it’s important to be aware that some terminals will rewrite your colors anyway.As a concrete example, the
base16_transparenttheme in Helix is horrendous with most kitty themes I’ve tried. But a sufficiently high minimum contrast setting made it good enough. Incidentally, here Helix demands 76 colors, which sits uncomfortably close to Pi’s stated number despite the fact that Helix has a much less trivial UI.I don’t want every terminal application to be doing its own contrast calculations; I cannot rely on them doing so, thus I will set minimum contrast anyway so I don’t have to think about it.
Perhaps there should be a protocol that allows a terminal application to ask for contrast adjustments when it knows it’s using entirely too many colors and needs help.
score 1 · canonical
For many months, Pi annoyingly insisted on a light/dark theme duo
I’m confused you say that because Pi did not. You can set a basic theme.
score 1 · canonical
Yes there was
pi-terminal-thèmefor instance, which I have been using until the system theme was added. I should have said that the built-in themes were only dark/light, and that the issue of “fitting the terminal colors” was initially only remedied by an automatic switching between the two, before the system theme was added. I was referring to the out-of-the-box experience, which is how I used Pi really. The only extension I ever had waspi-terminal-theme.
score 1 · canonical