frontend icon indicating copy to clipboard operation
frontend copied to clipboard

Color of off state appears as unavailable (#14619 not fixed)

Open RobSmyth opened this issue 2 years ago • 12 comments

Checklist

  • [X] I have updated to the latest available Home Assistant version.
  • [X] I have cleared the cache of my browser.
  • [X] I have tried a different browser to see if it is related to my browser.

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.

    This issue has been resolved in latest release. If you have still experience it, please open a new issue.

Originally posted by @balloob in https://github.com/home-assistant/frontend/issues/14619#issuecomment-1353169854

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.

image

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.

RobSmyth avatar Dec 16 '22 05:12 RobSmyth

Recently color in History for unavailable changed to "transparent". It happened in 2022.12.4. I first found it mentioned here: https://github.com/home-assistant/frontend/issues/14619#issuecomment-1345385634 Then a PR was created for "transparent": https://github.com/home-assistant/frontend/pull/14710

I confirm that currently in 2022.12.5 the unavailable is "transparent": image

Since I am sure that "transparent" is a BAD choice for unavailable, I created this issue: History-graph: do not make a graph for "unavailable" sensor transparent

ildar170975 avatar Dec 16 '22 05:12 ildar170975

@ildar170975 - do you remember what the actually false color was in 2022.11? I'm wondering if I'm getting confused here.

RobSmyth avatar Dec 16 '22 05:12 RobSmyth

Here is for 2022.7.4: image

The best solution would be:

  1. Use a separate theme variable for on, off, alerted (stands for "on" or "off" for some device classes), unavailable, unknown - then users will be able to define colors as they like.

  2. Ideally - provide nice default values for these variables - so most users will not have to create custom themes.

ildar170975 avatar Dec 16 '22 05:12 ildar170975

Here is for 2022.7.4: image

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.

RobSmyth avatar Dec 16 '22 05:12 RobSmyth

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:

  • True
  • False
  • Unavailable
  • Unknown

Comply with common conventions to help the states to be self-evident (UX):

  • Gray, especially light gray, is a common convention for unavailable or disabled UI elements.
  • Red is often used as an alarm state - depending on application, sensor, logic, wiring, both true and false could be an alarm states. So red is ambiguous.

RobSmyth avatar Dec 16 '22 06:12 RobSmyth

@franco-101 - I see you last comment on #14619. Raised this issue as that one is closed as resolved.

RobSmyth avatar Dec 16 '22 06:12 RobSmyth

hm... why not use the default color of an inactive icon for the off-state? That would at least correspond with the icon color ...

The Icon Color becoms light grey when the entity is unavailable or unknown: grafik

This should be the same color in the History ... ok, we can discuss about the differenciation between unknown / unavailable.

the OFF-State could be just the default icon color: grafik

when the state changes - and the icon active color changes, the same color will be applied in the history as it is right now: grafik grafik

ChristophCaina avatar Dec 16 '22 08:12 ChristophCaina

@ChristophCaina wrote:

hm... why not use the default color of an inactive icon for the off-state? That would at least correspond with the icon color ...

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.

RobSmyth avatar Dec 16 '22 09:12 RobSmyth

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. Grey - should be, as you correctly pointed out - be used for Unknown / Unavailable... while we could discuss (and that's already in some topics here) - different shades of gray for Unknown / Unavailable.

But yes, I agree - grey should not being used for OFF... that's what I wanted to say :D

ChristophCaina avatar Dec 16 '22 10:12 ChristophCaina

Bring back the History state colours from version 2022.11! Red for False/ Off / Closed Green for True/ On / Open Grey for Unavailable

quantum-fc101 avatar Dec 16 '22 11:12 quantum-fc101

@franco-101 said:

Bring back the History state colours from version 2022.11!

Yes ... get it back to usable and then treat any color changes as a new feature (not a fix to this issue).

RobSmyth avatar Dec 17 '22 01:12 RobSmyth

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. Grey - should be, as you correctly pointed out - be used for Unknown / Unavailable...

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. :-)

RobSmyth avatar Dec 17 '22 01:12 RobSmyth

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. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Mar 17 '23 01:03 github-actions[bot]