Some blacks are not correctly ordered when ordering by color about simple-icons-website

[jorgeamadosoria]

I've added my implementation. It looks as the image above.

[jorgeamadosoria]

I think this is heading in the right direction, if you reverse the black and whites (so the colors are followed by whites first, then blacks) it would be satisfactory for this issue. We could play around with the exact cutoffs for blacks and whites but this is a good start. Do you think you can replace the current implementation by yours?

It should be easy to invert blacks and whites. they are in different buckets so it would just be a switch.
Yes, the cutoffs for black and white do change the distribution of colors, the problem is that if you go too much in one direction, you end up with some dark colors that are not really black (think of, say, a red with a black overlay, that will be classified as black because of the luminosity). There is wiggle room, but unfortunately is not that much.

I can try and substitute the implementation and make a PR we can test live, let's see how that looks like on the web site.

[adamrusted]

Might this be something we can calculate ourselves by turning the Hex into HSL, and ordering primarily by Hue but then by either Saturation / Brightness to suit our needs? I imagine that's what a lot of color-sorter is, but may allow us greater flexibility if it's built straight into our own code?

[ericcornelissen]

Feel free to play around with it, you can inspect the source code of color-sorter (the dependency we currently use for sorting), try other color sorters, or implement something yourself. All you need to do to test this is update the value that is assigned to the sortedHexes constant in webpack.config.js.

Honestly, as a temporary fix I would be okay if we hard-code moving #181717 and #1D1717 to the end for now, if you can't find something else that works feel free to submit a Pull Request for that 😄

[jorgeamadosoria]

So, I've been reading about this, and this is a problem without a clear answer.
There is no way to order colors without some jumps happening from time to time.
Also, the library used even has some reference images that illustrate color jumps such as the one seen.

This is not so much a bug as an undesired behavior.
I don't think the library can be leveraged for something different. We would have to sort manually, use a different library, or live with this.

As I was reading, apparently this is a problem without hard solutions. Every color sorting algorithm encounters breaks in color continuity, and the only option is to choose where those are going to happen, not if.

[ericcornelissen]

I agree that there isn't a "best" solution, but that doesn't mean there necessarily isn't anything we can do. I think the goal of this issue to find what we, collectively, think is the "best" solution for our use case. To get to that I would suggest anyone working on this tries to play with the configuration of our current color sorter library, and possibly try some others libraries. That way we can see what "feels" right, and perhaps narrow down on aspects we find important (e.g., the order should look "as expected" above the fold - which it currently doesn't).

^{I will update the issue description for clarity}

[jorgeamadosoria]

I am scouring the web for alternative algorithms. They all have pretty visible trade offs, I'm afraid.

The most promising approach I've found is hue clustering: order the colors in buckets by hue, order each bucket by luminosity, and concatenate the buckets.
It looks like a series of up and downs from white to black, except each segment is a different color.

Can someone explaon why are we sorting by color, anyways? Is this a highly used feature, or does it provide an importanr benefit I'm missing?

[ericcornelissen]

I am scouring the web for alternative algorithms. They all have pretty visible trade offs, I'm afraid.

That's awesome, though I don't think we have to (or even should) go beyond using anything prebuilt that's available on npm. If you've come to the conclusion that there's really no suitable solution for the problem/example of the issue description than please do close this 🙂

The most promising approach I've found is hue clustering: order the colors in buckets by hue, order each bucket by luminosity, and concatenate the buckets.
It looks like a series of up and downs from white to black, except each segment is a different color.

I would personally prefer it the way we have now where it is (mostly) granular - with "pure" blacks and whites at the end.

Can someone explaon why are we sorting by color, anyways? Is this a highly used feature, or does it provide an importanr benefit I'm missing?

The project website originally started out that way. Following #38 we decides to switch the default to alphabetical ordering. I personally still use the colored ordering as neither colored or alphabetical seems "usefull" to me, and colored ordering is more aesthetically pleasing. If there's consensus I guess we could remove it but, at least to me, it doesn't seem like too much trouble to keep around as long as we already have it.

[jorgeamadosoria]

http://jorgeamadosoria.info/colorsorting/

a sample of ways to order by colors.
I don't think there is a lot of improvement over color-sorter.
Maybe a library can show improvement.

[jorgeamadosoria]

That's awesome, though I don't think we have to (or even should) go beyond using anything prebuilt that's available on npm. If you've come to the conclusion that there's really no suitable solution for the problem/example of the issue description than please do close this 🙂

Not yet at that point. I'll certainly do it if it comes to that, thanks for seconding.

I would personally prefer it the way we have now where it is (mostly) granular - with "pure" blacks and whites at the end.

That's achievable in some forms of sorting by lightness.

The project website originally started out that way. Following #38 we decides to switch the default to alphabetical ordering.
I personally still use the colored ordering as neither colored or alphabetical seems "usefull" to me, and colored ordering is more aesthetically pleasing. If there's consensus I guess we could remove it but, at least to me, it doesn't seem like too much trouble to keep around as long as we already have it.

It's no trouble, until such time as it starts to be perceived as buggy, by issues like this.
I'm ok keeping it, but only because it's already in. I see no advantage in sorting by color, really. Alpha should be more than enough. My reasoning is that people don't come to simple-icons to look for "a red icon", they come to look for "the icon for Google Calendar". So the color is necessary to provide the user with a guideline, but ordering... it tries to establish a one dimensional relation between things that don't really relate that way, and that the user doesn't necessarily need to have related that way.
I don't know, I find it unnecessary beyond aesthetics, and even then that's subjective.

[ericcornelissen]

I agree that alphabetically ordering is enough. I disagree that alphabetical ordering is "better" than colored ordering.

Alphabetical ordering is in no way going to help you find the Google Calendar icon. At best it's going to help you find an icon that is above or near the fold, beyond that there's just too many icons on the screen to make alphabetical ordering useful.

Actually, I would go so far as to say that not providing alphabetical ordering would be the better approach. Namely, it's an attempt to discourage people from looking for an icon manually instead of using a search option. (admittedly, having colored ordering as an optional second does nothing towards that goal.)

It's no trouble, until such time as it starts to be perceived as buggy, by issues like this.

That is a very good point, but I feel like it appearing buggy is not much of a problem as long as it's not the default ordering.

[jorgeamadosoria]

I agree that alphabetically ordering is enough. I disagree that alphabetical ordering is "better" than colored ordering.

Notice that I didn't say "better" I said "more than enough". Having said that, Alpha is, not better, but more fitting to the nature of the data. Alpha establishes a clear one dimensional relation between the icons, something color sorting can't do by its own multidimensional nature.

Alphabetical ordering is in no way going to help you find the Google Calendar icon. At best it's going to help you find an icon that is above or near the fold, beyond that there's just too many icons on the screen to make alphabetical ordering useful.

That is true, but notice that it's irrelevant to what is being discussed. The search feature is for that. Alpha helps find other Google icons if you know one, for example. Or it helps you traverse the list one by one in a natural order. Color sorting helps in... none of these things. It just looks somewhat pretty. Emphasis on somewhat, because as established, color sorting is an unsolvable problem and depends highly on what we decide the color order is.

Actually, I would go so far as to say that not providing alphabetical ordering would be the better approach. Namely, it's an attempt to discourage people from looking for an icon manually instead of using a search option. (admittedly, having colored ordering as an optional second does nothing towards that goal.)

If we can get consensus on removing color sorting and alpha sorting I wouldn't be against it. Font Awesome just came to add alpha sorting in version 6, I think, and I have used it happily for years without it. If we get approval for removing both sorting features and replace it with a category filter, I'll even volunteer for it. Alpha is good, but it's by no means necessary.

It's no trouble, until such time as it starts to be perceived as buggy, by issues like this.

That is a very good point, but I feel like it appearing buggy is not much of a problem as long as it's not the default ordering.

This is true.

[ericcornelissen]

Notice that I didn't say "better" I said "more than enough". Having said that, Alpha is, not better, but more fitting to the nature of the data. Alpha establishes a clear one dimensional relation between the icons, something color sorting can't do by its own multidimensional nature.

I can't not read "more fitting" (or similar wordings) as an indication of it being better. But that's irrelevant 🙃

That is true, but notice that it's irrelevant to what is being discussed. The search feature is for that. Alpha helps find other Google icons if you know one, for example. Or it helps you traverse the list one by one in a natural order. Color sorting helps in... none of these things. It just looks somewhat pretty. Emphasis on somewhat, because as established, color sorting is an unsolvable problem and depends highly on what we decide the color order is.

If you want "people to come here for the Google Calendar" to be an argument in favor of alphabetical ordering, than my argument must also be relevant. I'm not claiming color sorting will help people find the Google Calendar icon, just that alphabetical ordering (also) doesn't.

If we can get consensus on removing color sorting and alpha sorting I wouldn't be against it. Font Awesome just came to add alpha sorting in version 6, I think, and I have used it happily for years without it. If we get approval for removing both sorting features and replace it with a category filter, I'll even volunteer for it. Alpha is good, but it's by no means necessary.

I don't know what you're trying to say here. You want to remove both alphabetical and color ordering? Then what is the ordering we have? Are you suggesting we group icons by "category"? If so, you still need to order things within "category".

[jorgeamadosoria]

If you want "people to come here for the Google Calendar" to be an argument in favor of alphabetical ordering, than my argument must also be relevant. I'm not claiming color sorting will help people find the Google Calendar icon, just that alphabetical ordering (also) doesn't.

You misunderstand me. I'm neutral on alphabetical sorting. I don't care if it's in or out. I'm negative towards color sorting. The Google calendar example is not meant to indicate that alpha sorting helps on that or not, but to mean that people are more interested in names than in colors.

I don't know what you're trying to say here. You want to remove both alphabetical and color ordering? Then what is the ordering we have? Are you suggesting we group icons by "category"? If so, you still need to order things within "category".

I don't want to remove alpha sorting, since it is already in the project. It would be more work that we can't afford. The value of alpha sorting is neutral, so keeping it in is better than removing it in net effort.

I was thinking that categories is a good grouping for icons. Of course, they would have to be defined: Programming languages, Tech companies, crypto currencies, retailers, etc. It's an idea, but it's not something all that important. Feel free to disregard that.
And in a category, you don't need to order the icons. It doesn't matter, it's a bag, not an array. But it's fine if you order them alphabetically: like I said, for this type of project, alpha sorting is a neutral value.

Now, going back to color sorting, is any of the alternatives in my sample better than the current alternative?

[ericcornelissen]

I was thinking that categories is a good grouping for icons. Of course, they would have to be defined: Programming languages, Tech companies, crypto currencies, retailers, etc. It's an idea, but it's not something all that important. Feel free to disregard that.

If you think categories are a good idea, open an issue!

It doesn't matter, it's a bag, not an array

I understand where you're coming from from a technical perspective, but that doesn't translate clearly to displaying things on a website.

Now, going back to color sorting, is any of the alternatives in my sample better than the current alternative?

Forgot about that comment 😅 Nice work on that one! (here's a preview in case you ever decide to remove the webpage)

• Both "Default sort implementation" and "Sorted by color distance" mix colors more than the current implementation does (which tends to mix in whites and blacks instead).
• "Sorted by hue only" looks surprisingly good I think.
• Both "Sorted by hue,saturation, light" and "Sorted by hue,saturation, light" looks very close to what we currently have, except with the blacks and whites moved to the front.
• "Sorted by saturation,hue,light", "Sorted by saturation,light,hue", "Sorted by light,hue,saturation", and "Sorted by light,saturation,hue" all look pretty random I would say.
• While "Distance by buckets every 30 degrees with in-bucket sort by lightness" is pretty ordered, I don't think the repeated dark-to-light sequences look good overall.
• Both "Distance by buckets every 30 degrees" and "Distance by buckets every 60 degrees (primary and secondary colors buckets)" look pretty good, but not better than other options and having the blacks and whites in the middle doesn't look good I think.

All in all, I don't think any of the alternatives is better than what we have currently. Thanks a lot for putting this together though!

The only other avenue I can think of is trying to extract blacks and whites and sort the "colors" separately from the "grays" and then just append the "grays" after the "colors". I believe the previous version of our website used to do something like this based on the saturation(?). My knowledge of color theory is very limited, @jorgeamadosoria do you think you could investigate further in this direction?

[jorgeamadosoria]

The only other avenue I can think of is trying to extract blacks and whites and sort the "colors" separately from the "grays" and then just append the "grays" after the "colors". I believe the previous version of our website used to do something like this based on the saturation(?). My knowledge of color theory is very limited, @jorgeamadosoria do you think you could investigate further in this direction?

Yeah, I also don't think any of these is better than the current one. Maybe the buckets, but it has the issue of alternating dark to light per bucket, as you pointed out.

Now, regarding blacks, whites and grey, I guess that it is possible to mdoify the bucket algorithm to add a black, a grey and a white buckets at the end of the algorithm.
That would (in theory, depending on implementation) move all black, grey and whites, in that order, to the end of the sorted array. It would keep the dark jumps for every bucket, but would not show a very dark hard stop, rather a color would give way to the next in a softer (but not really soft!) transition.
I will work on that algorithm, it could be interesting. If anything else, it could be its own npm package :)

[jorgeamadosoria]

I've added a new approach: http://jorgeamadosoria.info/colorsorting/

Slightly better with the blacks and whites, but not perfect. Hey, at least the leading blacks are out of that position, so that's a win, I guess.
I honestly don't know how to make it better. Suggestions?

[ericcornelissen]

I think this is heading in the right direction, if you reverse the black and whites (so the colors are followed by whites first, then blacks) it would be satisfactory for this issue. We could play around with the exact cutoffs for blacks and whites but this is a good start. Do you think you can replace the current implementation by yours?