Add colour naming (for us colourblind types)

[daveslutzkin]

I'm pretty colourblind. When I'm implementing a front-end I often have to create a variable name for a particular colour, and it's very hard to know where to start. Should this be $nice-yellow or $warm-green or $cool-orange?

I generally use https://www.color-blindness.com/color-name-hue/ to give me prompts on this. I don't need exact names - I'm not going to have 200 different colours in an app - but some little suggestions are very helpful.

I'd love it if Pika could also help me with this, by allowing me to see a name along with the colour value.

And of course if you need a real-life proper colourblind person to test with, you know where to find me!

[superhighfives]

Hey @daveslutzkin! Love this idea, and appreciate you taking the time to write it up. I wonder if this could be its own format (like "RGB, HEX, Named" where you can still copy out using the other formats. Or it could be displayed with the HEX / RGB, etc. Would be super keen to get your thougths.

And appreciate the offer to test it, too—I'm really keen to improve the accessibility of the app, with better voiceover support, keyboard navigation, etc (#28). Some of those limitations are on the SwiftUI side, so I'm thinking it'll be a focused sprint on that specifically. Currently it's sort of mostly functional, which... isn't good enough, really.

Anyway, I digress, love the suggestion, added to the roadmap to explore. Currently I'm working on 0.0.9, with which I'm also hoping to include more sensible ordering for the WCAG details.

Again, thanks for reaching out, and for the suggestion. Let me know what you think. 👍

[daveslutzkin]

(I should note I haven't actually used the app yet because this machine is still in 10.13 but I'll get around to a major version OS update one day surely. Surely.)

I think RGB, Hex, Named makes sense to me. You probably don't want to display it by default? I assume others (non-colourblind) don't want to see this clutter!

[superhighfives]

Yeah, fair! That said, displaying them could give a playful vibe to the app, which kind of ties into the "friendly" dot point of my product vision. But yeah, will have a think on it. 🙌

[superhighfives]

Adding this for future reference, from this tweet:
https://github.com/meodai/color-names

[meodai]

@superhighfives I like having names as well. Even if I am not color blind. It makes it easier to describe to color in a meeting or to come up with a good name for a variable or name in a style guide: https://github.com/meodai/color-names/tree/master/dist
I would suggest to use the "best-of" subset. They are all "certified fresh" by me or other maintainers ;)

Used the "best of" names here: https://farbvelo.elastiq.ch/.

[meodai]

@superhighfives saw the integration in the test version! Sooo cool.

Smoking Mirror | #a29587 would be correct probably if you are using the best of list

[superhighfives]

Yep, I'm currently only using the best of list, @meodai. 👍

[superhighfives]

Awesome, this is now live in v0.0.11. 🥳 https://github.com/superhighfives/pika/releases/tag/0.0.11

[meodai]

@superhighfives I'm so excited about this! Thanks.
Last question then I leave you alone with my names :D How do you update the list. The releases are pretty frequent at this point. (We just had a Major Release with some breaking changes, mainly fixing typos and a bit of spelling uniformity: using grey instead of gray...)

[superhighfives]

Hey @meodai! Yeah, that's a really good point, and I don't have a great answer, other than manually updating before a release (which is usually every couple of months). In a perfect world, Pika would periodically reach out and grab the latest list and store it for use, but to implement that would have networking, data storage, and potential security implications. I'm not sure if there's another option that comes to mind, than those two.

[meodai]

What about just packing it with the app when you release a new version? You can either add it as submodule or simply fetch the json or whatever you consume before you release a new version. Or maybe just have a folder in the lib that contains a json file? So if needed people could switch it out for an other names list (pantone for example that you can't ship with the app for obvious reasons). PS there are a bunch of other useful name lists here: https://github.com/colorjs/color-namer/tree/master/lib/colors

[superhighfives]

@meodai Updating it each release works for me! 👍 I think that's the easiest approach, at least in the short term.

In terms of supplying your own color names (which is in and of itself a super interesting idea) you could edit the package contents and replace the json file in the assets, but it would be overwritten for each update. So, I'd be curious if providing your own is a feature that people would be useful. At the moment it feels out of scope, but I'd love to hear it if anyone disagrees with me.

[meodai]

Yeah of course that is the perspective of a color name fetishist :D