Shall blue dot decorator be extended with other styles?

[andrewfg]

In #4069 the MainUI Thing overview list applies a "blue dot" decorator to the online status badge of any Thing that has a non null / non blank online status description text.

There has been some discussion here openhab/openhab-addons#20758 (comment) and here openhab/openhab-addons#20758 (comment) about this.

The original PR applies the "blue dot" in a binary manner .. if there is a non null / non blank online status description text then it is applied, and otherwise not. By contrast @lsiepel feels that the "blue dot" may be confusing, and he is suggesting that instead of having a single blue decorator mark, there should perhaps be several possible decorator styles .. perhaps as follows:

• DecoratorStyle.NONE - never apply a decorator even if there is an online status description text
• DecoratorStyle.INFORMATION - use existing (and therefore default) blue dot decorator
• DecoratorStyle.WARNING - use (say) an amber decorator
• DecoratorStyle.CRITICAL - use (say) a red decorator

So I am opening this issue to see if we can get some consensus among developers and maintainers on whether the decorator should be a) simply a blue dot dependent on the presence/absence of an online status description text, of b) something more sophisticated. (Note the latter would require some changes in OH core and OH webui, albeit these are relatively easy to do).

This discussion is related to openhab/openhab-core#5587 which discusses the circumstances under which an online status description text may/shall be applied.

[andrewfg]

Just for info, the code for one possible proposed solution is below:

• OH Core: patches for thing status related java classes
• OH WebUI: patch for things-list.vue

[mherwege]

I am not sure this is enough to put an extra burden on binding development. If it doesn’t get used in all bindings where it makes sense, It may confuse more then anything. The thing state is there to convey most of that, so I don’t see the point in doing a core extension just to support the visualization.
Would it make sense to use an information icon (i in a circle, I think also used in the semantic tag editor), to indicate there is extra state info, maybe with a tooltip already containing it? I kind of agree a. Lue dot is not very meaningful.

[andrewfg]

maybe with a tooltip already containing it

Yes that is already present in the current implementstion.

Would it make sense to use an information icon (i in a circle, I think also used in the semantic tag editor)

We could certainly do that. At the time my F7 skills were rather limited so the blue dot was the best I could do. But of course I can try again to put an i inside the dot :)

[mherwege]

We could certainly do that. At the time my F7 skills were rather limited so the blue dot was the best I could do. But of course I can try again to put an i inside the dot :)

Have a look here:

openhab-webui/bundles/org.openhab.ui/web/src/components/tags/treeview-item.vue

Line 51 in 5e0ed66

<f7-badge v-if="tag.description" class="semantic-tag-tooltip-badge" :tooltip="tooltip">

[lsiepel]

By contrast @lsiepel feels that the "blue dot" may be confusing, and he is suggesting that instead of having a single blue decorator mark, there should perhaps be several possible decorator styles .. perhaps as follows:

• DecoratorStyle.NONE - never apply a decorator even if there is an online status description text
• DecoratorStyle.INFORMATION - use existing (and therefore default) blue dot decorator
• DecoratorStyle.WARNING - use (say) an amber decorator
• DecoratorStyle.CRITICAL - use (say) a red decorator

Not entirely. In this comment, I tried to explain that I see three separate issues.

It was not my intent to suggest multiple indicators, at least not yet. I think we first need to discuss the underlying issues, preferably in order.

The blue dot with an “i” is already an improvement over just a blue dot, because it is:

a) more distinctive from other blue dots
b) better for accessibility

That said, I do want to point out that an “i” is usually understood as “information”, whereas an exclamation mark is usually interpreted as a warning. Which one is appropriate depends on the intent of the indicator and the data it is based on.

That is why I think there is an order in which we should look at these issues.

[mherwege]

That said, I do want to point out that an “i” is usually understood as “information”, whereas an exclamation mark is usually interpreted as a warning. Which one is appropriate depends on the intent of the indicator and the data it is based on.

That is why I think there is an order in which we should look at these issues.

I agree, but I also think we need to consider the context.

The prime element is the thing status. If the thing is online, the message can convey extra information, but it should be information, not warning. If you need something else, maybe we need an extra thing status level to differentiate Status.ONLINE, not just a message classification.
Secondly, I doubt anyone ever looks at the list of things to check messages when everything is working and ONLINE. So how relevant is it to go and create extra message classifiers for the UI?
Third, if we do this, it needs a sweep through the addons to make implement this in more places and make this relevant. If it is only there for a few addons, it again does not invite to check.

[andrewfg]

If the thing is online, the message can convey extra information, but it should be information, not warning.

I agree. (The thing can/will have extra state or trigger channels for warnings or alarms. What you see in the UI is info that may or may not prompt you to also look at those..)

Have a look here

I am working on some code. It is actually quite difficult to make it look good in the UI in bith dark and light modes and on different screens. But I will get back asap.

[andrewfg]

I will get back asap.

Here is my proposal that adds an f7 "info" icon to the dot. And attached is the revised code for things-list.zip -- whereby obviously minor details of pixel size and position can be tweaked as preferred.

[lsiepel]

I agree, but I also think we need to consider the context.

Isn't that the same as

Which one is appropriate depends on the intent of the indicator and the data it is based on

So it is a double agree :-) or do you mean somethign else with context ?

Again, i think we should pause the efforts here for a moment and first determine that the rules for the source (status description text) are clear.
JFTR adding a 4th parameter to the updateStatus is IMO also too much at this moment, while not ruling it out entirely.

[andrewfg]

JFTR adding a 4th parameter to the updateStatus is IMO also too much at this moment, while not ruling it out entirely

JFTR I did already write the code to do that. It was quite easy. However I will certainly not make an PR until the issue is resolved.