At first thank you for the contribution to this thread.
I need however comment on what you wrote. Quoted fragment seems to be inconsistent to me. But it might be due to my different point of view.
You mentioned 2 facts:
Content Accessibility Guidelines
newcomers (I’m one of them)
Since newcomers start mostly from implementing lights, how can you achieve CAG if they get GUI full of yellow bulbs as they would have had without HA change? And in addition the same beginners will get confused with switches, which drive lights but not change the color.
You also mention that the new HA version adds other domains to behave like bulbs icon-wise. It means even more yellow color.
I know it already happened and will likely be not turned back. But if I go this way, I would provide some global switch (on root level) to maintain old behavior.
As I mentioned I’m beginner. I’m using default light theme. And I didn’t found yellow icons on default bright background cumbersome (working on different monitors and iPhone). Hope trying to be compliant with CAG at any cost wouldn’t the main goal of the change.
well, I found it hard to see what icon it is when highlighted, maybe that’s what he meant?
the issue I see now is if there is no highlighting, some of my icons should reflect entity’s state but sometimes there are no crossed icons OR I don’t know how to change icon according to state (or maybe I just cannot justify creating a template wrapper just to get that changing icon).
But is it important? To the extent that it’s better to remove the coloring at all from icons of some domain (while adding it to other domains)?
Was changing active color under consideration? Maybe adding ability to change it on global level would help? Maybe making the yellow a bit darker? Maybe adding thing border or shadow…
IMO removing the functionality of providing visual cue was the worst choice considering HA UI’s main task is to signal states.
I have no answers and suspect they depend on who you ask.
All I know there was a long discussion that included a limited number of HA developers and contributors and there was no public survey carried out before implementing the change to find out what’s important to the community.
Here we are.
That was an intentional decision because Button card does not display the state as text. The icon coloring is therefore necessary to determine the current state. You’re correct though that button card currently doesn’t support state_color: false . That’s good feedback and would be a perfectly reasonable feature request to make.
Alternatively there’s also the Custom Button Card which is fantastic and allows full customization of everything. That will always have more features than the default core cards which are meant to be more simple and straightforward.
Well I’m not sure what else to say, the GitHub and Discord are where all development-related things occur, and so naturally that is where one should expect the pre-release discussion to take place as well. These are public and super easy to access, just click the “Need Help?” link at the very top of the main website and forum or the Developer Tools > Info page in Home Assistant itself.
It’s far better and more organized to have all the discussion occur in one central location where you can be 100% sure the developers are reading the feedback, and so that information doesn’t have to be unnecessarily repeated in multiple different places. That would just slow down development.
The GitHub PR’s are linked to from the release notes, so it’s helpful for users to click on them to learn more about why a change was made (again, here is the PR for this specific change). If the discussion about a change was fragmented across various forum posts or social media networks the links in these release notes would be far less useful.
If you want switches that drive lights to also behave like lights, you can use the Light Switch platform. This way you can also add them to light groups and they’ll show up in Google/HomeKit etc as lights.
Yes, and giving all those other domains coloring is precisely why it was made opt-in. To avoid all that yellow unless the user specifically wants it. It’s set to state_color: false by default for the Entities card.
Accessibility was not the main goal of the change, but just one of several reasons why it makes sense. You can visit this contrast ratio checker website to see the results of yellow on white (a huge fail).
Ultimately it’s simply not necessary in the Entities card, because the state is always displayed either as text (for binary_sensor) or as a colorful toggle switch for most other domains (switch, fan, input_boolean, automation, etc etc).
Here is an example of the Home Assistant default theme (left) and some various community themes, both light and dark. You can easily determine the on and off states just by glancing at these toggles, without even seeing the rest of the entity.
Notice how the icons don’t change here on iOS or Android? Because the toggle makes it perfectly clear already. Coloring the icon on top of this is unnecessary duplicated functionality. It’s still easily possible to add back if you want, but it’s certainly not essential.
No functionality was removed though, in fact more was added. The only thing that changed here is the default setting.
I believe the issue here is that the implementation of this change was, first, a complete surprise to the vast majority of users because there aren’t that many people who have the time to try to keep up with this forum and updates to HA and then to also visit the other various and sundry places that these development discussions happen. I know I don’t have that kind of time. HA already takes up way too much of my time already.
It’s kind of funny that you say that the developers need to have a place that they can discuss all of these changes without having to be spread all over social media. So what did they do? Instead of using this forum they created a separate discord channel for HA, a reddit channel (or whatever it’s called), the github issues section and a feature request section here.
The “need help?” link goes to a page that has no less than 10 places that users might need to go to get help. That doesn’t sound very consolidated to me.
I would bet good money that if the developers used this forum and made more forum posts about “hey, this is coming down the pipe. What do you (the experienced current users) think?” you would get a lot more positive feedback. And when those changes got implemented you would likely have a lot less push back from those very same experienced users because those decisions would have been aired in the place where the vast majority of users actually spend most of our social media HA time.
Second, the stated goal was to improve understandability to newcomers by making everything consistent. Then turning immediately around and making things inconsistent by making the “light” domain the only domain to get a colored icon by default.
third, the recommended “salve” to sooth the irritation of having to go through your entire config and opting back in to a functionality that had previously existed is to claim that “you can make the changes on a card level basis”. Then when people in this thread tell you that doesn’t work for all cards is to basically ignore that statement and keep repeating the same thing isn’t at all helpful.
So, can we do the card level option on, at least, all of the core cards? If not then the change was rushed out before it was fully implemented. Which causes more frustration from existing users.
Last, to offer the suggestion to change all of your light switches to the “Light Switch” integration isn’t much of a solution either. You still have to go thru your entire config and re-create all of the existing switches into “light switches” and then you end up with two entities that represent the state of one device.
For me I had already customized my switches that control lights to have the light bulb icon to indicate they were light switches. Now, unless I go to each entity and either convert them all to “light switch” or turn on the state_color option in each card for each entity I will have some “bulbs” that show the state color when switched on (because they are in the light domain) and other “bulbs” that don’t show the state color when turned on (because they are in the switch domain). Nope, that’s not confusing at all.
especially if they spent plenty of time making their UI useable and consistent and now it looks weird again because someone did something ‘logical’ from their point of view (as it was decision of 3-5 people as far as I understand). so we’re all reaping the results.
Well… as previously said the very same changes could be done better, much better using different approach.
I see quite a few people asking for things to be cross-posted here in the forums for more feedback/visibility and frankly, I just don’t see that being viable. Lots of PRs are from one-off contributors. We’re already hurting for contributors as it is and to make them post over here as well before we merge something is an obstacle that most won’t want to go through.
I’m a fairly regular contributor, but even that is a big ask for me. I do this in my free time; I’ve got 3 kids, a wife and trying to work on my own HA setup. And like I said before, all our PRs are open to the public, our Discord channel as well.
That all being said, I can feel your pain. I too had to go through my large configuration and added state_color to my cards as that is my preference for entities card. If you have a large config that you need to update, my best suggestion right now would be to copy your config to an IDE like Visual Studio Code (release 1.38 or higher), and do a find replace on
type: entities
and replace with
type: entities
state_color: true
Watch for indentation issues.
I really hope you don’t truly think contributors, myself and core devs included, are out to hurt you. I honestly thought this would be a great improvement to the UI and still do. Like I said, I too use this on a daily basis.
Lastly, I do plan to add the state_color option to button and glance cards as well as the state-icon element for those of you that want to turn off such indications. Feel free to provide feedback on the PRs when I submit them. You can subscribe to the frontend repo to get notifications if you wish. I’d recommend turning off email notifications though and just check them periodically if you want to keep your inbox at a sane level
Thanks Ian for your hard work and for the answer.
I think many of us understand you very well.
However, as it was your PR and after its merge there were many omissions showing that the merge was a bit rushed and it could benefit from a brief consultation with the community I just want to ask to think about the situation calmly and maybe try gathering more feedback before implementing such dramatic changes next time.
Of course, ideally it should apply to all of us.
And I’m not teaching, just voicing my opinion as a member of the community and a user of this great system.
Thanks again!
Thank you for such a detailed response. And thank you for continuing to work and improve HA! I think this change makes HA much better, people are just complaining that they want more control over it.
Any plans to add an option so you can globally set this variable or even change color in a config? Similar to how custom UI does it? There was a feature request about this, but I didn’t think it was actively being worked on.
No, I don’t think so. At the very least it is not something I will not work on as it is really just a stop-gap to avoid adding this to your cards. Which I can understand can be tedious for updating an existing large config, but should really not be a big issue going forward, in my opinion.
It was in the beta for a week and no complaints were raised during that time. A PR open for a week and a week in beta is, in my opinion, far from being rushed I also can’t keep my ear to all the feedback on the forums. There is a LOT going on here I focus mostly on what is happening on GitHub.
Gotcha, so no plans for color state options? It would make it sooo easy to set up how state colors behaves for different entities. For example, using Custom UI (which is buggy as hell but somehow still works) my global config looks like this:
Not by me I’m just one dev though and a selfish one who usually makes thing that I want
I could see an icon_color option being added to cards, but I doubt it would be done the custom UI way, i.e. globally. But if icon_color becomes a thing, a custom solution to set those by templates becomes much easier.
Ian, (I presume) that’s because most of the beta users are the very same people who propose changes or make PRs. I personally only update when .2 comes out as I cannot afford disrupting my setup. (I also open issues and sometimes make PRs, but not as great as yours )
And still, I think now you have at least 2 FRs on your hands related to the lack of functionality in various types of cards making them difficult to use after the change. We can call it whatever we want but it could have been less stressful, and it’s not only about time - more importantly, it’s taking into account users’ opinion.
If you meant that 2 weeks was enough for everyone to get familiar with that PR… I don’t know who reads all these PRs before they become part of HA. I got a link to it from the release blog when we discusses “why could it happen at all?”
but did you try to gather it? like a poll or something? if no, then yes, you can’t
I believe you and that’s great, really!
However,
it’s ok but do you really think that your discussion with @SeanM and @balloob could for sure take into account needs and use cases of say, 50% of HA users registered on this forum alone (50% of roughly 50k If I remember it right). Or 10%?
I’m happy either way as I can see HA progressing. But its progress ultimately relies upon its user base, which in turn is directly influenced by relationship between users and developers, by the way developers respond to their needs and issues - just because users are here if the product satisfies their needs.
Beta users will stay for sure as that’s their hobby, what about the majority? Everyone (both developers and users) should understand that.
I can understand frustrations on all of that, but at the end of the day, I’m just a guy who likes poking around in a project in his free time. I don’t really want to be more than that.
I mean, we try not to break things, we try to make informed choices, we try to make things better. But asking me or anyone really to talk to 50k users, to do case studies and user polls and filter through all that to make a change to icon coloring…that’s not something I’m going to do. But I’m not a core dev, I’m just a guy, trying to have some fun and make cool things
I also can’t keep my ear to all the feedback on the forums. There is a LOT going on here 
I focus mostly on what is happening on GitHub.
)