Open lolodomo opened 7 years ago
I think changing the icon is not a good idea. Just remember a UI which is showing only the icon and a very abbreviated string as a description (i.e. due to space restrictions). If you now have multiple devices in a NULL
or UNDEF
state you cannot distinguish these devices from each other anymore.
What I could imagine instead would be to show this new "red question mark icon" where we currently show the state of the item. This way it would be easier for a user to see which device might have a problem at the moment.
Your proposal would mean to change all UIs.And not a small change.
I know, but in my opinion it makes more sense than displaying for example a temperature sensor next to a switch with both the same "question mark" icon and UNDEF
value.
I don't know how to implement that but maybe we could have the question mark icon overriding the mormal icon with transparency?
Or just adding opacity on normal icon when the state is NULL or UNDEF ?
I found how to superimpose two images with CSS. So the idea would be to have one question mark over the normal icon. That requires a change in each UI but maybe not a big change.
If you are touching all UIs anyway I would strongly vote for replacing the value and not overlaying the icon to show that a certain item is NULL
or UNDEF
.
Remember that you don't have always a value but sometimes a control (slider for example).
So I vote for my easier and better solution ;)
As a conclusion, probably another thing that will remain as it is :(
Let me summarize what I understood from this and previous discussions so far
Which leaves the original intention of this issue: improve the state display in the icons in order to allow distinguishing OFF and UNDEF.
There were several options discussed so far:
I don't know about the others, but I at least think it would be helpful to have a (or several) visual mock(s) how it would look like. I would imagine a small question mark overlay in a corner of the existing icon (maybe similar to how eclipse is doing it?). As you said, it can be hard to make it look nice with all different kinds of icon sets. But if the icon set would provide the "undef marker" symbol by itself, there would at least be some kind of design consistency.
Could you quickly sketch something? Maybe it would also help to convince others of the idea (or shatter it completely)...?
I think we should consider the NULL case too. This can happen for example when a thing is OFFLINE and channels were not set. In this case it would help a lot to have an indication in UI that channel is not set.
I will try to propose something first for Classic UI and show with a snapsho how it looks like.
Just a quick mock with paint/photoshop/gimp/whatever would suffice completely - at least from my point of view there is no need to fiddle around with CSS at this stage.
Here is how it could look for UNDEF.
The icon is 16x16.
For unintialized items, I would prefer a X in red.
A new version with a little space around the ?
Another example:
Any feedback on my examples ?
Personally I think the principle could work. The design however does not look consistent. I didn't manage so far to find a better suggestion though. Maybe @reitermarkus has an idea?
The current architecture leaves it to the IconProvider (and thus to the iconset), how icons look like for different states. I would therefore rule out a "one fits all" solution as different iconsets might want to handle it differently (and I would claim that even for different categories you might want to handle it differently).
From the options of https://github.com/eclipse/smarthome/issues/3742#issuecomment-313616387, this would therefore mean a variation of option 2, i.e. a special icon for some categories for these states. The current design line of the Classic icon set chose greyed out versions of the icons for such cases, which I think is quite a good approach (and I do not see a reason why this should be changed).
So to make this consistent, we could simply rename a few icon files as currently "no state" is often the greyed out icon. So if we e.g. make "cistern.svg" to "cistern-undef.svg" and copy "cistern-50.svg" to "cistern.svg" (and similar for others), we should be able to nicely see whenever a state is UNDEF.
As it was recently discussed, using just color to differentiate icons is a bad idea for accessibility reason. This would be really a big work to change the full iconset. I could do it at least for the icons I am using.
What about uninitialized items (NULL state) ? This case is important to consider for things that are OFFLINE in particular. Would it be ok to update the icon provider to redirect to the UNDEF icon ?
In fact Kai's solution could be handled very easily without the need to add any icon. We should consider that the icon without state like contact.svg is the undefined icon. So we just have to change these icons to make them grayed. For example switch.svg should be changed to be different from switch-on.svg. the work is still big but no need to add new icons in the iconset.
No, that's not an option, my suggestion to copy/rename icons was on purpose. The "no state" icon should have colors as it is simply used as a category icon - e.g. for frames, text widgets without an item and whatever else.
You're right, I forgot this usage.
@kaikreuzer : by using grey, how will you differenciate for example 0 and UNDEF fir a dimmable light icon ? Another example is door or window, how do you imagine the UNDEF icon for these icons ? The only case that looks clear for me when I consider your solution is the switch icon ;)
Simple: Everything that is black in the case of "0" should be grey for "UNDEF". As a rule of thumb: UNDEF has a decreased constrast and no colors.
To follow a discussion started in #2962 , I would like to propose adding an "undefined" icon category in the iconset and then use this icon each time the item state is NULL or UNDEF, in replacement of the requested icon category. Before going further, is the principle ok for the maintainers ?
The first option is to implement that in the icon proxy. I already tried this option and I face off one problem with all UIs providing a state in the request in all cases even for a sitemap element not linked to any item or for a group item without function. It leads to the undefined icon in these cases when not expected. It means all UIs should be updated to avoid providing a state in these 2 cases.
The second option is to implement that in each UI. The change to do in each UI can be a little bigger than the previous option.
In all cases, as a change is required in each UI, I will prefer the second option to avoid impacting unchanged UIs.
For the icon itself, I propose just a red question mark.
What do you think about that ?