I find quite funny that the author is so convinced that the use of colors is the "right default".
1) I'm colorblind so my view of colors is different from yours.
2) I find that any tool which use many colors suck: there will be a color combination which will be hard to read (for example git log: the sha1 keys are dark red on black, unreadable) but using just a few color is very nice (git diff: 3 colors, one for +, one for - and a third one for the rest, nice!).
Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!
Sorry the colours aren't working out. One of the feature requests in exa's pipeline is the ability to customise the colours, so you could make everything use bold colours if it's too dark, or make more things the same colour if it's too garish. Would something like this make it usable?
Speaking about the point in general, though, I think that terminal programs have been in a chicken-and-egg situation for the last decade or so with ANSI colours. Because colours only get used sparingly, not all terminals have good-looking colour schemes by default, which means they often look ugly, which means they only get used sparingly. There shouldn't be any reason why a terminal program should ship with unreadable colours by default (I have been killed in NetHack before because the default 'blue' colour in PuTTY was so dark, I could barely see it), and terminal programs that output colour should be smart about it (disable colours by default when not to a terminal, to avoid problems with grep like the one you cite).
Is the problem really that there are colors, or that the colors used don't work well for colorblindness? Do you find coloring that doesn't go afoul of your particular type of colorblindness still less useful than no coloring, or is it just that so often little attention is paid and an assumption is made that it's no worse than monochrome when in actuality it sometimes is?
I guess my real question boils down to if whether the author tried to make the default color profile at least not horrible in some respects for most colorblind users, would you still think defaulting to color is the wrong default?
From my experience as a colorblind person, the use of color to convey information falls into several categories.
1. It improves the presentation of information. The vast majority of colorblind can still see color. In this respect, we are no different from people who have normal color vision.
2. It has no impact upon the presentation of information. In these cases, the colors may not be distinguishable but there are other cues that convey information. I typically think of these cues as context. An example of context relevant to to exa is the column or character used to represent the information.
3. It degrades the information being presented. In addition to there being different types of colorblindness, each type seems to be variable. That is to say that most colorblind persons aren't actually blind to a particular color, they are simply less sensitive to that color. This means that they may be able to see a color if it is intense. Using colored text is really bad in this respect since it is typically less intense, likely due to a small number of pixels being illuminated. This reduces the legibility of text to varying degrees.
4. It makes information illegible. This is essentially the extreme version of case 3. This happens when the contrast is so low that color is the main distinguishing factor, so it may be nearly impossible to distinguish two adjacent colors (such as foreground and background colors for text).
Take anything that I say at face value. It is largely based upon personal experience. The only thing that I can say with certainty is that colorblind people see color differently. I suspect that people with normal color vision suffer from similar issues to colorblind individuals. It simply manifests itself in a standard way so that there are standard design methods to avoid it. Of course colorblind people throw a wrench into the works because their vision is calibrate in different ways due to their sensitivity to each color.
Does it not make sense for the colourblind person to adjust the colour definitions for their terminal, so all programs give acceptable output? Just as a myopic person may increase the font size.
I don't think it's colourblindness, but I have trouble reading ANSI blue, which xterm defaults to rgb(0, 0, 238). I've changed it to be a roughly Persian green colour rgb(0, 166, 147).
If I had the most common male colourblindness, I'd probably add some orange to the default reds.
Sure, I'm largely aware of how colorblindness works (my father is colorblind and my friend is colorblind and I've discussed it multiple times with each). I'm really looking for whether experiencially you, or the root comment, have experienced good color schemes that work well within the constraints you impose, and whether that alters the statement slightly from "it should not default to color" to "it should not default to color unless done well".
I understand that the answer may be different for different people in somewhat non-subjective ways, since there are different types of colorblindness.
In the case of text that means asking the question: does removing all color remove any information? If the answer is no, then a colorblind individual can use other cues. (While my prior post focused upon legibility, two different colors may look like the same color to me even when the text is perfectly legible.)
I would also suggest keeping the number of colors used to a minimum. More color combinations means more opportunities for problems and more difficulty in resolving those problems by setting a custom palette.
Finally, only use color when it adds value. The use of color to highlight different file types was useful. (The file extension still existed as a cue, which is great.) The use of color to highlight columns is just asking for trouble without adding value. It is not adding value because all of the elements in a column are the same color anyhow, so it adds the risk of reduced legibility without highlighting anything in particular.
Point 4 is the overriding problem. I have never been able to find a color scheme that works acceptable for text on light background and for text on dark background. It is virtually impossible to find a good pleasing and legible color scheme that works just on text on a light background.
I do not like this attitude one bit. exa isn't here to make money, it's here to list files; if somebody can't use the software, then that's one less member of the community and one less person who can offer suggestions, rather than a resource who wouldn't give me a return on my investment.
If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.
I see where you are coming from (you want your software to be used by as many people as possible), but this really isn't the pragmatic approach to this type of software.
For certain products, this approach makes sense. Generally, this approach works for "any software where more adoption means a better experience for an individual user". Examples: a messaging app, anything with its own format (like a word processor), because it makes sharing easier, or anything which I need to work with as part of a team (version control).
This is not that. File listing programs are local and isolated. My experience using some file listing program does not improve if more people use the one that I am using. In this case, it makes more sense to have exa or ls or whatever be the software that addresses 99% of use cases for the average user. Then, for the portions of the population with particular needs, you make software that is particularly tooled towards them.I am not colorblind, so having support for colorblindness just makes software more bloated.
tl;dr - I agree with your sentiment when it comes to programs that need/want "universality". This is not one of those programs and doesn't need to be.
Ah, I'm with you now. And yeah, I do agree that a line has to be drawn somewhere. exa would probably fail if used with a screen reader, or heck, it doesn't even work properly under Windows right now. That's a huge market I'm ignoring!
What I've seen people doing is saying that there's no line at all: every feature needs to have its cost justified, every type of user scrutinised to make sure they're not dragging the product down. This is expected behaivour for startups (launch to a limited market first) and big companies (where you need to justify every cost) so I'm not surprised to have encountered it here.
For colourblindness in particular, though, I still think there has to be a way for the default colour scheme to be colourblind-friendly without the experience for everyone else suffering as a result.
Expecting every single command-line application to support different colour schemes for colorblind people is insane, not because the effort it worthless, but you are asking it to be spent on the wrong level of abstraction.
I know that Gnome Terminal supports[1] different colour schemes which you can customise, and I think this is the point where it should be implemented at.
My trouble is that most terminals have color settings such that colored text is not very visible. I really wish I could have a large number of different-colored terminals for different tasks, and that is easy if I turn off color, as designing a whole color set that always works is a bigger job.
What's funny is that colored interfaces worked just fine on IBM 3270 terminals in the 1980s, as they did on PCs. I can't understand why we can't get it to work right in the 2010s.
Another tricky thing is finding a colour set that works against various backgrounds. A ton of people use either black or white backgrounds. Occasionally you come across a different colour (eg: some people use red backgrounds for 'root' or 'production'), but even if you exclude these folks, getting something that works with both black and white backgrounds is a minimum requirement.
Every new terminal I open uses a random background color. All colored text is always readable.
What I did was make sure the background colors were always dark, and set the first 16 terminal colors to be light. I randomized the background color by specifing it to the terminal via a command line option as the output of this 10-line script[1] that takes an HSV Value as an argument and returns an RGB with randomized Hue.
It's nice for terminals to be differently colored when you have many of them open. It helps one to realize when you've switched to the right one.
iTerm2 lets you force a minimum contrast, which solves the contrast problem while still letting you use colors. Lots of programs display hard-to-see colors (red-on-black for me too), so it makes sense to address this problem at the terminal level.
> Sometimes an application will display text with a color combination that is hard to read. Colorblind users in particular may find certain combinations hard to see if the colors differ only in hue and not brightness. If you enable minimum contrast (under Preferences > Profiles > Colors > Minimum contrast, then iTerm2 will guarantee a minimum level of brightness difference between the foreground and background color of every character. If you set this to its maximum value, then all text will be black or white.
BTW, I actually like having the git hashes almost invisible. I don't need to see the hash, I just want to double-click to copy it.
Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!
So colors by default? Thanks but no thanks.