Improve default favorite color temps and colors

[Hypfer]

Proposed change

Today, I found myself wondering why I didn't really use the favorite colors feature.
I've asked around and heard the same from other people, so I thought that it would be worth looking into.

The answer I arrived at eventually was "Because it doesn't offer what I actually want".

When plotted, I've noticed that the colors provided do only cover a very limited subset of the color wheel:

The Kelvin generation in the prior config (for a light with 2000-6500k capability) ended up with

with the standard 2700k nowhere to be found.

So what would I actually want?

For colors, a more even distribution, so that the defaults allow me to test all the capabilities of my lights.

These are the ones I've settled on, but I don't have any strong feelings about them. Any other set with an equal coverage would be fine.

For color temperature, I wanted the minimum the light can do, the maximum the light can do and common presets (2700, 4000,5500). So the code now does that if the light has that spectrum, and if not, it synthesizes some middle steps to fill up the total preset count.
That ends up looking like this for a light that can do 2000-6500k

To achieve this, I've raised the number of favorites to 5 each and also raised the width to fit the 5:

(Color temps and color order in this screenshot are not what the code in the PR generates, but from an earlier state)

I'd say it's fine. It's a bit more bottom-heavy now, but I'd argue it's worth it.

Additionally, I've noticed and fixed this

which was technically correct, but likely confusing to less technical users.

And, finally, nothing seems to have used formatTempColor anymore?
So now it's gone.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: N/A
• This PR is related to issue or discussion: N/A
• Link to documentation pull request: N/A

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[PlasmaPod]

Wait I had no idea you could tap and hold them into wiggle mode to remove or add colours to the list.
i definetly agree that the default colours should be a lot more lively,

[dhoeben]

I totally agree, I just gave up after 4/80 lights of wanting to do exactly this!

[Hypfer]

@dhoeben "exactly this" being those five specific color temperatures or which part do you mean?

[dhoeben]

@dhoeben "exactly this" being those five specific color temperatures or which part do you mean?

That the defaults are off and that this is the fix that makes it easy for me. In stead of editing all 85 of my lights

[Hypfer]

@dhoeben I'm just asking for specifics to make the job of the UX team easier. After all, it's less about this specific solution and more about what the specific user pains are, what they'd want/expect, how big those are, etc.

Conceivably, what I've proposed here might actually not solve this at the root. But to find that out we need the raw data and not the derived measures 🙂
In fact, it does from time to time happen that the solution to a UX issue is no code change at all and instead just a docs update. I don't think that that could happen here, but it's worth keeping in mind

[laupalombi]

Agreed! Even though the issue is discoverability, I like the current order you propose:

• temp gradient in row 1
• basic colors in row 2

It actually makes it easier to identify they are defaults.

I have one more suggestion - ditch the green in the last row (realistically its the least common of the group) and add the "+" button to add another one. This will improve discoverability.

Then we just need a way to let people know that the favorite colors are editable.

[Hypfer]

Hmm. Would a + in a hypothetical third row also work, or would that be too much?
Which then would jump to the edit mode and then people also notice that they can delete default presets.

I would personally prefer to by default have all colors available

[laupalombi]

well, that would be a different design solution, a third row is too much and we might need to see how it works out... why would you rather have all those colors as default? I would have assumed 7 defaults is already okay-ish

[Hypfer]

Hmm but that third row is how it is right now? It only appears in that edit mode, but then that's how that works.
It might also help with making it less bottom-heavy, but I need to try that I suppose.

Even though the issue is discoverability

Yes and no. It definitely is! But it is not just discoverability but also the sensible defaults like I wrote.
Ideally, as a user, I don't even have to manually customize too much, because the defaults already give me what I want.

"What I want", as described right at the top would be "sensible color temperature defaults" + "color presets that utilize the full spectrum of my RGB light". Dropping green would no longer achieve the second thing.

But I do of course see your worries there regarding not wanting to overload the whole view.

[dhoeben]

"What I want", as described right at the top would be "sensible color temperature defaults" + "color presets that utilize the full spectrum of my RGB light". Dropping green would no longer achieve the second thing.

I agree on this, for what it's worth. If we look at the climate entity, that more info popup is very bottom heavy as well for airconditioning units which can heat as well.