-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Color of off state appears as unavailable (#14619 not fixed) #14805
Comments
Recently color in History for I confirm that currently in 2022.12.5 the Since I am sure that "transparent" is a BAD choice for |
@ildar170975 - do you remember what the actually false color was in 2022.11? I'm wondering if I'm getting confused here. |
The best solution would be:
|
Thank you ... I never liked those color choices but it is does not make me look my UI can wonder why all my sensors are unavailable. :-) Also ... your prior image highlights the need to understand more than just the issue title. False appears as a lighter gray when in dark mode. Just plain wrong. :-( As for solution ... sure user definable would be a nice feature but regardless the default values need to be both usable (my issue here) and look nice. |
Thinking more about root causes, rather than behavior/color seen ... perhaps the underlying issue here is: The UI's rendering of boolean states in history graphs need to be unambiguous, self evident, & look good. The states that must be clearly differentiated are:
Comply with common conventions to help the states to be self-evident (UX):
|
@franco-101 - I see you last comment on #14619. Raised this issue as that one is closed as resolved. |
@ChristophCaina wrote: hm... why not use the default color of an inactive icon for the off-state? Thanks Chris, if your examples show that color then I think I think have not explained myself clearly. I put that it is common practice to use light-medium gray for disabled/unavailable/etc. Many users will, as I do, confuse the light-medium gray in your images with disabled/unavailable. Some colors have general meaning in some contexts. This is not about what I like but how I, and I believe others, will interpret what they see (UX). I would rather not get into a discussion about one color or the other as I suspect it is more complicated than that. For example, if the off/false state is tied to the icon default color then the on/active/true, unavailable, and unknown states should also match icon active state. Does this work in both light and dark modes? etc. Using your images as an example, will the icons go green when the state is "Open" on your UI (I do not know). Making quick choices may well spawn further issues and break other things as I think has already happened. While I have identified one regression here I recommend: Reverting to prior implementation and then allowing the team to consider what is required, design, and UX across all needs. I doubt a robust implementation will be achieved without coming from requirements and style guide review. Note: I really dislike the prior colors but at least they were less misleading, more usable. |
sorry, maybe I mis-explained what I wanted to say :) an "OFF" state should have the same color as the OFF icon does have - in this case, the dark-greyish-blue. But yes, I agree - grey should not being used for OFF... that's what I wanted to say :D |
Bring back the History state colours from version 2022.11! |
@franco-101 said:
Yes ... get it back to usable and then treat any color changes as a new feature (not a fix to this issue). |
Yea, thx. For me, "dark-greyish-blue" is another gray and I suspect linking to that icon off colour may appear as another gray in dark mode. Hence I'm pushing back on any knee jerk reaction to just pick a colour. I think it is more complicated than that. :-) |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
Checklist
Describe the issue you are experiencing
I reporting this as the #14619 has been locked and marked as resolved when I believe it has not been resolved. I took yesterday's release and still see grays that are by common convention "unavailable" as shown below. That is ... it looks unavailable and this change diminishes UX.
Originally posted by @balloob in #14619 (comment)
While the title of #14619 reports the issue as colors being the same (true), it is also that the color chosen for false has now changed to match what by convention is, also, unavailable. So it just looks unavailable.
Describe the behavior you expected
Please revert back to 2022.11 colors
Steps to reproduce the issue
Widely discussed and reproduced in issue #14619.
What version of Home Assistant Core has the issue?
2022.12.6
What was the last working version of Home Assistant Core?
2022.11
In which browser are you experiencing the issue with?
Firefox 108.0
Which operating system are you using to run this browser?
Windows 11
State of relevant entities
No response
Problem-relevant frontend configuration
No response
Javascript errors shown in your browser console/inspector
No response
Additional information
Post that fix please then make changes after developing UX guidelines and seeking.
Front end version: 20221213.0 - sown as latest on my UI.
The text was updated successfully, but these errors were encountered: