💄 additional active icon states #4510
Conversation
There was a problem hiding this comment.
My comment from linked PR - #3897 (comment):
Each time this comes up, I say the same thing: don't suggest that we need to color this or that, instead, come up with a strategy that we can use for each place (entity row, entity button etc) on how we should color each type of entity/device class and each of their states.
|
Looks like there is two competing strategies here. The first being highlight when active (e.g. "locked") the other being highlight when requires attention (e.g. "unlocked"). Feels like that choice needs to be made first. Personal preference is the former as it can be explicitly coded. The difficulty with "requires attention" is that it varies with context e.g. an ulocked front door requires attention but so does a locked fire-exit door. |
|
@balloob I believe I did, my strategy is highlighting items requiring potential attention. Or are you saying I should explicitly state for each and every entity/state combination? I think that's overkill and this can evolve overtime. I don't think there should be a difference between state badge and entity button. |
|
I think that if something requires attention, like a plant in "problem" state, we should color it red or even add a red badge to the icon with an |
|
So I'm glad that we're talking about this issue btw, and let's find a solution 👍 and sorry for not reading the description thoroughly when leaving my review. So I don't know if "potentially requires attention" is a good strategy. Is a person being home requiring attention ? Wouldn't either "active" or "open" be a better strategy? |
|
Will it be possible (with this PR) to allow little more user control? For example, we may not know what requires attention. Also, attention may not be a simple binary state, i.e., there are different levels of attention. Something to think about (if not for this PR, maybe for the future). |
|
What is the driver of this change? Right now glance and picture elements use the same component as the entities row card. Glance and picture elements could benefit of such changes, entity row not (it would become too busy). @arsaboo that is out of scope of this pr |
|
@balloob person was admittedly something I struggled to fit within this reasoning. Let me take sometime to better describe each case and we'll go from there. I really want to get something resolved on this as well 😉 |
|
Also, |
|
The problem is that if everything wants to grab attention, nothing will. |
|
So my idea is that we should only highlight/change an icon color when it warrants attention which can be a very tricky thing to balance as @balloob noted. My initial changes were the ones I saw most value from, but if I'm doing this, I might as well do it right and consider ALL domains, so I'll try my best to explain each domain below (sourced from domain_icon.ts, so may not be complete) and hopefully we can finish with something that makes a lot of people happy:
|
|
I guess I am not convinced that "needing attention" is a good strategy. I still prefer using energy. Not all domains will have states. Some are only because they are shown in the logbook. Like Alexa/Google. Scenes don't change state and can't be colored. Same with zones. Climate. This one if anything should be linked to the action, not the mode ? And if it's set to mode, all modes should be colored except if it's off. Should follow same coloring as the thermostat card. Consistency is important. We can't have two colors to indicate that a device is heating. I don't believe that a person or device tracker being home should be colored. |
|
I agree that using energy is a good piece of criteria, but is also too narrow for all of home automation in my opinion. Climate: I would be on board with aligning with thermo card for hvac_action |
|
I lean towards preferring the "requires attention" idea and think ian's list above is mostly good. Perhaps another way of thinking about this: if you're about to go to sleep/leave home/go on vacation and take a quick look at Home Assistant before doing so, what information is most important to know at a glance? Whether there's any doors left opened or unlocked, whether your alarm is armed, if you forgot to turn off some device, etc. I don't think device tracker / person should be colored as that one feels too subjective. You could argue that "home" state is more significant as automations depend on that, but many parents would probably think their child being "away" requires more attention. |
|
I think that if we want to build an interface that is glance worthy in case you're going to sleep/leave home etc, we should probably not conflate that with our control UI? (we have already discussed a couple of times to get sentence summaries of rooms/everything and is still on some list) |
|
Mockup:
I think that too much yellow will render it useless. Maybe not color any non-controllable entities ? |
|
I agree that if most icons become yellow it would kinda defeat the point and just tip things too far in the opposite direction. But at the same time, the current icon coloring strategy feels somewhat arbitrary? For example: These all have the same exact "on" state, they're all in the same card, they all have toggles, yet some get coloring and others don't. They all look the same, yet behave differently. Isn't this kinda confusing for new users? I don't know how to easily explain this beyond "that's just the way things are." One idea I had before was to drop coloring on entity rows altogether. The reasoning being that in most cases there's a colorful blue toggle to quickly determine state, and coloring the icon feels like duplicated functionality. iOS and Android don't color icons when there's a toggle switch. Plus for non-controllable entities, the state is always shown right next to it as text. But I suspect this would be kinda controversial so I was too afraid to ever suggest it publicly 😄 IMO though, this has always been less about the Entities card and more about other cards like Glance and Button. The glance card can be configured with Everything is "on" here just like above, yet if you showed anyone this picture, they would say that two things are on and three are off. This is even more of an issue on the button card because that doesn't even have a |
|
The glance and button cards really do highlight the need. I agree with entity rows, to an extent. I don't think we should remove it, but perhaps have an option for the card FWIW, the remote is a bit useless; you can't even turn a remote off to my knowledge |
|
We should at the very least align the different domains with coloring, that binary sensors do color and other domains don't doesn't make sense. We should make sure that a lock/cover binary sensor is the same as the lock and cover domain. I do agree with Sean that it is mostly the glance/picture elements/button cards that need this, the entities row is not really needed, but I think it is weird to not do it in the entity row for consistency? As you would still want to do it for light to show what color it is? I gave it some thought and requiring attention might be a slippery slope for a ruleset. It might be different from entity to entity and user to user. Anything that has a clear on/off state could be colored like a switch and binary sensor already are. But I don't think much of Ian's table will change if we would base it on on/off. For domains that do not have a clear on/off like climate, for example, we might be able to use other colors to indicate the state. For climate, we use color in the thermostat card to indicate the state, so we could expand those to the rest of the cards. Eventually, I think we will get settings for this, also for sensor values to be in specific ranges to give it a specific color, etc. But we should have a sane default that works for 90% of the users and use cases. |
|
I don't think we should touch sensor 😄 type: glance
entities:
- entity: sensor.download_speed
icon_color: red
states:
- value: 10
operator: '>'
icon_color: yellow
- value: 20
operator: '>'
icon_color: greenHow we accomplish that is another discussion though 😛 @balloob and I had previously discussed a state-merge-config card that would allow you to merge a configuration based on the current state of an entity. I think it would be an AWESOME card, but wrapper cards can be quite advanced and there's little chance of a nice UI editor for something like that. Anyways, that leads back to a user being able to define the icon color via the configuration which already I've had push back on. I think ideally each card just have a state merge function that allowed for such changes, but again, I'm side-tracking myself 😄 |
|
Yeah I said eventually, like not in this PR ;-) |
|
Alright, what about:
|
First of all let me thank you for discussing this, as a fervent customizer of state colors, I truly welcome the extra options for Lovelace this would offer. So do continue! Please allow my 2cts on this: I feel using/adding Moreover, might I suggest 1 extra option expanding on that:
Doing so would keep the global coloring schemes based on theme, And enable incidental coloring per card individually, using outside-theme coloring, which would be a main driver for using the Please also remember users might want to change the off color also, not only the on color... |
|
I think balloob's proposal sounds good.
I suspect some will gripe about the entity row changes in the short term simply because they've been used to things working a certain way. Though I think most people will get over it quickly and realize coloring isn't necessary there. But might want to make a compromise and still always color lights though in entity rows? Not sure. |
|
@Mariusthvdb color customizations can happen with a theme-per-row setting. But let's keep that out of this PR. |
iantrich
changed the title
iantrich
changed the title
extract common css properly set boolean attributes separate error states/color fix unavailable color
|
I think that it looks fine from my end. @bramkragten and @SeanPM5, any opinions on coloring? |
|
Coloring choices look good to me 👍 |
|
FYI, colored lights still change in the entities card |
|
Makes sense colored bulbs are still colored. Should we make non-colored lights turn yellow? 😛 |
the switch should suffice and a user can override if they wish with |
I think highlighting devices that require potential attention is the main goal and after some thought propose the following changes:
Domain - Active State
Existing
Additional
fixes #3897