[Basic UI] Improve layout of header and buttons

[kaikreuzer]

This refers to #2010 and the discussion at the forum:

After seeing the new feature on my production env, I feel that it could possibly be improved. What was a neat, slim list of charts before has now become bloated and imho unpleasantly arranged:

Things that might be improved:

• Showing a text/icon although none has been specified feels like a regression and it should imho be avoided. Setting label="" and icon="none does not feel right, it is counter-intuitive (we usually define what we want and not what we do not want) and looks rather like a workaround.
• The new header wastes a lot of space, especially, if no label+icon is desired. One idea would be to show the buttons as an overlay when hovering over a chart. Imho this would be quite elegant, although I understand that it might not be simple to implement.

Looking forward to your thoughts on this, @lolodomo.

[lolodomo]

• Showing a text/icon although none has been specified feels like a regression and it should imho be avoided. Setting label="" and icon="none does not feel right, it is counter-intuitive (we usually define what we want and not what we do not want) and looks rather like a workaround.

No, this is exactly the general principle of any sitemap element. If a label/icon is set on the sitemap element, we use it. If not set and if the sitemap element is linked to an item and if a label/icon is set for this item, we use the item label/icon for the sitemap element. And finally if still no label/icon set on the item, we use the item name as label and the icon associated to the sitemap element as icon (chart.svg in the current case).
So I don't think that would be a good idea to make something different (the inverse) specifically for the chart element.

• The new header wastes a lot of space, especially, if no label+icon is desired. One idea would be to show the buttons as an overlay when hovering over a chart. Imho this would be quite elegant, although I understand that it might not be simple to implement.

I have no idea how to implement that overlay stuff.

What I can propose for those of you who do not like this new header line for chart and image elements is to do something similar to what I have already done for the video/webview/mapview elements, that is the header line is hidden in case an empty label is set on the sitemap element. This change is trivial to implement, just few lines of code. Like that, everybody can restore the old behaviour if he prefers to not have the header line for charts. There will be only one exception when an image item is part of a group and you open the group, the default will be to display the header line for the image. As chart is never the default element of an item, you will never have chart elements when opening a group of items.

Another option will be to enhance the sitemap syntax for chart and image elements to let the user adding "withHeader" when he wants the header line. In that case, the default will be to show the header line. In that case, this new property should be also handled in Android and iOS app.
Or the opposite, that is the default is to show the header line but the user can add "withoutHeader" to hide it.
Edit: in case we add "withHeader" (or "withoutHeader") to the sitemap syntax, we could then add it also to webview, mapview and video elements.

WDYT ?

[kaikreuzer]

No, this is exactly the general principle of any sitemap element.

Yes, you're right. But then again, chart, image and webview widgets were never really meant to have a header.
Both Android and iOS apps do not show such a header (and they took the ClassicUI as a template).
I don't really see a reason to have it now in Basic UI by default, while the native apps do not have it. (And tbh, my main concern is the UX as images/charts used to be nicely embeddable into a page.)

What I like is the solution in the Android app: If a user is interested in the details of a specific chart/image, they can click on it, get it full screen and then have the buttons to toggle the legend or to select a different time range. Couldn't this be an option for the Basic UI as well?

[lolodomo]

At the origin, there were issues/requests declared by users asking icon and label for any sitemap element including chart.
Note this was also enhanced in the Android app but I have no precise idea how it renders as the change is not yet in the app store:
openhab/openhab-android#3441

So as usual we have a part of users requesting something and others who don't want it.

What is done in the Android app for chart (version in google store) is an option. IMHO having to click on the chart to open a new page to see the icon/label is a little strange and certainly not what was requested.
But we could imagine a combination of both ideas: in normal page we display the header line with only icon and label but a really smaller line. And when clicking on the chart/mage, a new page is opened with the bigger header line including buttons.
This may be more or less the current state in the Android app we have not yet tested.
@openhab/android-maintainers

[maniac103]

The Android app certainly works differently than BasicUI here:

• there is no 'button row'
• icon and label are both hidden if the label is empty
• the 'header' is smaller than for other widgets (icon is smaller and label font is smaller as well)

Having mentioned the last point, it rather should read 'should be smaller', because it currently isn't:

I think I'd prefer a layout which we previously used for Mapviews:

That way it becomes more obvious label and icon belong to the chart/image/... and are not just another widget without state.

As for 'some people want labels for their charts and some don't': maybe a compromise could be not auto-populating the label field for those widgets in the server, that is, only fill out the widget label if explicitly listed in the sitemap and do not fall back to the item label? That way, the default view would still look as before, while still providing the option to show label and icon if desired. For the apps, there's no way to differentiate 'user has set a label on the sitemap widget' and 'server filled out label from item label as widget label was not provided for sitemap widget' anway, as all we have to work with is the label field in the JSON response.

Another option will be to enhance the sitemap syntax for chart and image elements to let the user adding "withHeader" when he wants the header line. In that case, the default will be to show the header line. In that case, this new property should be also handled in Android and iOS app.
Or the opposite, that is the default is to show the header line but the user can add "withoutHeader" to hide it.
Edit: in case we add "withHeader" (or "withoutHeader") to the sitemap syntax, we could then add it also to webview, mapview and video elements.

TBH, this sounds a bit overengineered to me. So far, the sitemap syntax is mostly free of UI-specific toggles, and I think that's a good thing. The way I could envision this working in BasicUI is

• label empty? -> do overlay thing; if that's not possible, show a small 'settings' icon to the upper right of the chart, which then opens a menu with 4 checkbox items
• label not empty? -> show icon, label + your header bar (essentially an expansion of the proposed menu)

[maniac103]

And when clicking on the chart/mage, a new page is opened with the bigger header line including buttons.

In the case of BasicUI, wouldn't a popup/dialog kind of thing not be better than navigating to a new page?

[mueller-ma]

I think @maniac103's suggestion is the way to go:

• Don't auto-populate the label field.
• Inherit the icon from the item(s)
• Show the header only if label is not empty

This way there's no need for additional configuration and it's backwards compatible to existing Sitemaps.

[lolodomo]

• Don't auto-populate the label field.

We have to be clear for which sitemao elements we introduce this exception.
And I understand you expect a change in the core framework (REST sitemap API(.

• Inherit the icon from the item(s)

You mean if icon is not defined on the sitemap element?
I would rather say: no changes for icon.

• Show the header only if label is not empty

Ok

To summarize, the idea is that the user will have to set a label to its sitemap element to get the header line. That is a reasonable suggestion I believe.
@kaikreuzer : is it ok for you too?

[maniac103]

We have to be clear for which sitemao elements we introduce this exception.

Two options:

• Only for those which are normally not expected to have the label shown (chart, image, map, video, webview)
• All of them (and do the fallback in the client if desired)

The former is 100% backwards compatible (since it will hide the header where not present before, and where thus label wasn't used before), while the logic of the latter is more straightforward, but needs client changes (even though it's a simple one in the case of the Android app at least).

And I understand you expect a change in the core framework (REST sitemap API(.

Correct.

[lolodomo]

The documentation is very clear on how it currently works. Documentation should be updated in case we introduced exceptions:

[lolodomo]

Two options:

* Only for those which are normally not expected to have the label shown (chart, image, map, video, webview)

* All of them (and do the fallback in the client if desired)

The former is 100% backwards compatible (since it will hide the header where not present before, and where thus label wasn't used before), while the logic of the latter is more straightforward, but needs client changes (even though it's a simple one in the case of the Android app at least).

I agree the first option will in practice break nothing as the label for these elements were not displayed before.

I do not understand your second option. The inheritance of label/icon from item for other elements is very important and we clearly do not want to break that feature.

[lolodomo]

I do not understand your second option.

Or by "all of them", you mean chart, image, map, video, webview but not all sitemap elements ?

[maniac103]

Or by "all of them", you mean chart, image, map, video, webview but not all sitemap elements ?

I meant literally all of them. The documentation doesn't mention whether that replacement is done on server or client side ;-)

[lolodomo]

I am not sure to understand what you want to do with your option 2. IMHO, the label should be computed by the core framework for all UIs and provided with the REST API. If each UI starts developing its own logic, that is not consistent for the end user.

[maniac103]

The advantage of option 2 would be all sitemap widgets behaving exactly the same, there would be no special cases (in the server and JSON response).
The advantage of option 1 would be more centralized logic...but there's so much need for interpretation in the JSON response as of now already that I doubt it's much of a difference. The more important advantage of option 1 that I can see is backwards compatibility, but that fallback logic can be added to the clients in advance already.

[lolodomo]

I have suddenly another idea which is a kind of compromise with Kai's idea: the header line for image and chart elements would be hidden by default but clicking on the image will alternatively show and hide this header line. So without any click, you will still get the historic rendering without icon/label/buttons but just with one click on the image you will then get the additional line.
This solution should be very easy to implement. This is a pure Basic UI solution but the Android app has already more or less this behaviour for chart.
@kaikreuzer : would it be ok for you ?

Without feedback, I will go in that direction.

[maniac103]

This is a pure Basic UI solution but the Android app has already more or less this behaviour for chart.

The Android app now still shows a header bar (as per my second screenshot above) while it didn't do that before and which BasicUI also wouldn't show by default with that proposal, so if that were the new BasicUI behavior, we'd need to revert the respective app commit.

I assume you didn't like the idea given towards the end of #2065 (comment) ? If so, any specific reason why?

Personally I still think this + depopulated label if not given in sitemap is the best way to move forward.

[lolodomo]

I assume you didn't like the idea given towards the end of #2065 (comment) ? If so, any specific reason why?

I like it less than my last proposal for 3 reasons:

1. For label, we would introduce a kind of exception on how it is currently working (everybody seems to think openHAB is already too much complicated for users)
2. Linking the display of the action buttons to the definition of a label is weird and not intuitive
3. The method in the core framework computing the label/value of a sitemap element is probably one of the most complex method in all core framework and I would be very happy to not update/break it) :) (even if I already updated it in the past - but not recently)

[maniac103]

I don't agree with 2, since the presence of the label just controls how exactly the 4 options are displayed, it doesn't control whether they are present or not. Such kind of readjustment for space saving reasons doesn't seem too unusual.

For 1, one could also think of a client heuristic like 'if widget and item label match, assume widget label was populated from item label'. Alternatively, there could be an attribute like labelSource in the JSON response to distinguish both cases.

Item 3 really should not be a valid argument. If the code reaches a complexity level where nobody dares to touch it anymore, it should be refactored immediately ;-)

[lolodomo]

Item 3 really should not be a valid argument. If the code reaches a complexity level where nobody dares to touch it anymore, it should be refactored immediately ;-)

Yes, I know, it was more a joke, that is why I ended it with a smiley. But it is also true that the code is complicated on this part. It was changed in OH4 and a regression was introduced (hopefully quickly fixed through one of the hot fix).

[kaikreuzer]

the header line for image and chart elements would be hidden by default but clicking on the image will alternatively show and hide this header line.

If I understand this correctly, this is very much what I proposed above. When opening a page, it "looks" like before (i.e. backward compatible, without a header line) and by clicking on it, the details and buttons appear. That's what my Android app version (3.7.0) is doing and what I referred to above.

The Android app now still shows a header bar while it didn't do that before

If the Android code has meanwhile changed, maybe it would be indeed a good idea to revert it, so that the behavior is similar.

[maniac103]

If the Android code has meanwhile changed, maybe it would be indeed a good idea to revert it, so that the behavior is similar.

I'm not sure a straight revert is the best idea given people actually asked for an option for showing a label for charts:

• In Chart element icon= is ignored openhab-android#3421 (triggered change in Android app)
• [Basic UI] In Chart element icon and label are ignored #1931 and [Sitemap] Missing chart labels #1367 (triggered change in BasicUI)

While I agree we should aim at similar behavior between UIs and at not showing the label by default, I still think one of the proposals in

• [Basic UI] Improve layout of header and buttons #2065 (comment) (at the end of the comment) or
• [Basic UI] Improve layout of header and buttons #2065 (comment)

makes the most sense, as it allows the UIs finer control about when to display the header. Assuming the latter proposal would be implemented, I'd make the Android app show the label if it's populated from the sitemap widget definition and hide it if that's not the case. @kaikreuzer WYDT?

[lolodomo]

Personally, like Kai, I prefer largely my last proposal, which is very simple, providing exactly the same rendering as before by default, without changing anything (I mean nothing to change by the user), which does not introduce any special/uncommon handling for the label and which makes the presence of the header line not dependent on the definition of a label.

[maniac103]

... and which ignores the user requests to optionally show the label, because it never shows them. It's not that that proposal only has advantages.

which does not introduce any special/uncommon handling for the label

The thing is, we already do have special handling for the label, in that we do not show it for charts, images etc. at all currently.

[kaikreuzer]

I'm not sure a straight revert is the best idea given people actually asked for an option for showing a label for charts

Well, if you read the issue closely, he reported a bug that label+icon are not considered, then noticed that the label IS shown when clicking on the chart and hence commented in the issue that only the icon is ignored. This sounds to me as if he is happy with the solution to only show them in the "detail" page after clicking the chart.

I still think one of the proposals in
#2065 (comment) (at the end of the comment)

Yes, this one would also be my favorite (and very similar to my initial thoughts on top), but @lolodomo mentioned that he wouldn't know how to implement this for Basic UI (and I wouldn't know either...).

[maniac103]

but @lolodomo mentioned that he wouldn't know how to implement this for Basic UI (and I wouldn't know either...).

It was my understanding that statement referred to the proposed overlay of the buttons when hovering the chart/image. That's why I suggested the 'settings' icon with menu as a more static alternative.

IMO the implementation of the header bar does not necessarily need to be tied to the decision about whether or not to show label and icon if the label is specified in the sitemap.

#1367 (comment) shows that you had the same thoughts as now 2 years ago already ;-)

Well, if you read the issue closely, he reported a bug that label+icon are not considered, then noticed that the label IS shown when clicking on the chart and hence commented in the issue that only the icon is ignored.

That's correct about the Android report and #1931 (made by the same person), but not about #1367.

[kaikreuzer]

That's why I suggested the 'settings' icon with menu as a more static alternative.

@lolodomo Wdyt? Is such a static overlay possible? I think that would be a good compromise.

you had the same thoughts as now 2 years ago already ;-)

Ouch, you're not fair! 😛

[lolodomo]

That's why I suggested the 'settings' icon with menu as a more static alternative.

@lolodomo Wdyt? Is such a static overlay possible? I think that would be a good compromise.

I will be honest, I am now totally lost, I do not understand what is the solution you are both converging to !

Kai, your request is to restore the old rendering by default, that is no icon/title and no buttons by default and without the need to update all user sitemaps. Do we at least all agree on that goal ?
If not, what is exactly the new goal ?

[lolodomo]

Kai, what is the problem for you exactly? Is it the presence of the header line in general or is it only its current size ?
In case I move the buttons elsewhere, I could then reduce the height of the header line, the font size and the icon size. One option would then be to move the buttons in a vertical bar at the right of the image.

[maniac103]

If not, what is exactly the new goal ?

I think Kai's main goal is to not show the header bar by default. As the functionality makes sense, though, I think the suggestion in #2065 (comment) would be a good compromise, if implementable. Putting the icon bar to the right of the image still would show it rather prominently, which is why I suggested the small icon + menu thing.

[lolodomo]

Kai, what is the problem for you exactly? Is it the presence of the header line in general or is it only its current size ?

@kaikreuzer : are you there?

[kaikreuzer]

I think the suggestion in #2065 (comment) would be a good compromise

Yes, I agree with this.
I do not mind too much whether the header is there by default or not as long as there is an option to suppress it (setting label="" isn't imho really a good way for suppression). In general, I prefer backward compatibility, if it isn't clearly a change everybody welcomes. So the referred suggestion to not auto-populate the label would be a decent compromise.

Wrt the buttons, the referred suggestion is also very nice:

label empty? -> do overlay thing; if that's not possible, show a small 'settings' icon to the upper right of the chart, which then opens a menu with 4 checkbox items

This was the part I referred to when asking your @lolodomo whether this small "settings overlay" is feasible to implement or not.

[lolodomo]

I have no clear idea how to handle overlay and I will not spend several days to search how to do that, at least not in the coming weeks.

As a short and quick solution, I will make the header line hidden if there is no "label" explicitly set on the sitemap element for Image/Chart/mapview/Video/Webview elements.
And specifically for image and chart elements, clicking on the image/chart will toggle the display of the header line containig the buttons (the current header line).