Erlang: icon colors are too similar to each other.

[zaroth]

One picture is worth a thousand words:

I'm not colorblind, but I have serious trouble with distinguishing the colors of .beam, .erl and .hrl at the first glance. This is especially troublesome with .beam and .erl files, which usually have the same filename produced by the compiler, and .beam files are basically binary and you don't want to open them in Atom, ever.

I included .py and .pyc in the screenshot. That's because IMHO .beam files, being binary, could maybe use a similar, very distinguishable at a glance icon as binary .pyc files. They fulfill a similar role in Python language.

[Alhadis]

FWIW, I actually am colourblind, and I'm total agreement with you. :|

However, icon shapes and icon colours are represented independently using CSS classes. Customising the shades of red/brown/whatever for Erlang icons specifically is easily done. Add something like this to your stylesheet:

.erlang-icon {
    &.medium-red::before    { color: #ea3a3c; }
    &.dark-red::before      { color: #a22c2e; }
    &.medium-maroon::before { color: #8f5536; }
    &.dark-maroon::before   { color: #8f5536; }
    // Etc …
}

Here are the lines in config.cson which define the colours for each Erlang-related file extension.

Now... me recommending this as a fix isn't a case of "hurrr, I'm too lazy, fix it yourself". It's because colours and contrast will vary drastically between users and their choice of ui-theme. What you're using now has worse contrast than, say, seti-ui, where a pitch-black background pronounces such colours better:

The complications of adding icon-specific colour tweaks is best left as an exercise to end-users, because if we started adding such adjustments for icons – for all users, we'd be drowning in monolithic stylesheets full of very subjective adjustments.

As I said, I am colourblind (not in the red/brown spectrum though 😉) so I know from personal experience how terribly subjective people's opinion of colours can be.

(For the record, pink sucks and yellow is gross. There, I said it. 😀)

[zaroth]

@Alhadis While I agree with your sentiment of leaving the customized tweaking to the end-users, I'm also a very strong proponent of sane defaults. That's because default settings rule the world:

• http://digg.com/2016/default-settings
• https://www.theguardian.com/technology/2013/dec/01/default-settings-change-phones-computers
• https://uxplanet.org/the-power-of-defaults-992d50b73968

I'm an example of that here. If I had installed a custom Atom theme, I would instantly take your advice, hell, I wouldn't have even bothered to create this issue in the first place. But no - this is me using the default Atom theme (fresh Windows install) with the default file-icons settings, being almost completely unable to distinguish at a glance a source code icon from a binary icon. Is this the out-of-the-box experience we want to give our end-users? 😅

[Alhadis]

You know what I'm a very strong proponent of? Telling people shit they don't already know. Permit me to enlighten you:

1. I haven't been maintaining this package forever. I'm not even its original author. It was transferred to my care long after it had gained a widespread presence in the Atom community, where the conventional way of tweaking icons had to be done with your stylesheet.

2. The colour-palette being used is drawn from the original colours used by file-icons. Which was before my time here. Notice there's a dark, medium and light variant of 9 base colours. How the hell do you comfortably distinguish dark red, medium maroon and dark orange if they just happen to be used alongside each other in the tree-view?

3. That binary icon you see? Not my handiwork. That's one of the default file-icons Atom provides out-of-the-box. As in, without the file-icons package installed:

   

   Notice they're all pretty same-ish and confusable? Yeah, I agree. So does every other user who's installed this package, probably. But we do retain their use for certain formats because it makes no sense to add a different image-icon, a different symlink icon, or a different binary-icon.

Atom's philosophy is "the hackable editor". Meaning, it's supposed to be changed, hacked, tweaked, twisted, and subject to any number of fathomable aesthetics a sick mind can concoct.

"Out-of-the-box experience" is a non-argument here. Maybe it made sense for whatever editor you were previously using (was it Apatana? PHPStorm? NetBeans? Something inflexibly boring?) In either case, that immalleable world is gone now – welcome to ours!

[zaroth]

While I don't really understand your hostility here, I do understand that you're against the idea of fixing this upstream and have strong opinions on the matter. I respect your decision. Thanks for the pointers.

[Alhadis]

That "hostility" is simply my annoyance at having you condescend to me on the topic of UX and program design, as though the links you posted are something that's somehow beyond my comprehension.

There's also nothing to "fix" upstream. It's subjective. Some people might find the icons too uniform, and most people might prefer icons that look much flashier. That doesn't make it a bug.

[zaroth]

I apologize if I came off as condescending - that was not my intention at all. I just like for my statements to be well-sourced.

[Alhadis]

So my issue was never with tweaking how the colors themselves look, but with the choice of colors for Erlang files themselves...

Alright, that would have come across a whole lot differently if you'd stressed that earlier.

Generally, I try to pick colours which match those of a logo's branding or the branding's official styleguide. That doesn't always leave me rich with options, so the colours I end up choosing are usually "analogous": that is, close-by on the colour wheel: For orange, that'd be red and yellow, possibly maroon. For blue, often cyan or purple, with an appropriate level of pitch (dark purple tends to flow nicely with dark red and shades of blue, anyway, I digress).

I won't lie: I know fuck all about Erlang, or what .beam files are (I'm assuming those .beams aren't light-related, right? 😉) When I googled, every Earl I came across was reddish-brownish-maroonish. Earlang is a red dude, and yeah, that's the extent of my rationale for monotonous colours. :D

Sometimes I do just resort to a truly random colour, because there are more XML-derived file formats in the world than there are visible wavelengths of light. 😀

[Alhadis]

FYI, the file-icons package is already adjusting colours for certain icons because their details are too faint to comfortably make out on certain backgrounds. That was my idea, and I felt @ahmadseleem's pain in #168 because I myself use/prefer light-coloured UI. So there's already some motif-sensitive corrections that take place. :)