Support for disabled Colors

[jlnrrg]

Idea

I thought about a feature where the developer can provide a list of color values, that either get grayed out or be non selectable in the color picker.

Why would this be useful?

I enable users to select their own player color in my app, which is in turn used in statistics. On initial creation the user gets a random color assigned which is not yet selected by another user. The user is able to change the own color, but it would be great, if a visual indicator would show which colors are already selected.

What is your take on this?

[rydmike]

Hi @jlnrrg,

They way I would approach that with existing features is to use the "custom" colors section in the picker.

You firs compute/provide a selection of colors that are still available for use, and add them as colors to the custom colors for the picker, and then you show only colors a user can choose from. Showing users colors that are not available and cannot be selected anyway, is perhaps not needed from a UX point of view?

You can name the custom tab whatever you want (as you can with all of them). However, if you only show one section, the custom one in this case, then the tab and its name wont even be shown.

If you only show the custom tab, that only contains colors that are available that user can choose from, you should be good to go. Naturally you would then also disable the shades selection, since in the shades of colors, for your provided as "available" color, a shade might already be taken.

---

If you want users to be able use the HSV wheel selection, to select any color out of 16.7 million in the RGB color space, well then I guess it is a bit tricker.

Then one would need some kind of color block list of value not usable provided to the picker. How many colors might be taken on it? 10, 1000, 10k, 100k? Performance might take a hit plus 1k already, when operating the wheel.

Plus a color that is just off by jus one in any of RGB values, from one that is taken, look for all practical reasons pretty identical to the human eye. So one would also need to implement some kind of minimum color space distance to use free color selection, to not be visually too close to something that is already chosen and on the "blocked/used" colors list. Hmm... :)

[jlnrrg]

This would be a tough topic to solve for the color picker wheel :sweat_smile:. I mainly was thinking about the primary and secondary tab. But with your explanation I can just build a custom one for those.

What is your take on providing a visual indicator in the ColorIndicator widget (I was thinking about smth like a cross out)

eg. (but with only one strike through?)

[rydmike]

Not sure I fully understand the use case. Do users choose a color for a game session, that can have "n" gamers, say 10, and none should have same color in the session? Then why not just show 10 different colors, with taken ones crossed out/over as in your image. Don't really need any color picker for that, just tiny bit of UI directly in the app.

But if it is a "user profile" associated color, always the same for a given user and should not match any users, then it is more challenging, and colors visually distinct to each other for the human eye, to the degree that it would be possible to associate it with a given player, is also a limiting factor. Plus it requires some color math to create the separation. Also the case for you to be able to provide available options that do not clash. Max users/gamers would then also be limited by max colors based on used minimum color separation logic.

In a color picker, why would I as a user want to see colors I cannot pick? Better to just show options I can pick.

If the use case is the situation I mention first above, with users joining for a quick game in a shared session and should pick a color to identify them for the session. Then a list of colors matching max gamers, where users get a random one by default, but can change among still available ones, where taken ones are/get crossed out like above, in real time as other joining users/gamers snipe them, makes sense. One does not really even need a picker component to pick colors for that usage scenario 😅.

Hm... so perhaps it is the "unique game profile" color scenario after all. Which as mentioned has other challenges, at least if/when amount of gaming profiles grows, with amount of "possible" visually unique colors available becoming a limiting factor.

---

As to what could be done in the FlexColorPicker, sure it could be done, but the use case sounds very specific, but doable of course.

After I have completed on going work on FlexColorScheme v5 (big updated in the works now). I plan to work on FlexColorPicker again and add some of the new features you can see listed as enhancements.

From a picker general applicability, many of those topics will probably be higher up on my list to add. But sure adding a feature that can make certain colors in the main Material 2 Colors and its Accent colors and their shades, disabled and even provide a custom disables color overlay style, is not that hard to do, so I will put it on the list 👍🏻

Currently I do kind of have higher urgency for other color space format pickers. A new picker "page" selector than the iOS slider, I want one that works with keyboard navigation too. And perhaps also multiple colors picking, so you can assign 2...n (max 20 perhaps), slots that you can pick a color for each slot, in one go... 💙