From time to time I have feeling that devs forgot about how it is to be a newcomer. I can bet most of beginners to home automation start with automating lights. since there are many ways how to integrate light, those might be represented by many domains. But now some of them can’t light up the icon while other do.
Then add to that groups which don’t light up with no clear reason and you can imagine confusion of the beginner.
If the main reason behind the decision was aesthetics, why it’s not done other way: defaulting to true, allowing to disable if someone really wants it. Right now to give UI a consistent look default lovelace is not enough. it requires a lot of hacks, 3d party cards… Shouldn’t lovelace provide consistency by default?
Reasoning comes from a request, to make icons to become yellow for all types when an entity is active, and not for just a few entity types. However, this would get out of control very quickly, as shown in the screenshot below.
I think your reply was a typical english joke (and please don’t take it as an offence, it’s just a fact that Englishmen have a very special type of humour)
I’m not a dev and I can feel your pain.
But on the other hand they’re still in the process of creating/decision making, it’s not 1.0 if you understand what exactly that means. Try to read this, it’s very complicated under the surface.
well… perhaps not always until we reach more stable state as it’s still rapidly evolving as far as I can see.
I’m Australian not English (no offence taken) but I understand what they are saying. I think it’s a reasonable approach. I’m glad I can FINALLY colour my input_booleans at long last. Anyway I think it’s good going forward. It’s just people get used to a certain way and don’t like change. A lot of this wasn’t thought out all that well originally and now they are working to a plan which does upset people who don’t want or like change.
I didn’t mean a country, it’s more down to language/culture and different ways of conveying information, for example.
You most likely understand what they are saying in this particular case because you took part in that discussion. I’m glad that @SeanM posted the link here because now I understand the reason behind this change and can react to it more consciously, it’s not like “they killed Kenny, bastards!” anymore
It’s not exactly “people get used to a certain way and don’t like change” (they mostly upset because they suddenly have a big task of fixing a working setup) but I know what you mean. Well, that’s the result of some decisions in the past that had accumulated into a series of issues and have been resolved by this change, yeah.
I can imagine the complexity (not most complex thing over the world though). I’m a sw developer/architect for 25 years. I appreciate devs work (regardless it’s paid or for free). But I don’t buy the “beta” argument. How long it’s stucked in this phase? Is there a roadmap available? What is the final plan for entities behavior (considering we are experiencing a transition). It’s incrementally ongoing development for sure. But version number itself is meaningless.
well, the problem is they plans must take into account users’ feedback. I very well know what happens when people start doing something “for the best for others” and don’t get in touch with reality and are carried away by their fabulous ideas… to nowhere.
There is even an english proverb about good intentions but I’m not that proficient
My point here is that it doesn’t seem like a good mechanism of getting such a feedback does exist for HA (or maybe I’m not aware of it). FRs have no dev’s attention. PRs/issues being put down just because one person says no (and there were situations when it happened just because that person didn’t take time to read a proposal properly) or there is just no response to it at all (sounds very encouraging to anyone willing to contribute, and don’t forget - we are talking about the project that declares itself being hugely based on volunteers’ help).
So it’s very unclear how devs set their goals and what influences their decisions. If it does not include user’s feedback… it can be fatal in the long run as essentially it’s not users for HA, it’s the other way round. If users say “screw it if it screws us” who would be bothered about state_color or whatever?
I personally am trying to take it realistically and hope the devs-users interaction in terms of goals and decisions will improve in the long term as it’s definitely not at its best right now. It’s just a fact and I hope it won’t offend anyone, that’s definitely not my goal. I like this project and wish it only the best… but if it stops being suitable for my needs, I’ll have to go elsewhere if I have no way to influence.
I meant how complicated sometimes is for them to make a decision
Perhaps it’s a result of
I have enjoyed being on the sidelines of this discussion, since my UI is setup with mostly glances, entity buttons, and some conditionals.
However, I am still not sold on the reasoning for only lights being colored by default. Was it like, “What class entities do you guys thing should be colored by default?”, and the decision is made, “Just lights. I think colors on switches, binaries, and booleans are a rare use case. So we’ll default those to false.”
Seriously? I mean, OK it makes sense for most sensors, and stuff like zwave entities etc, but it seems common sense to default color on things that return only on/off, 0/1. Call me lost in translation, but I’m failing to see the logic there honestly. Again, I don’t even have a dog in this fight… just a casual observer offering $0.02.
This is actually one of the main reasons it was changed, to make things easier for newcomers. It was very tough to explain the previous setup - certain things got coloring and other things did not, and there was no clear reasoning why things worked the way they did. There wasn’t a consistent ruleset that you could easily explain.
The old behavior was far from perfect, it’s just that we got used to the quirks over time.
Aesthetically, having potentially dozens or even hundreds of small yellow icons on a white background would look awful and be very hard to see. That has a contrast ratio of 1.39:1 which fails Web Content Accessibility Guidelines.
It might look perfectly fine on your particular setup and theme, but everyone’s setup is different. Some people have really minimal setups but others – especially newcomers who haven’t yet learned about conditional cards and seperate views – have densely packed interfaces. We have to take into account things like the default auto-generated user interface which places ALL entities in one single view.
The default auto-generated user interface is one of the reasons why there must be a sensible default, because the auto-generated layout cannot be customized at all unless the user takes control. They would have no way of opting-in or opting-out and need to have something that looks and works good by default. This default UI is something that most existing / advanced users take for granted because we’re so used to customizing our layouts.
I realize it’s an inconvenience to update your setup to how it was before. But the fact that you can still do that means it’s not the end of the world. More domains have coloring now, and the user has more control than ever before - you can enable or disable coloring on a per-card basis, or even a per-entity basis. The current system is super flexible.
This very much incorporated user feedback, there were tons of requests to get coloring on input booleans and other domains/cards. Here’s one from Sept 2018 and another from Jan 2019 just to give two examples. It was put on the backburner for a long time because it’s a very difficult thing to figure out - there’s dozens of domains and two dozen Lovelace cards with very different styles and needs. It’s challenging to figure out something that works best for all of these.
Majority of the discussion about this change happened in public places - the GitHub link I shared earlier, the Discord chat, there was a public beta where everyone had a chance to provide feedback.
It’s impossible to please everyone, but I hope this post at least explains some of the reasoning as to why these choices were made.
I understand the driving reasons behind the state_color change, however not all cards offer this ability.
I use a large number of entity-button cards conditionally to enable toggling on and off of certain items (switches, input_booleans, and alarm_control_panels). Different icons represent different states, and this is something my family are now used to.
With this change my buttons are now coloured in line with the stipulated domain states (e.g. alarm_control_panel icons are coloured yellow when disarmed), and I have no way of changing that AFAIK as I cannot use ‘state_color: false’ within the entity-button card.
I spent over an hour trying to adjust this yesterday after upgrading before giving up. I’m now having to consider how to completely redesign this section of my UI to take it back to the state it was before the upgrade.
Irrespective of the reasoning behind altering this behaviour, it would seem logical to consistently offer the same control capabilities of this feature throughout all aspects of the user interface. I would assume that consistent entity / card features in the UI would be more friendly to new users?
That’s a bit disputable. I believe a lot of HA users only use this forum (namely - Fearure Request section that doesn’t seem to be visited by the developers so often it looks like another chat room without any tangible result - but yes, I know it’s important as well) and sometimes don’t even know about all options Github provides (like Issues etc). Discord is also not for everyone and nobody apart form interested parties can see the discussion after it happened.
It is impossible.
However, it’s reasonable to keep in mind that only an active minority (in terms of quantity) of users make FRs or ask for changes using various channels. The majority is happy and doesn’t want any dramatic changes.
If you ask them to vote before rolling out something major (and many of them woudn’t vote as they don’t care) then you can carry on with the active minorities’ ideas (provided you received enough support) and in case of riots say ‘look, we asked you’. But without such a voting/consultation it’s catering for minorities only I’m afraid. Well, that’s my personal view on it.
And thanks for keeping us informed, that’s very important.
Hope based on discussions on this forum there will be more ways how developers gather users’ feedback and weigh they decisions before implementing changes.
Cut from within a vertical and horizontal stack, but this is the syntax for all the problem cards.
As an alarm_control_panel it is highlighted in yellow (I’m using the default theme) when disarmed.
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.
(and please don’t take it as an offence, it’s just a fact that Englishmen have a very special type of humour)
