Why I'm mostly not a fan of coloured text (in terminals or elsewhere)

September 13, 2021

I recently read someone who was unhappy that in this day and age, a Linux distribution specifically chose not to enable text colours in its default shell dotfiles (obligatory source). They have a point about the general situation, but also I disagree with them in practice.

On the one hand, the hand of theory, it is 2021. Our environments have been capable of coloured text for a long time (even if some people chose to turn it off), but here we often are, not using that capability. In many ways the default text environment is still single colour, with use of colours as the exception instead of the normality. In one sense, we really should have good use of colour in text by now.

On the other hand, the hand of practice, I'm glad that colour isn't used much because much use of colour in text is terrible (along with use of other methods of text emphasis). One technical reason for this is that many colour schemes for text assume a single specific foreground and background colour but don't (and often can't) force that, and wind up looking terrible in other environments. I run into this relatively frequently because I more or less require black text on white for readability, while many people prefer white text on black (what is often called "dark mode" these days).

A broader reason is that most colour schemes are not designed with a focus on contrast, readability, and communication (I think they're often not systematically designed at all). Instead they are all too often a combination of what looks good and matches the tastes of their creators, mingled with what has become traditional. This is colour for colour's sake, not colour for readability, information content, or clear communication.

(Even when some consideration has been put in for what the colours will communicate or emphasize, it often contains embedded value judgments, such as showing code comments in a colour that de-emphasizes them.)

There are probably text colour schemes out there that have been designed with a careful focus on contrast, readability, and HCI in general (and an awareness of the various sorts of colour blindness). But even in 2021, those colour schemes are a relative rarity. In practice, most colour schemes are various forms of fruit salad.

(This lack of careful design is not surprising. HCI-based design is hard work that requires uncommon skills, and also dedication and resources for things like user testing.)

I would probably like good colour schemes if they were common. Unfortunately, all too often my choices are either bad colour schemes or monochrome, and so I vastly prefer monochrome for the obvious reasons. In monochrome, all the text may blend together but at least I can read it.


Comments on this page:

From 193.219.181.242 at 2021-09-13 02:30:43:

Hmm, I agree about possibly not wanting many of the elaborate color schemes in apps, but I'll disagree about color in general – I do think that interactive shell prompts, specifically, should be if not in color then at least in some other distinct style (e.g. reverse).

I've noticed that no matter what program I'm using (be it Bash or the Python/Ruby/PHP REPL or LFTP or the MariaDB client or even the OpenVMS DCL), having the prompt displayed in just a single color helps immensely with how "friendly" the system feels (and of course with quickly finding where one command's output ends and another begins, when going through scrollback) – even if the rest of the system remains default black&white.

(Separately from that, I do wish that if ls doesn't use color then it should at least default to displaying the ls -F indicators for directories and other special objects...)

It's not the only way to do it, I suppose – with black-on-white terminals, whitespace (e.g. PS1='\n\$ ') would also be a good way to make the terminal contents less of a "wall of text", while color helps more on white-on-black.

By Opk at 2021-09-13 04:28:46:

Often few colours is better than either lots or none. Configuring man to do headings in colour is worthwhile and I have just two colours configured with LS_COLORS. There are cases where it is worthwhile to make good use of the 256 colour palette in which case I recommend the tool at https://www.easyrgb.com/en/create.php for choosing colours that complement each other well. This creates far less of a fruit salad effect than you get by only picking from the first 8 (or 16) colours.

Otherwise, I recently had to configure the default yellow from the basic 8-colour set to be rather darker just so it is even readable. This was precisely because of the growing trend among new utilities to use colour by default – especially with stuff written in Rust and Go for some reason.

From the designer perspective, it's troublesome to deal with color across environments. Building a terminal scheme, apps are thinking in terms of "this is green; we'll use it for 'good' status indicators," so the designer is wise to keep it in the neighborhood of both hue and luminance of the 'original' colors. Building an app-specific scheme, though, about 50% of xterm's default palette is unreadable on its white background, while they're great for (almost?) everything else.

Even if the app has an idea of whether the terminal is light/dark background and lets the designer react to it, screen terminal types can confuse it.

I also liked reduced colour in my terminal window: just the shell prompt mostly. I find it annoying that ls output also tends to colourized in recent years: I prefer "ls -F", with object types delimited by symbols on their ends (/@*) and not colours. I have no idea what it means when some text is red, but I do know what it means when it ends with a slash (/).

Another pet peeve of mine: I type "vi bar.conf" and Vim starts up with colourized syntax highlighting.

If I wanted Vim I would have typed in "vim".

Written on 13 September 2021.
« How many Prometheus metrics a typical host here generates
The rc shell's nice feature for subdirectory searching of $PATH »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Sep 13 00:24:34 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.