[Main UI] RFC: Home page and end-user pages design

[ghys]

This issue is a proposal and a call for constructive feedback on the end-user facing screens of the OH3 default UI - which I'm sure could quickly become a matter of personal tastes - but hopefully we'll reach a consensus. For now these include:

• the home page
• additional pages for visualization and interaction with items, i.e. the current sitemaps and maybe other concepts

General goals

An "universal" app

Mobile-friendliness remains IMO one of the main goals, which doesn't only mean responsive screens: the app should be a breeze to use on desktop, tablets and phones, for example by trying to avoid clutter i.e. lots of controls on a single page, or multi-column layouts, which work okay on a big screen, but don't translate well on smaller ones (the user having to scroll through a reorganized now-single column page until they find what they want.)

This also means, as far as letting the user customize the layout and the design, not everything goes; the app should provide means of customization, but not to the point that it will become unusable because of unfortunate user-injected CSS or HTML - not everyone is an expert in design, or these web technologies, and there should be safeguards against these kinds of abuse. Providing a way to easily change a custom background image or color could suffice in many cases. For advanced custom designs, a dedicated app could be made and installed separately.

Suggest and display the most important stuff prominently

A focus should be made on displaying the most useful controls in order of importance, especially on the home page. Common day-to-day operations and information should be available at a glance. Additionally, what appears at the top could change depending on the situation - see HABot's suggested cards feature, which makes cards appear based on the result of a calculation on item's states, a version of this could be valuable here as well.

Of course, every user will have his/her own idea of what's important to them, so there should be some customization options, but we should also try to help the novice by automatically displaying common controls in the right places and avoid a steep learning curve for those who can't/won't be bothered to get into heavily tailoring their UI. One of the intended objectives of this new UI, after all, is to be appealing enough to new users by letting them set up a new openHAB instance from scratch just by navigating through the UI and end up with a functioning system.

Avoid mixing up user & admin features

The same app featuring both end-user and admin operations, it is important to "protect" the system from tampering by non-technical users. This includes both technical protections - full RBAC system if we can deliver it in time for OH3, or a simple master password in the meantime, which is imho enough in most "single family + guests" use cases, maybe other techniques can be used too e.g. unlocking the admin features per-device, These would be best discussed in another issue (# tbd).

It also involves making sure there is a clear separation between user-facing screens and admin screens, i.e. preventing unnecessary navigation from an user screen to an admin screen; if it's clearly established that the user has admin rights, maybe it becomes acceptable - but even then, it should be avoided.

The Home Page

The home page is what users will see first when launching the UI, and arguably, in many cases, the only one they should have to interact with - they have a specific need, need to flip a switch or push a button, or launch another UI, and carry on with their day. It's therefore important to get it right.

There could be alternative approaches for it, like simply displaying a preconfigured "sitemap", or their successor, to have a completely user-configurable home page, that could even be offered up as an alternative, but what I'm proposing is the following (not necessarily the final design):

The home page would be separated into 4 fixed tabs: an Overview tab, and 3 tabs, Locations, Equipments and Properties, which match the semantic nomenclature inspired by the BRICK schema and currently implemented as a core openHAB feature.

These tabs would present users with different ways of interacting with their items, but would as a general principle require them to construct a correct semantic model of their home first - which might be a problem with existing installations - so they would be automatically classified, grouped and presented semantically in the according tabs.

The obvious advantage to this approach is that the users automatically get multiple ways of interacting with items related to each other, as soon as they semantically tag them: whether they want an overlook of a specific location ("kitchen", "garage"), a specific equipment class ("windows", "batteries"), or a specific property ("temperature", "energy"), those are automatically available. The challenge is that even it's fairly easy to display a default view based on semantics alone, it might not end up in an usable and orderly fashion, and how to allow customization is now up to debate. There are also technical challenges related to querying items and listening to all (SSE) state update events in order to allow this as a client-side implementation, for large installations with lots of state updates this could become a problem with the current API.

Another issue (tbd.) will be opened to define/refine the infrastructure behind this.

The Overview tab

The overview tab's goal is to provide an easy-to-reach answer to a significant chunk of the "casual" visits to the app, like "activate the evening TV scene", "who's at the door", or "stop the music". Again, this could be easily solved by simply displaying a well-curated sitemap, but let us reflect on this a little bit further.

While the system is not completely configured, it could also be the area where hints and suggestions could be offered to ease the on-boarding experience for new users (i.e. "what to do now" cards). Example:

(upcoming link to a separate issue about the on-boarding screens)

The optional 'natural language input' section

The top part of the Overview tab would feature a text box (with optional voice input), but only if the necessary dependencies, namely HABot, or eventually another NLP/chatbot addon, are installed.

When focusing on the text box, the last 3 queries (stored in the device's local storage) would be displayed for easily recalling, if available; failing that, some generic suggestions could be offered. The query and answer would be displayed in a chat session-like fashion, with an eventual HABot card whenever relevant. As opposed to the canonical HABot UI, where previous queries are still accessible, every new natural language query here would replace the previous one.

The 'Now' section

This section, while not completely defined, is meant to provide a series of controls that are relevant to the current state of the system, like HABot's so-called "suggested cards". What appears in this section would not necessarily be automatically provided, but would require an admin to provide a "formula" or Excel-like expression yielding a boolean value determining whether the relevant piece of UI should appear or not. It would therefore be up to that admin to figure out these expressions, unless we can come up with a way to provision them easily, but this would lead to interesting ad-hoc interaction, mostly above-the-fold in the landing page of the app: thermostat controls if it's too hot or cold, remote control for the TV or music player but only if it's on, camera view when the doorbell rings or an alarm goes off, etc. If there's nothing to display in the "Now" section, it would not appear at all.

(upcoming link to a separate issue about how to define a "suggestion")

The 'Favorite Scenes' section

This section would feature a set of buttons to easily execute "scenes" relevant to the entire home.

There are multiple correct way to set up scenes in openHAB, but I would like to suggest the following: a scene would be defined as a "NGRE" automation engine's rule, with or without triggers, tagged with the "Scene" tag. That's because the UI can easily retrieve the list of rules tagged "Scene" with the REST API, and run them. In the rule editor, specific controls, like a checkbox/switch, can be offered to easily define whether the rule is a scene or not, and they could filtered out and listed separately. Additional tags could be provided on the rule to define the button's background color, icon, and order in the list.

By the way, this "scene" rule tagging could also eventually be complimented with semantic tags, so that scenes for a specific semantic concept could appear in the relevant place, for instance a scene specific to the kitchen in the kitchen card in the "Locations" tab, or a scene for HVAC equipments, etc.

(todo: screenshot with the scene buttons)

Again, this section would only appear if there's something to display in it.

The 'Favorite cards' section

This section would feature cards that are deemed important by the admin, and are worthy of being featured on the main page. The concept of a "card" is still unclear, as is the infrastructure behind it, but it should be possible to define a card from another tab (location, equipment, property) as a favorite card for easy access, and custom-made cards could appear there too. There would be a way to reorder them.

These cards would expand upon clicking or tapping and expose additional controls, like a "mini-sitemap" but with only one page.

It would also be possible to customize the header of the card, possibly with something resembling HABot's "components-slots" paradigm.

The other tabs

As for the favorite cards, the "semantic" cards, comprised of a header and a details section; however, their default appearance would be partly auto-generated, as long as there is a semantic model to support them.

Furthermore, it should be possible to "eject" them from their default, autogenerated state, and customize them completely - both the header and the details. How to do this remains is still to be defined:

• there could be a separate storage mechanism i.e. a registry of cards à la HABot and an associated API;
• per-item metadata in a specific namespace, e.g. "ui" or "card", could be used to drive the appearance of a card and/or details about their associated item

The header of the card, ideally, should display a useful overview of what's inside it (where the big "State" placeholders are), this could be defined with components/slots, or as a template defining a string: for instance {x}/{y} open, min: {x}, avg: {y}, max: {z}, perhaps chosen from a set of prebuilt ones... Interactive controls in the header are possible but should be designed with care (for instance, a global switch for all members in the details of the card).

The semantic cards are sorted alphabetically by default, but there could eventually be a way to customize their ordering.

(upcoming link to a separate issue about card customization)

Additional interaction pages

The features provided by the home page would arguably not be sufficient for more involved interactivity, therefore there would be a way to navigate to additional pages for specific needs. The most obvious ones are the current sitemaps, or their evolution; but others could be considered too, and presented on the sidebar indifferently (only the icon would distinguish them), like so:

On mobile, these pages would require two taps to access - one to bring up the sidebar and one to select them - so it's relatively trivially accessible but not quite. Shortcuts on the home page's overview tab could be worth considering.

We should now decide which types of "pages" we want to support in this sidebar:

• Legacy sitemaps: arguably the most obvious option, even if they cannot be configured interactively, only via text files; we could also deprecate them in favor of the "new" sitemaps (see below), if there's no backwards compatibility, and rely on Basic UI only to display them;
• "New" sitemaps (i.e. https://github.com/openhab/openhab-core/issues/594#issuecomment-549377670): those depend on @flaviocosta-net and it remains to be seen how well they would cohabitate with the current ones; there's a very interesting suggestion here: https://github.com/eclipse/smarthome/issues/5337#issuecomment-386506325 to version them with the Accept HTTP header, however, I'd like to offer another one: simply consider renaming the concept altogether, to simply "Pages", "Lists" or something of the like, and deprecate the "sitemap" name. If backwards compatibility cannot be ensured, this could be a way to avoid confusion, even if it would require a significant overhaul of the docs,

Other types of pages which could appear here as well;

• Card-based dashboards: useful for cameras and more condensed views, could be based on HABot's card concept; even if I suggested above it's a bad option because it doesn't translate well on mobile
• Floorplans: Full-screen SVG or images with absolute positioned controls
• Charts: the UI will leverage ECharts for ad-hoc interactive charting (https://echarts.apache.org/examples/en/), but the library is insanely powerful, and having full pages of charts configured declaratively could be done, so it's an option we should consider.

(link to a separate tbd issue on storage for additional interactive page definition)

[cdjackson]

Thanks @ghys - this sounds good, and I think it's great to get your thoughts etc out for discussion so thanks.

I would like to throw in a couple of requests (so far :) )....

Since there is only planned to be 1 UI in future, I would like to see if extendible to account for the specifics of different technologies. Rather than requiring users to use third party apps, it should be possible for binding providers to (somehow!) enhance the admin section to support the features of their technology.

A couple of examples (simple, and not so simple) -

• it could be good for bindings to be able to format the properties for a device so they are presented in a specific way and order to users.
• it could be good for bindings to be able to add another "page" to provide admin information derived from the binding (eg network topology maps) or to support specific configuration.

This is something I would have loved to have seen with PaperUI, but it needs to be considered from the outset as retrofitting this sort of extendibility is not easy.

Also, you don't mention theming. While I agree with your comments about issues with user injected CSS etc, I think there does need to be some way to configure the general theme without too much hacking. Currently with PaperUI we have the ability to add a simple fragment bundle to override files - this allows simple theming by overriding the images, css, and even js etc if someone wanted. I think it's important not to loose this capability (I'm not saying it needs to be managed through fragments - just that there should be some ability to override the look and feel without major hacking).

[digitaldan]

Thanks for kicking this discussion off!

I agree about keeping Admin and User control discussions separate, they have different concerns and do not have to be related other than being accessed from the the same core UI.

I think a goal for 3.0 is to simplify our UIs, or at least the number of them. I suspect that in this UI there will be sub types (sitemaps, HABPanel, HABot), but I think one goal is to reduce the amount of UI choices user's have right now (many of which are redundant), so the system "just works" for most people, but can be customized by expert users. Is this a correct statement?

How are we thinking we will balance the above concepts of cards, favorites and the BRICK UI along with other UIs we want in 3.0? Are we essentially creating a new UI along side our new sitemap concept and other UIs we want to keep? I'm wondering how we balance this so we actually reduce the amount of visual interfaces we have to support?

Some information i find helpful when thinking about whats important is to look at the latest openHAB community survey (https://community.openhab.org/t/community-survey-2019). UI usage looks as follows:

UI	Percent Used
Sitemaps (basic and mobile)	82%
PaperUI	76%
HABPanel	46%
Habmin	31%
Classic UI	20%
Custom	4%
Habot	2%

From the above list, sitemaps, administrative control (PaperUI/HABmin) and HABPanel seem to be the most used. The UI proposed here will replace PaperUI and Habmin, and probably include the new sitemaps, HABPanel and Habot, correct?

If so, should some your awesome ideas be considered implementing with something like the new sitemap concept? For example (and this has NOT been well thought out by me!), maybe the new sitemap concept is used to dynamically generate the home UI, using a BRICK hierarchy and including favorites, rather then building something separate.

BTW, I'm not trying to stifle innovation, or keep doing things b/c thats how they work today. I am only asking this as a question for discussion, not opposed to anything ATM. I think the concepts you have are really great.

Very excited to see this progress!

[ghys]

If so, should some your awesome ideas be considered implementing with something like the new sitemap concept? For example (and this has NOT been well thought out by me!), maybe the new sitemap concept is used to dynamically generate the home UI, using a BRICK hierarchy and including favorites, rather then building something separate.

Yes, that's what I had in mind too - hoping that @flaviocosta-net's concepts detailed in https://github.com/eclipse/smarthome/issues/5337, in particular those of definition models, prototypes and rendering models could be versatile enough to be reused in a different context than sitemaps, for instance, cards - whether they're automatically built from semantics or not. My fear is that they are maybe too complex to understand and use properly, but I hope I'm wrong. There should probably be some middle ground between these very server-centric ideas, and HABot's cards, built on hierarchies of components and slots, which are mostly client-centric. After all, both identified, I believe correctly, that component composition are the best way of designing pieces of UI these days.

it should be possible for binding providers to (somehow!) enhance the admin section to support the features of their technology. it could be good for bindings to be able to add another "page" to provide admin information derived from the binding (eg network topology maps) or to support specific configuration.

Fair point, extensibility is something I keep in mind, but it could prove difficult considering the way the UI is built (with webpack). That being said, for a limited number of "important" bindings (Z-Wave, MQTT...) I wouldn't mind seeing this kind of specific extra functionality built-in. For instance, the Home Assistant UI has a MQTT debugger which becomes visible only when their equivalent of the MQTT binding gets activated, and those screens are simply in the UI's repo. And, maybe you missed this, but Z-Wave things have a special section in the thing details page for specific actions which even features a network map 😉 It's actually a small overhead since the same ECharts library already used for line charts can handle this easily, so there's no harm in including it as a built-in feature.

_{(I have a small Z-Wave network!)}

So these pieces of binding-specific UI would have to be an integral part of the UI, and maintained as such, but with features like webpack's code-splitting they could be isolated in a dedicated chunk loaded on-demand.

[cdjackson]

it could prove difficult considering the way the UI is built (with webpack). That being said, for a limited number of "important" bindings (Z-Wave, MQTT...) I wouldn't mind seeing this kind of specific extra functionality built-in.

I'm just concerned that if we don't provide the means to enhance the UI, then we won't achieve the goal of reducing the number of UIs. for OH2, the stated position was that different technologies should use another UI to configure the devices, and then just use the openHAB UI to configure OH. To me, this needs to get resolved - pushing people to use third party applications to configure their system leads to a disjointed system, it will drive up the number of UIs (as we saw in OH2) and will ultimately lead to user dissatisfaction.

I can understand that it's not easy to provide such functions, and I don't know webpack so can't comment, but if it's not extensible, and not considered from the beginning of the development, I think we won't achieve the goal (just my opinion). Supporting just ZWave and MQTT is also a bit limiting (IMHO) - personally I would want to see ZigBee and I'm sure others would probably want to see other technologies.

I hadn't noticed the ZWave map so thanks for pointing this out. Ideally, this should be available to all bindings I guess? In ESH we had a discussion some time back about creating a provider for this (see https://github.com/eclipse/smarthome/issues/3492 which also shows the ZigBee map in PaperUI).

Is there no "plugin" system available for web UIs or something like this that we can lever off?

Again, I appreciate your work on this, and like @digitaldan I'm not trying to be negatively critical, but want to raise the issues that I see as potential blockers so that we consider them now - even if they aren't easy. Getting the right architecture and technology before starting is definitely better than trying to do it later ;).

[ghys]

Thanks for your valuable insights; I understand your concerns about extensibility and there are techniques to achieve it, what I was trying to say is, I don't actually foresee at this point many add-on authors "bringing their own UI"; maybe I lack imagination or am mistaken, perhaps it's even because of the very fact that Paper UI didn't allow that, or because in many cases, configuring things with parameters and linking channels simply works.

So my point above was to try and be pragmatic by saying, for the few who want to (not restricted to your bindings and MQTT, of course, there might be maybe half a dozen or more), maybe the better option is to examine the needs on a case-by-case basis and assist them in including the functionality in the main codebase, which would clearly offer the better development experience, rather than try to figure out what the extensibility points requirements should be (I have no idea; additional screens, additional sections in existing screens?) and making a one-size-fits-all API to inject code at runtime.

We can configure webpack to only load the required bits when needed, so there would be zero overhead for users who don't need the addon-specific functionality.

[stritti]

Really interesting concept. What I still miss in all UIs is managing of time. For example to align temperature of thermostat depending on day and time.

[Hilbrand]

Thanks for starting this discussion. I've also been playing with how an ideal UI would look like. There is already so much information here I hardly know where to start giving feedback :smile: . So I'll start with some random thoughts:

1. For me what the cards show would be the first interaction point for the user and only for detailed information should the user click on the card, or for additional features). I very much like the way HA Lovelace UI does this.
2. I think a big challenge will be to how to effectively make a admin vs user part. In the proposed pages there are pages for Locations, Equipments and Properties. For me that seems to be more relevant for administrating. An interface for a 'normal' user should be able to work only with multiple overviews. And when the user is admin the user will have access to the other pages.
3. Talking about overviews. What about having 1 overview entry in the menu with multiple pages as tabs? Either the user can give each tab an icon only or icon + text or text only?
4. In my ideal UI I would see a user can make a overview page either fixed format (cards) or free format like HABPanel and add cards or custom cards/widgets to either type of pages.
5. The terms Equipments and Properties seem to be different from what is generally used in openHAB. That does seem to make it more complicated.
6. Regarding plugins, like @cdjackson mentions. Can this be something like using the technique used with HABPanel? Using $compile? As an API the add-on registers itself as an 'App'. This 'App' would show up as an entry in the left menu. It would implement a template like structure using $compile or just an url that is opened in an iframe not bound to openHAB (This latter is similar to what hass.io does).

I hope I've been able to communicate my thoughts. Let me know what you think or if if something is not clear.

@stritti I think one reason for the missing of managing time is there is no API to manage this and few work has been done in that area making it also difficult to add this to the design of the UI. So maybe it's good to start a new topic about what requirements would be needed to make it possible.

[bjoernbrings]

Cool to see the pushing-forward spirit here :)

Though we of course all like to minimize the number of UIs I still belive that it is very important to decouple those cleanly and provide good API(s). I remember that some weaker devices had some problems with the number of REST requests (discussion on filtering)

[kaikreuzer]

Hey @ghys, let me also briefly chime in here! First of all, many thanks for your extensive work and thoughts - what you write above sounds very reasonable to me. A few comments on the discussion:

• For the user UI, I'd actually also love to see kind of "pop-up timelines/charts" on item states, similar to how HA is doing this. I'd actually suggest that we make some persistence mandatory, i.e. have an rrd4j with some default settings always active, so that we can provide such a feature in the UI out-of-the-box. It would imho make many things easier for beginners, not having to configure any persistence service by themselves.
• Wrt to keeping admin + user space separate: Yes, that's imho really important and I promise to dig into the RBAC in the next months to allow the UI to hide admin stuff from users.
• On extensibility: I think @cdjackson has a very special few here, because Zigbee+ZWave are pretty much an exception of all our bindings: They include setting up the network and maintaining it, incl. commissioning devices etc. We don't have that situation for most other bindings as openHAB rather follows the system-of-systems approach, i.e. we integrate, what is already set up and working (like Philips hue systems, where we don't want to be a replacement for the setup app, etc.). So I actually agree with @ghys: We definitely need UI extensions for certain bindings, but it should and will be rather the exception than the rule. I'd therefore think we can be pragmatic and say that those parts have to be contributed to the web-ui repo, so that we have a chance to manage building the UI.
• Wrt sitemaps: Yes, the new UI should ideally be built in sync with the new sitemap, allowing the creation or rearrangement of sitemaps through the UI itself by moving widgets. @flaviocosta-net, please let us know, if we can expect your commitment to this and see it evolve quickly - otherwise we would need a plan b...

Probably off-topic for this issue, but important to me: Imho the most urgent task is to get the new UI into the repo, so that we have a replacement of the Dashboard and the Paper UI - otherwise, our 3.0.0 snapshots are not usable at all. We should thus leave the user parts for a bit later and could simply use the home page space for the dashboard tiles, giving access to Basic UI etc., instead of hiding them in the drawer on the right. Would that be feasible, @ghys?

[clinique]

I would also add that OH3 should drop http in favour of https.

[ghys]

We should thus leave the user parts for a bit later and could simply use the home page space for the dashboard tiles, giving access to Basic UI etc., instead of hiding them in the drawer on the right. Would that be feasible, @ghys?

That's reasonable and feasible.

Really interesting concept. What I still miss in all UIs is managing of time. For example to align temperature of thermostat depending on day and time.

That's more an admin feature, but I thought about this and for now I envisioned (and implemented) a Schedule page which will present, in a "horizontal timeline" (one column per day) the expected occurrences of NGRE rules with Cron or time-of-day triggers and day-of-week conditions, which are tagged "Schedule". Other tags on the rules could help for filtering or presentation. Of course it's a client-only implementation so it only works with specific triggers and conditions, and for instance doesn't support the Ephemeris conditions. Maybe the occurrences could be calculated on the server and exposed through an API.

[kaikreuzer]

I would also add that OH3 should drop http in favour of https.

This is not related to the discussion here. Feel free to open an issue for discussion at openhab-distro to disable port 8080 on Jetty. Fwiw, I am not sure if that's a good idea...

[cdjackson]

A couple of points not mentioned here that we should consider for the admin side -:

• Ability to install addons - one of the most common questions on the forum is "how do I get the latest X binding" or some variation of this. I opened an issued in openhab-distro (https://github.com/openhab/openhab-distro/issues/1054) but as this spans repos it needs to also be considered here.
• Firmware updates - ie I'd like to not loose the current PaperUI functionality to interface with the FirmwareProvider to allow people to load new firmware to their things.

[kaikreuzer]

@cdjackson Imho this issue and the discussion @ghys started here is not at all about the admin features (which yes, should offer what was possible with Paper UI as well), but about "home page and end-user pages". So please let us stick to the topic here as those discussions easily head into a million directions.

[cdjackson]

Ok, sorry about that. I'd thought this was a consolidated UI discussion, but re-reading it, you're right, it's just focused on the user side. Is there a discussion as well about the admin side of the UI or do we start another?

[kaikreuzer]

Is there a discussion as well about the admin side of the UI or do we start another?

I'd suggest to wait until @ghys published the current code here. We can then have individual issues for whatever needs to be enhanced. Or even better: Individual PRs to add further functionality to it :-)

[cdjackson]

I'd suggest to wait until @ghys published the current code

I really think that we should capture the need somewhere rather than waiting until the code is published. I don't mind if it's one issue for all admin features, or separate issues (which might be clearer) but I think we should capture things so there is some visibility of the "end" design.

[ghys]

With the addition of the component registries API (https://github.com/openhab/openhab-core/pull/1356) we can move forward, here's how I'd suggest to proceed:

1) add a new Pages section to the settings, which would list and allow the user to create/edit in a central location: a. the "component-based" sitemaps (in the system:sitemap component namespace) which are transformed to actual sitemaps and made available to other clients b. additional future types of pages, which are only meant to be rendered by the main web UI. To keep things simple and minimize API requests, these other pages would all be in the ui:page namespace regardless of their type (see below), the type of the root component being the type of the page; 2) make an editor for the component-based sitemaps first; 3) decide which types of pages we'd want to support, some ideas (already mentioned in the OP): a. Chart page: a fullscreen chart, preconfigured in the settings but with some interactive features on the page itself (like changing the period or showing/hiding data series) b. Map page: a fullscreen map to show preconfigured Location items c. Floorplan page: a fullscreen raster or vector background image with icons, labels button positioned over it. The ability to configure multiple floor plans and switch between them with a menu or a swipe on the screen but technically stay on the same page would be nice too. d. Layout page: widgets arranged in a multi-column, grid-based fashion. This would be preferred to sitemaps for e.g. security cameras, or generally to make the most of the screen real estate when on a desktop or tablet. A separate editor adapted to each type of page might be preferable to a one-size-fits-all editor.

How to order pages on the sidebar? Some options:

• Alphabetically using the label, regardless of type
• Alphabetically using the label but grouped by type (which order? sitemaps first then layouts, charts, floorplans, maps?)
• Alphabetically using the ID, regardless of type - the user would have to choose these IDs, so the order could be chosen using e.g. ID prefixes like 1... 2.... The caveat is that we cannot hide these technical IDs from the user (so no using GUIDs) and we should support changing them.
• Alphabetically using the ID but grouped by type - see above
• Using tags on the root component - for sitemaps we'd have to retrieve the source components just to get the order since it's not on the resulting sitemap.
• Using an "order" numerical property on the root component - see above

[digitaldan]

Awesome work over the last couple weeks!

Just to clarify, if the user can create/edit pages in the settings menu, which i am assuming you mean adding a new menu here:

Is each type of page added as a submenu, or is each user created page listed and there is a "add" button somewhere here?

Does that page then become available at the top of the left bar, as shown here (which are sitemap pages atm), for the user to select and use?

make an editor for the component-based sitemaps first;

Do you have an idea of how to do this? Are you thinking a wysiwyg type editor ala Habpanel?

[ghys]

Is each type of page added as a submenu, or is each user created page listed and there is a "add" button somewhere here?

I wanted to add a single list for all types of pages, and the "+" button expands to select the type, like this:

Does that page then become available at the top of the left bar, as shown here (which are sitemap pages atm), for the user to select and use?

Exactly, like shown in the OP - the icon reflects the type:

make an editor for the component-based sitemaps first;

Do you have an idea of how to do this?

Not sure if true wysiwyg is possible because there's some server-side rendering, but maybe some kind of tree-view based editor - I'll try to make it possible to show a "code view" as well to allow the edition with the current syntax in an editor so that copy-paste etc. becomes possible (just finished a Nearley grammar for that).

[digitaldan]

Thanks for the clarification! Wrt to the different page "types", are all of these still based on the new sitemap concept? Or are all of these different UI implementations? I guess i'm confused how a page would be a Map or a Chart, as i would assume they are children/components of a page, so you would create a new "page" and then add a chart or map along with other components.

I'll try to make it possible to show a "code view"

Do you have an embed editor out there in mind? It would be awesome to have something like Eclipse Thea (https://theia-ide.org/) embedded in for this and other types of file editing (like everything in /etc/openhab), but most of these require a node backend, so i'm not sure how that would work (sounds too heavy weight)

[ghys]

Wrt to the different page "types", are all of these still based on the new sitemap concept? Or are all of these different UI implementations?

Apart from the tried and true sitemaps, my (opinionated) idea was to leave the rendering of the other types of pages entirely to the frontend to avoid a complex, possibly rigid chunk of server-side code in the OH core that someone would have to maintain - the pages would be rendered with Vue components solely from their definitions stored as JSON on the server, dynamic data would be injected from a client-side dictionary of item states (in a Vuex store likely) kept current with SSE. These pages aren't meant to be client-agnostic like sitemaps, the main UI being small-screen friendly and a PWA it can be run almost anywhere.

I guess i'm confused how a page would be a Map or a Chart, as i would assume they are children/components of a page, so you would create a new "page" and then add a chart or map along with other components.

I thought about it and it would make sense to make the charts, maps and floorplan top-level, fullscreen pages, as opposed to letting them be inserted into a layout page - it's easier to get things looking good esp. on smaller screens - so the root component would be a ChartPage, MapPage or FloorplanPage, they would be rendered accordingly and when editing the specialized editor will launch.

Do you have an embed editor out there in mind? It would be awesome to have something like Eclipse Thea (https://theia-ide.org/)

I have used CodeMirror so far throughout the UI, it's fast, fairly lightweight, has a decent feature set, and easily embeddable; also it's treeshaken i.e. gets loaded only when a page containing it is displayed. Full web-based IDEs like Theia are maybe a little out-of-scope for the main "default" UI which shouldn't IMO become bloated, there's still the possibility to bundle more specialized UIs separately, an IDE for advanced editing would be a good candidate.

[digitaldan]

Thanks again @ghys, i really do appreciate the amount of time and passion you have put into this, before i continue, i just want to reiterate that i am only voicing my opinion for discussion, and am very open and flexible to yours and others point of views on this, i can be easy persuaded :-) so i hope my comments do not come off as cross or discouraging.

I am trying to wrap my head around how we have a consistent approach for the UI's. I really like the idea of cards , maps, and even the SVG layouts, but having them as parent scopes, and not part of a more cohesive strategy seems like we are creating more UI's , not less. So in additional to the new SItemap, we now have a SVG UI, Card UI, and Map UI.

I'm also thinking about what use cases a user would want these concepts only as separate components, and only navigable by the hamburger menu at the top left. It feels to me like we would be introducing cool concepts, but not very practical for users wanting a single dashboard like view of their system.

In a perfect world as a new user of openHAB, logging in to our dashboard would give me some default layout based on groups and items. I think we agree this would be the job of the new sitemap using some default generator. Being able create a new "page" and then able to drop in the elements you mention above would be ideal, but having to choose between very different layouts that don't talk to each other through navigation seems disjointed to me. I worry we are not really solving the problem of having a strong consistent UI experience, bu creating multiple unrelated ones.

Of course, i may be way off base here, curious what others here think as well.

I have used CodeMirror so far throughout the UI,

Sounds great! That quickly became my first choice as well after googling for a bit, I think i saw in one of your commits you have already written a language plugin for sitemaps, very impressed how quickly you got that integrated.

[digitaldan]

I also want to ask the question, should we be focusing on making the new Sitemap concept the only technology driving any new UI's in 3.x ? If we want to support things like SVG layouts and Cards, should we be making that part of the new sitemap spec rather than something new and separate ?

[ghys]

Hi @digitaldan - don't worry, every constructive feedback and friendly discussion is welcome and appreciated - I know that UI design is often subjective ;)

Regarding the overhaul of the sitemap concept, after giving it some thought and some discussions about it in Brussels, I'm not convinced anymore we should necessarily pursue it at all costs. I'll try to explain some of many reasons why I reached that conclusion:

• The proposal (https://github.com/eclipse/smarthome/issues/5337), while generally well thought out, is very ambitious and the initial implementation attempt (which, I believe, now differs a bit from the specification) involves a quite complex definition-model-to-rendering-model transformation engine powered by Eclipse Epsilon - which made sense at the time because ESH was an Eclipse project - and prototype definitions to make that translation. Having such a significant addition to the openHAB core codebase would likely be an equally significant additional maintenance burden, with deep knowledge of its intricacies required from at least one active maintainer. Moreover, the code doesn't seem to have changed in 1.5 years, hasn't been ported to openHAB since ESH was discontinued, and - unless I'm proven wrong - there haven't been any signs recently indicating we can expect it to ship within the year as part of openHAB 3 (this includes a rewriting of all clients);
• The current sitemaps have been successful partly (IMHO) because their API and semantics are stable and limited in scope; there are only a dozen widget types or so, with limited leeway for rendering and styling. That's why we can enjoy multiple mature, feature-complete clients for different platforms, and gracefully degrade the rendering of these widgets according to the capabilities of the tech (smartwatches...). If we push this concept of "define once, render everywhere" too much and extend it to the point where we end up with broad, detailed rendering models, it'll mean we'd have to implement these extensions on all clients - there could be many reasons why one of the other won't keep up, so we run the risk of having varying levels of support across clients. This would be a bad look. And let's be brutally honest here - hopefully it won't be perceived as nearsightedness or a lack of ambition -, at the moment, there isn't too much momentum to improve the UI situation or developer bandwidth to rewrite all clients and keep them current while we add things to the spec;
• The very concept of a sitemap as an all-encompassing UI paradigm might be limiting for different, innovative types of interaction, especially when prototypes have to be declared on the server for the rendering engine beforehand. Let's take a wildly imaginative example: say someone want to do an augmented reality UI - putting some widgets over things when looking at them. Surely the sitemaps won't help much here, and since the client would be highly platform-specific, there's no point in defining prototypes on the server for a single client.

That's why I presented a pragmatic alternative - we keep the sitemaps as they are, continue to support them for the time being to keep our client ecosystem working, and add:

1. a flexible storage facility for frontends who can reserve a namespace for themselves and keep their component definitions in the JSON DB (https://github.com/openhab/openhab-core/issues/1355);
2. a much more efficient SSE endpoint (instead of a translation to a rendering model) to get states from items (https://github.com/openhab/openhab-core/issues/1363) and hydrate the UIs with current data - or perform client-side computations to e.g. alter the styling or the rendering in general.

The frontend is therefore completely responsible for all aspects of the rendering including dynamic data using only the component definition and item state SSE endpoint, which is not a problem with modern frameworks.

This also means we now don't automatically consider anymore that there would be multiple client implementations for a specific component namespace, with the notable exception of the system:sitemap namespace which acts as a "bridge" to the sitemap world - components are automatically translated to sitemaps. This allows us to have editable sitemaps with the API as an alternative to the DSL, and therefore we have addressed what was one of their major shortcomings until now. We could introduce more system:* namespaces, the prefix indicating that the components in that namespace are generic enough to be rendered (perhaps differently) on multiple clients.

Hope I have explained my vision clearly enough - as for pages (pages are hybrid concept consisting in sitemaps and other types only implemented by the main UI) and which kinds we'd implement, maybe it's better if I open another issue specific to them in the coming days :) Note that featuring a page on the sidebar could be optional, and we could for instance allow links between pages on dashboard-like layouts, so an user could display only a few top-level dashboards on the sidebar and build hierarchies with pages accessible only with links from other pages.

The design of the home page (which is a priori not a "Page" in the sense described above) esp. the overview, which should IMO focus on dynamic, contextual elements is also not final.

[digitaldan]

the code doesn't seem to have changed in 1.5 years, hasn't been ported to openHAB since ESH was discontinued, and - unless I'm proven wrong - there haven't been any signs recently indicating we can expect it to ship within the year as part of openHAB 3

If this is not being actively pursued, and there is no appetite for others to continue the work, then that significantly changes my opinion of how we move forward..

If we push this concept of "define once, render everywhere" too much and extend it to the point where we end up with broad, detailed rendering models,

Something similar was eating at me as well regarding a more complex server side rendering engine and complex DSL; we actually already have a standard UI DSL, its called HTML :-) So not reinventing the wheel again sounds good to me :-) ( I know this is an over simplification of how complicated HTML is and the fact it includes logic in javascript)

a flexible storage facility for frontends who can reserve a namespace for themselves and keep their component definitions in the JSON DB (openhab/openhab-core#1355);

Sounds reasonable, i would imagine HABPanel would be a good candidate for using this right away.

as for pages (pages are hybrid concept consisting in sitemaps and other types only implemented by the main UI) and which kinds we'd implement, maybe it's better if I open another issue specific to them in the coming days :)

I don't want to slow us/you down right now with too much chit chat :-) So i leave that up to you. Do you see each UI having very different code bases, or do they share significant portions and only have different views? If the later, i think the code speaks for its self, and we can where we need to open issues, or use PR's to converse.

and we could for instance allow links between pages on dashboard-like layouts,

Anything we can do to present the various UI pieces as a single UI replacement would be really helpful

I also think making it easy for users to submit "official" widgets into this would be awesome, much like HABpanel custom widgets , but hosted on our own repo. I'm hoping that would attract more contributions on an ongoing basis and keep the UI's very active.

Fwiw, I think HABPanel is a wonderful example of an extensible and user friendly UI (along with a UI editor), with a focus on panels/tablets of course (I use it extensively at home). Hoping this does the same for web and mobile (through a webview or cordova).

[ghys]

Something similar was eating at me as well regarding a more complex server side rendering engine and complex DSL; we actually already have a standard UI DSL, its called HTML :-)

Not really HTML in our case, but a composition of specialized components, each configured according to their own semantics defined by their client-side implementation (typically as a Vue component at least for components built for the main UI in the "page" namespace). For this namespace in particular I also generalized the expressions evaluation system also found in HABot cards: you can make a configuration parameter dynamic by prefixing the value with "=" (a "tribute" to MS Excel) and then it will be treated as an expression instead of a literal and evaluated with https://github.com/donmccurdy/expression-eval. We have to be careful with that of course (performance and security wise) but it unlocks a lot of potential for building specialized widgets, here's an working example in a "sandbox" I've built to test the concept:

The layout on the right there, including the first card with the multiple sliders, is entirely generated from the component tree on the left. Colors, disabled status for the button etc. are achieved using expressions and use item states. It's almost working already actually but depends on https://github.com/openhab/openhab-core/issues/1363. And of course I only implemented a handful of components so far, having a good robust set of them is probably what will prove to be the bulk of the work.

Do you see each UI having very different code bases, or do they share significant portions and only have different views? If the later, i think the code speaks for its self, and we can where we need to open issues, or use PR's to converse.

There will be a standard so-called "layout page" (similar to HABPanel's dashboards or Home Assistant's Lovelace main page) which will come first and have its own designer UI. You will be able to choose from a gallery of built-in widgets or custom ones that you designed or imported (they can be serialized to JSON or YAML). Then eventually the dedicated pages for maps and charts and floorplans will come later - I had this idea of making more top-level pages for these because 1) the more screen estate you can give them, the better; 2) dashboards often don't offer a great experience when reduced to a single column layout on small screens, you have to scroll a lot, everything's rearranged and if some widget interferes with the scrolling (like a map or a chart), it's annoying. Ideally these other pages will have their own designer: configuring chart series or putting icons on a floor plan is significantly different than adding widgets to a dashboard. However all will have a "code" pane with a YAML representation of the entire component tree, because copy-pasting and editing code is often the best way of duplicating and rearranging elements than endlessly clicking buttons :)

[digitaldan]

@ghys looks awesome, can't wait to see more of it !

[flaviocosta-net]

Hi @ghys, first of all, congratulations for the detailed and meticulous proposal on the much needed improvements to the UIs. Some intriguing and promising ideas here and on RFC/new concept: UI component registries. So far, I have not explored in detail the possible inclusion of sitemaps in the end-user/admin pages, but I have played with a possibility by creating a sitemap that does not generate its contents from a typical sitemap definition file, but directly from the items registered in the system. It was fairly straightforward to do, and it is possible because of the conceptual separation of a "definition model" and a "rendering model" - the sitemap client is only aware of the rendering layer, it doesn't matter how or where the sitemap contents are defined.

The main reason for the very slow progress on this implementation is my limited spare time, having to juggle family and professional commitments, and contributions to the project. Earlier this year I have started to migrate the implementation from the old ESH codebase to OH and I expect to be able to resume and complete that now.

One point you mention here and that is a concern is the eventual complexity to maintain the implementation. I'd say that this new implementation may be twice as complex as the legacy sitemap implementation, but I think this cannot be completely avoided if we want to have a versatile and flexible solution that does not require significant programming skills from the end-users. We definitely need to have a clean and composable framework behind the scenes to enable developing advanced scenarios such as an augmented reality UI, but sitemaps would still be a relatively alternative to easily cover 90% of the UI needs of the average user.

Another interesting point is related to the name itself, "sitemaps". The new concept should allow alternative layout choices, be it a vertical menu with navigation as we have today, or panel/dashboard/card views. If everyone is fine with extending the idea of what a sitemap is, we could keep the name regardless of the layout choice, or eventually rename it as "page set" or anything very generic if preferred.

Yes, there are other specific challenges to be discussed, such as the handling of stale SSE subscriptions and backwards-compatibility with legacy sitemaps (I've tested it, looks quite feasible, but there is some work involved in terms of REST APIs). Still, I will work on finishing the migration of what I already have to the OH codebase and then post the news on Question: Sitemaps to keep the threads separate instead of hijacking this one. We could then have a joint look into these ideas and see how to better make everything work together.

[digitaldan]

Hi @flaviocosta-net did you read comment https://github.com/openhab/openhab-webui/issues/155#issuecomment-589632450 completely ? My understanding is that the "new" sitemap concept would be difficult to implement due to the reasons listed in that comment. Do you have a different point of view on those points?

[ghys]

Hi @flaviocosta-net, nice to hear from you again! First of all:

The main reason for the very slow progress on this implementation is my limited spare time, having to juggle family and professional commitments, and contributions to the project

No worries at all, of course, nobody here is going to blame you for getting your priorities in order, on the contrary 🙂 At the same time though, I'm sure you'll understand we'd also like to move the project forward and some decisions on how to proceed have to be made if we're left in limbo for too long ;)

The idea behind the "UI components registries" is that it would be a flexible way to store definition models centrally, and since they are organized in namespaces, we could decide, namespace by namespace, whether those definitions are meant for a single client only which would consume them as-is and "take it from there", or on the contrary be generic & universal, with translations to rendering models. The sitemap provider which translates component trees found in the system:sitemap is a good example of the latter case, and your proposal has certainly its place in this category as well - as in, if you find a way to fit your definition models in this model, we could reserve a namespace for them - but as I mentioned, as we expand such a "one-size-fits-all" model for sitemaps (or whatever they'll be called), whether it's going to be successful or not really depends on how the multiple clients it's targeting, and how they are going to catch up and keep offering an uniform level of support... which is not necessarily a guarantee. Still, you're very welcome to keep pushing your ideas forward as everyone is eager to having constructive discussions on these difficult concepts.

[flaviocosta-net]

Hi @digitaldan, the link you sent takes me to a comment made by @ghys, but let me try to address the general concerns that you raise on your previous messages:

I have considered the question as to how flexible and extendable standard sitemaps should be. I agree that there is no reason to reinvent HTML/JS and allow the users do whatever they want. The approach I have taken so far was to start extending existing sitemap functionality (this is also good to make the transition easier for existing users). This first phase is actually mostly implemented, so most of the difficulty here has been addressed, but it will be important to finalize it and issue a PR to start having more testers and input.

As I hinted on my previous message, I think that offering different layout options is a very important aspect of making sitemaps more flexible than they are today. A certain sub-page in a sitemap could be displayed with a card layout, or show an SVG file with a floorplan, so you don't really need to go outside of the sitemap implementation to have these UI options. As I could not yet reach that point, I am not 100% sure how difficult it will be to translate the concept into code, but I can't see why it would be much harder than the part mentioned above and that is already functional to a high degree.

Please let me know if I somehow addressed your point, or if you are actually referring to something else.

[flaviocosta-net]

@ghys, with things more organized on my side now, I plan to spend some hours per week to contribute more actively with the project and finally start delivering something usable!

The way my implementation has gone so far, it makes the definition model and the rendering model not only separate, but completely independent. The client only "sees" the rendering model, it is the agreed API/contract between client and server. The definition model only exists behind the scenes, it is "translated" into the rendering model before being sent to the client, but it can come from anywhere: a DSL in a text file, from the ItemRegistry data, an RSS feed or, why not an "UI components registry". You can have a fancy editor to configure and position your UI components, then this definition is exposed to the Sitemap infrastructure by a SitemapDefinitionProvider... and at the end you have a Web UI, an Android client, or anyone that will consume the generated rendering model from any of those sources indistinctly. This is a possible use-case to extend on what sitemaps do today.

However, from what I could see in this conversation, perhaps you mean the opposite thing: you would have this universal app where you can insert widgets and menus containing a sitemap. This falls outside of the scope I am working on, as I am not trying to provide a replacement for the Paper UI, but this may work as well. You could have a widget that "understands" the rendering model, so it acts as a web client for sitemaps. You could even use it to build some kind of dashboard where you see multiple mini-sitemaps side by side on the same page: one showing weather-related information, another with light controls, etc.

I'd need to better understand what we are trying to achieve here, but unless you believe I might be going on the wrong direction, it will probably be easier to discuss and validate once the new sitemap implementation is ready to be tested!

[digitaldan]

@flaviocosta-net apologies if my comment was terse and maybe not so clear, and i am glad you are back !

I only asked about @ghys comment b/c he addresses some concerns about moving forward with the sitemap concept, as my previous comment was made with the understanding that there were not concerns. I just wanted to make sure we are on the same page.

I'd need to better understand what we are trying to achieve here

For 3.0 the most important feature for me is to have a new UI that replaces both the old sitemap as well as paperUI as the main UI for users. While we will support current sitemaps and Habpanel setups, this new UI should be where most users, especially new users, interact with openHAB.

I'm curious how a redesigned sitemap system fits into the current efforts @ghys is implementing and how this would help with simplifying the UI choices for users? Are these two efforts completely different or is there a commonality between the two that can be used so we don't have more UI choices for users.

Looking forward to hearing others POV on this.

[flaviocosta-net]

Well, there are concerns for sure, but I think these are usual design choices and challenges of such complex frameworks, nothing out of the ordinary. :slightly_smiling_face:

As far as I can tell for now, the only change to what is being implemented by @ghys is that eventually he would need to support only the "new sitemaps", and that should be enough to give users the choice between more traditional sitemap layouts, and a dashboard/panel one.

Other than this, maybe there would be no major changes to what is being planned here, but for now I think it will be more productive to just finish delivering what I already started, and shortly after we can review more in detail if there are possible synergies in other aspects.

[ghys]

@flaviocosta-net another thing, I'm not sure what your plans are wrt backwards compatibility or coexistence with the current sitemap (rendering) API, and how much you want to the expand the scope of the sitemap concept; in any case, please keep in mind that it is an API that is being consumed by 2 native mobile apps, several web apps and possibly other unofficial apps.

In other words, by making changes to this API you're potentially affecting a lot of people, so I think it would be a good idea to make sure the maintainers of these clients (at least the most popular, I'm mainly talking about @openhab/android-maintainers and @openhab/ios-maintainers) aware as early as possible of potential breaking changes, what your vision is and how it would affect them - it's IMHO very important to make sure everyone's on board and able to deliver the necessary changes by the time we'll decide on a OH3 release. You'll also have to convince @openhab/core-maintainers so I'd advise you to open a PR there as soon as possible as well (use a [WIP] prefix) and push often so that people could have a sense of what the impact for them as maintainers will be, and a chance to scrutinize it.

As you probably know, the governance of the project has changed since the ESH days, it's run by volunteers on their spare time that can't be expected to cope with API breakages because "they have to", so drastic changes with repercussions to other developers have to be carefully planned and reached by consensus.

[flaviocosta-net]

Hello @ghys, these are valid concerns that came up quite early in the thought process of this proposal. The idea is to have zero impact on existing APIs, i.e. existing clients should continue working with no or very little changes, new sitemaps should be mostly invisible to them. There will be new/different endpoints for new sitemaps, so current functionality will keep working.

When I think about backwards compatibility, it is regarding the possibility of serving old sitemaps via the new API, so new clients would be able to also display legacy sitemaps. Need to work a bit more on this topic to see how difficult it is, and if it's worth the effort or if it will be easier to provide some script to re-write existing *.sitemap files to "upgrade" them.

The only "bad news" is that the new API will be significantly different from the previous one. The code on the clients that display the interface elements (icons, sliders, labels, webviews, etc.) may be reused to a great degree, but the communication with the server would need to be mostly rewritten for existing clients to support new sitemaps. For instance, the new sitemap structures can be downloaded only once, and only re-downloaded if the sitemap definition changes, while today each page navigation requires a new API call. The plan is to deliver much more flexibility to end-users and improved performance, thus creating a natural incentive for this migration. A sample JavaFX client application also exists and can be used as a reference implementation.

I just finished setting up Eclipse 2020-03 and adjusting my code to remove compilation errors (e.g. many package names changed from "org.eclipse.smarthome" to "org.openhab" since January when I last worked on it). I will now start working on testing and fixing runtime errors, so if all goes well then in a few days I should have something working - I will then push it to GitHub and open a new PR to start getting some feedback.

[ghys]

I'll close this as it has been largely implemented (for the most part) now and I'd like to open new RfCs to define the spec of the customization features for the home page.

[sirupflex]

Hi all, joining here by following the reference of @ghys in the "ontology improvement" discussion. First of all, I'd like to give a huge Thank You to all the developers for making OpenHAB 3 happen. I love it, it is a huge steps forward and while having migrated my (kind-of) "Pseudo Smart Home" from OH 2.5.6 to OH 3.0.1 already, I discover more and more great options to do things. I also discover sometimes some limitations where I wish I had more flexibility in shaping my "Smart Home" interface, and I'd like to share some feedback here.

One focus is that whatever we do and design, it shall not only be usable by IT geeks like me but it also has to be understandable and intuitive for my whole family. Personally, I can live with a lot of tekkie-tweaks and "funny exceptions / limitations / work-arounds" but my family cannot. They need to be able to just click one icon e.g. on the PC or Android mobile and then expect the "something" to open that they know and where they easily can control the few things in the house that they want to control.

In addition, that "something" they see has to follow their own "daily experience logic" which might be very different from an abstract logic of technical hierachies. And I guess every family has a different "experience logic", hence the UI should be as flexible as possible so families can tailor it to their own world. And here I love the general Pages concept with the different kind of pages, it addresses a lot of these needs, great job!

Despite the desired UI flexibility, and this is the challenge, OpenHAB as a system has to follow its own strict logic and model to work, of course. This means that the UI should give the user the possibility to customize the experience beyond the OpenHAB internal logic and model, hence internal model and visualization should be decoupled as much as possible or, to be more precise, visualization can follow by default the internal logic and model but should allow the user to modify it to their needs beyond that (without impacting/changing the internal model and logic, of course). Yes, I know, this is certainly a challenge, but let's see.

As an end-user, I have at the moment three different ideas on my mind that would provide me with more flexibility to design my own "home page" / user interface for my family's needs:

• Being able to have my own "Home Page"
• Being able to use the "Locations" tab and the "Equipment" tab also in my own tabbed pages
• Getting more flexibility in grouping equipments on the Equipments tab

To avoid ultra-long postings, I'll put the first two points in a follow-up posting, and the 3rd point I'll add in another separate one after that, hoping that this helps for readability and for the discussion.

[sirupflex]

Idea 1: Being able to have my own "Home Page"

The request is very simple. Currently, when OpenHAB opens, it always opens the default "Home Page" with the 4 tabs (unless you hide some tabs). I want to be able to define my own "Home Page". Means, maybe I design my own tabbed page, or I want to have a floor plan as home page, etc. ... would be great if I could mark one of my pages as the "Default Home Page" and then, when opening OpenHAB it always loads that one by default instead of the current standard Home Page.

Alternatively, if this is not possible or desired at all, as a second priority then please allow me to generate a link / URL that takes me to my own Page directly. At the moment this does not seem to work when using the direct link, neither on the PC nor on the Android mobile. Which page is opened currently seems to kind of depend on what is in the browser cache or similar, it is not predictable as it seems.

Idea 2: Being able to use the "Locations" tab and the "Equipment" tab also in my own tabbed pages

Maybe I don't want to use the default "Home Page" of OpenHAB but I still want to use the "Locations" tab and/or the "Equipment" tab and/or "Properties" tab. Would be great to be able to reference any of these three tabs like any other Page. So I could either use it as a stand-alone Page, or reference it in a tab of my own tabbed page (i.e. mixing my own page tabs with the Equipment tab on my own tabbed page). By that I have the best of two worlds. Being able to have my own tabbed page but still being able to benefit from the auto-created Locations/Equipment/Properties tabs that I generally like.

I'll add "Idea 3 (Equipment tab)" later when I have more time. Thanks in advance already for your ideas and feedback.

[Hilbrand]

@sirupflex Don't start new discussions on closed issues, just open a new issue.

[sirupflex]

@Hilbrand I was explicitly asked by @ghys , the owner of this discussion, to continue the discussion in this thread. See https://github.com/openhab/openhab-core/issues/1791#issuecomment-819910296

[sirupflex]

Thank you very much for re-opening, Yannick!

Idea 3: Getting more flexibility in grouping equipments on the Equipments tab - and grouping objects for visualization in general

It is great to have the "Equipment" tab where your equipement is displayed and grouped automatically based on the semantic model. Unfortunately, coming from the "daily family experience logic", things that make sense to be grouped from a semantic model point of view do not necessarily match that "family experience logic". And, every family's "experience logic" certainly is different.

Example: In the HVAC model group there is our air conditioning devices, the comfort ventilation system and the head-pump / heating. From a semantic model view, it is perfectly fine for me to have them together. In our daily family experience, however, they have nearly nothing in common. The rest of the family doesn't care about the heat-pump and neither needs nor understands to control the heat-pump. The family, however, clearly uses the air conditioning daily during hot summers. Having those items together in a display group does not add value for the family and confuses them.

So visually, I would love to have a separate card for "Air Conditioner" (that lists our two air conditioner devices), a separate "Heating" card for the heat pump and a separate "Comfort Ventilation" card, and the standard "HVAC" card I would simply hide. Again, it is just about the visualization, not about the sematic model.

How to do that? As it's pure visualization, maybe use metadata to define a "Display Group". For this option / field, if it is empty it uses the semantics model tag as it does right now. If you enter a string into the "Display Group" field, the string equals a Card. If you use the same string for multiple objects / groups / equipment, then these would be grouped together in the same card with the default label of that string.

That "Display Group" metadata could be a separate metadata item or could be another field on the "State Description" metadata item ... although it is not so much about the "state description" but then again, many options there are also mainly about the visualization.

Alternatively, if you want to explicitly work with groups (and also that String would just be a group in the background, basically), you could either define a special "tag" that defines a Group as a "Display Group". Or there is by default a root "gDisplayGroup" and then you can define child groups which would be used as "Display Groups" in the Main UI for the above purpose.

To spin this further: You could theoretically also start grouping any kinds of groups, equipment or single items visually, not just the ones in the semantic model. So you could start to create "visual cards" that groups any kind of equipment, locations, items, functional groups, etc. together.

Where to display these cards then? Either you look if the "objects" are defined as equipment, you display it on the "Equipment" tab automatically. Or in the "Home Page Settings" page, you have next to "Equipment", "Location" and *Properties" another section called "Custom Display Cards" where you list all the user defined "Display Groups", and you can even assign them to one of the three standard tabs (Equipement, Location, Properties).

To go even more crazy, you could introduce for pages a new Column / Cell type "Display Group" or so, where you can assign then a user defined "Display Group". So, when you click on it, a pop-up opens with the objects listed that you assigned to that "Display Group". And you can chose e.g. one of those items in that group as the default item to bevisualized on the Cell by default ,,, and so on ...

Honestly, I do not know at all about the feasibilty of such an approach. Might be a total nightmare and not worth the effort, or maybe there's a way to do so. Would be interested to hear some feedback.

[rkoshak]

Continuing the discussion:

1. I think is a good idea and I've seen several request for just this ability. Additional use cases, which will require working with the phone apps, are to have a the choice of a different default page on the apps from the default page for the browser.

2. I'd make this idea finer. I think it would be more flexible and address more user's use cases if they could reuse the cards from the Locations, Equipment, and Properties pages. Alternatively, making the basic card structure used there available as a base widget we can populate. I have seen many requests for something similar as well. Another related idea would be to allow users to add/remove tabs to the Overview page itself. Some users may only care about the Locations tab and want to remove everything else. Others might want a chart page or floorplan page to the be Overview instead of a layout page.

3. The rest of the family doesn't care about the heat-pump and neither needs nor understands to control the heat-pump.

Then the questions become:

• Why is the heat pump a part of the model at all?
• If it makes sense to have them in the model, why are the controls for the heat pump not hidden from regular users so only you as the administrator see them?

It is far better IMO to simply not show stuff to the "end users" at all than it is to move it to some "don't click here" section of the UI. And you can control whether or not controls show up using the visibility and visible to properties of the widgets. I've already opened a separate issue to address the fact that if all the Points in an Equipment are hidden, the gray label shouldn't be shown in the card for that Equipment (the same should probably apply to Points on the Properties tab). Visibility is really powerful to simplify the cards. For example, a Chromecast or Spotify or Sonos Equipment might have a dozen or more Items in the list. But only 0-2 or so of the Items are relevant when nothing is being played. So why show all those all the time? Only show them when there is something meaningful to show.

Again, it is just about the visualization, not about the sematic model.

Here is where I start to have a little bit of heart burn. The Equipment tab is supposed to reflect the model. If we start to break stuff out and show stuff in a way that is not part of the model we pretty much lose that. The Equipment tab becomes just another page that has a bunch of hard coded customizations that are independent of and do not reflect the actual model.

And that may be OK in the end. I'm not really arguing against this as a concept. I was mainly arguing against implementing this as part of the model on the other issue. I don't feel super strongly about it and over all I don't personally find the Equipment tab all that useful as is. But I do want to make it clear that it would be a loss on that front. No longer can the admin rely on the autogenerated cards to help understand what they've done in the model.

And to make another twist on the idea, what about merging Equipment that is currently shown on separate Equipment cards but do not need to be? I have four separate Door equipment tabs. At most I'd need two but ideally I'd want just the one. There really is no difference between the Front Door and the Back Door and the door to the Garage in terms of the type of Equipment they are. They are all external doors.

And for the end users, based on my own experience and what I've seen on the forums, only the Locations tab ends up being used a lot. The Equipment page largely gets replaced by a custom built Page(s) with custom widgets that unify the controls for something in a more intuitive way. For example, what's easier for end users to use:

(Notice that there is already a ton of customization and combining of the Items in the above. )

or this:

I don't have a thermostat connected to OH right now but that would make an even better example. What is easier for a user, a list of a bunch of independent values and discrete controls or something like

(see https://community.openhab.org/t/oh3-widget-daikin-aircon-hvac/118452).

To achieve the same capability on an Equipment card you'd have an Equipment with 15-20 Items listed.

More and more of these reusable example custom widgets to accomplish these unified complicated display and controls which are much more intuitive are being posted to the forum. Some day hopefully we will have a marketplace to install them from directly. But my main point is that most users are not likely going to have to build these kind of widgets on their own (though they are welcome to) so they are not really out of reach for most users.

So part of me is wondering if we are potentially heading down the wrong path. It might be better to make custom layout pages and custom widgets be what we should encourage to be use to address this instead of mucking around with the Equipments tab to really only half address the root problem, end user usability.

[sirupflex]

Many thanks for your input @rkoshak

1. I think is a good idea and I've seen several request for just this ability. Additional use cases, which will require working with the phone apps, are to have a the choice of a different default page on the apps from the default page for the browser.

Happy to hear and also makes sense to me.

2. I'd make this idea finer. I think it would be more flexible and address more user's use cases if they could reuse the cards from the Locations, Equipment, and Properties pages. Alternatively, making the basic card structure used there available as a base widget we can populate.

Sounds good to me too and if there are reasons to rather go alternative ways as you described, I'd be pretty happy as well.

Then the questions become:

• Why is the heat pump a part of the model at all?
• If it makes sense to have them in the model, why are the controls for the heat pump not hidden from regular users so only you as the administrator see them?

It is far better IMO to simply not show stuff to the "end users" at all than it is to move it to some "don't click here" section of the UI.

It shall be shown because I am a user as well and I want and need to see it. But it shall be shown in a context that matches the "family experience", which means they shall not be displayed together. In addition, because I am also a user, I don't want to completely hide it otherwise I need to start looking for things at very different locations and cannot really benefit from the Equipment page any more.

And you can control whether or not controls show up using the visibility and visible to properties of the widgets.

I am doing this already heavily to only show the most relavant items and to hide additional fields based on the context (if the washing machine is "off", no need to show the "elapsed time" field, etc.). This has nothing to do, however, with the grouping of equipment.

Here is where I start to have a little bit of heart burn. The Equipment tab is supposed to reflect the model. If we start to break stuff out and show stuff in a way that is not part of the model we pretty much lose that.

If I may be so open, I think this was an approach that does not work out in real life. The Equipment tab is not the admin tab to check the semantic model. For that you have the "Model" page in the Settings. The Equipment tab has to be the place where non-IT family users find the equipment that they know from the house in a way they expect based on their own use case. And this use case and "family experience logic" is different from the semantic model. So I recommend to give up that thought that the Equipment tab needs to reflect the semantic model. It can be based on the sematic model but finally shall reflect visually the Equipments in the users house in a way that makes sense to the user.

And for the end users, based on my own experience and what I've seen on the forums, only the Locations tab ends up being used a lot. The Equipment page largely gets replaced by a custom built Page(s) with custom widgets that unify the controls for something in a more intuitive way.

I understand and I also built my own pages to handle some equipment in daily usage. Still, the big benefit of the Equipment tab is that it is just there. An easy way to also quickly check through some of the equipment. And it is a beneficial effect of the sematic model, even with my wish to adjust the visual grouping in a custom way. I simply like it. I also agree, however, that the effort (development and maintenance) to allow further customization here has to be in a fair relation to the added value. Only the developers can comment on the effort, of course.

More and more of these reusable example custom widgets to accomplish these unified complicated display and controls which are much more intuitive are being posted to the forum. ... So part of me is wondering if we are potentially heading down the wrong path. It might be better to make custom layout pages and custom widgets be what we should encourage to be use to address this instead of mucking around with the Equipments tab to really only half address the root problem, end user usability.

This is indeed a valid point. I just recently started to check out the custom widgets and am at the beginning of the learning curve. I love the possibilities and would like to build my own, but have no clue yet how to do it (will start reading your examples, etc. as soon as I find a moment).

The only difference is that for custom items / pages you need to manually do it while the Equipement tab does it for you, so to speak. It is a bit like the difference between manually creating a nice list with 10 lights on it versus having the feature to say "show me all lights here" and it automatically does it, no matter if you have 5 lights or 10 lights or when you just bought a new light it will just be there without manual intervention (once it is in the semantic model).

As a conclusion on this point from my side: Custom pages / widgets vs. Equipment tab is not necessarily addressing exactly the same thing. If you tell me, however, that there is limited bandwidth (and there always is) and I would need to choose whether the effort shall go into giving users more flexible custom pages & custom widgets (i.e. giving users more flexibility and features to design your own page and your own widget), or the effort shall go into enhancing the Equipment tab, then I would fully agree to use the bandwidth for even better custom page features / flexibility (and widgets as well).

[rkoshak]

It shall be shown because I am a user as well and I want and need to see it. But it shall be shown in a context that matches the "family experience", which means they shall not be displayed together. In addition, because I am also a user, I don't want to completely hide it otherwise I need to start looking for things at very different locations and cannot really benefit from the Equipment page any more.

Maybe we are misunderstanding each other. Each user is given a role. When there is no authentication provided, the role is assumed to be a basic user role. Unless you've created two users for yourself, your login has the administration role. Different widgets can be shown or hidden based on the users role. So you can hide those Items that are are only relevant to you. and not the rest of the family.

The Equipment tab has to be the place where non-IT family users find the equipment that they know from the house in a way they expect based on their own use case.

And I think that my argument can be distilled down to that the Equipment tab cannot service this function and still be mostly automatically generated from the model. If it cannot be automatically generated from the model then it cannot be auto-generated at all, it mostly needs to be built by hand. Therefore the better approach would be to provide the ability to create/reuse some of those auto-generated cards in other locations that can be fully customized and make it easier to insert your own layout cards into the default page and some of the other suggestions made here.

In other words, instead of going through all sorts of gymnastics to make the Equipment tab work, offer the option to hide it (which already exists) and let users create their own Equipment tab with the ability to use some of the same widgets as appear on the equipment tab, but with the ability better control what appears in which card. And except for that last part, MainUI already supports this.

Furthermore, what's done to the Equipment tab is going to be expected to be possible on the Locations and Properties tab too. If you don't then immediately you'll have people demanding to be able to pull out the lights from a room and put them in their own card or pulling the temperature setpoints out of the temperature card so they are separate from the measurements.

By the time all is done, you'll have spent just as much time customizing the auto generated tabs as you would have spent building the tabs from scratch in the first place (using reusable custom widgets of course, and end up with an inferior UI page in the end despite all the effort.

Furthermore, once you've spent all the time customizing everything, the tabs really are not autogenerated any more meaning as you add and remove Items to the model later on, you'll have to edit the UI tabs. They can no longer correctly put everything where it needs to go since it has no way to know where you want them. So your "it's just there" essentially gets destroyed. It's no longer just there, it requires ongoing work to maintain. And since that is the case, what's the value of the tab at all over a blank layout page?

The only difference is that for custom items / pages you need to manually do it while the Equipment tab does it for you, so to speak. It is a bit like the difference between manually creating a nice list with 10 lights on it versus having the feature to say "show me all lights here" and it automatically does it, no matter if you have 5 lights or 10 lights or when you just bought a new light it will just be there without manual intervention (once it is in the semantic model).

This kind of leads me back to my "have your cake and eat it too" statement. We want it all the automatically generated yet we also want it all to be fully customizable. At what point is the effort involved to "fix" what was automatically generated as much or more than the effort it takes to build it from scratch? Especially if we can use the same cards as are used on the auto-generated pages, perhaps even prefilled with the lists of Items I'm wondering if it would be less work overall to just use a blank layout from the user's perspective, ignoring the work for actually implementing all this.

I'll close with a bit of a background on how custom widgets work because I fear you are under the false impression that it is actually a lot of work to use these custom widgets. If they are properly written with reuse in mind, they really are very easy to use. For example,

There you see a widget with a bunch of light switches on them. If you flip on "Tis the Season" a bunch more switches will appear. Naively one would think you would have to individually define each and every one of those Switches. But that's not the case. That whole widget is 43 lines of YAML and it build itself dynamically based on the tags from the model. It will show any Item with a Point/Property tag pair of Switch/Light and it only shows those with "Christmas" in the name when Tis The Season is on. But I don't expect most users to be able to create this widget and they don't have to. They can copy the code from my example and just use it. https://community.openhab.org/t/a-couple-of-simple-oh-repeater-examples/116818 They don't even need to set properties.

That Chromecast widget I showed above has just two parameters to configure it for use (assuming one created their Items with the default naming scheme). One property is the title for the widget and the other is the prefix for the Items. Based on the prefix it finds all 10 relevant Items to use in the widget automatically. So again, use of a widget like this is just a matter of installing the custom widget, dropping it on a layout page, and setting two properties.

I think it's important for me to note that I'm assuming, and not without reason, that the number of custom widgets that will be come available will continue to grow so for most users it will only rarely be the case that they actually have to create a custom widget of their own. They will mostly be using something created by others in which case they'll only need to set a couple of properties to configure them.

[sirupflex]

@rkoshak May I be very open with you? Your long posting creates the perception on my side that you do not really try to understand my requirements. You just want to explain to me why my requirements are wrong and that you know better what is good for me. As I wrote elsewhere, I'm an IT project manager for more than 20 years, and the absolut very worst thing you can do is to think you can tell your customers what they need instead of listening to the customer. You clearly haven't listened to what I said and your explanations did not address my needs for the Equipment tab at all.

My proposal for the Equipement tab would make sense to me and it would address my needs, even if you don't see it. I'm not saying that it is worth the effort doing it, but this doesn't change the fact that it would add value for me. It is okay to tell me that you don't see the value for yourself and as a developer it would not be worth the effort. It is futile, however, to try to tell me that I'm "wrong" or that it does not make sense to have a "customized automated tab" just because you don't see the value yourself. It makes sense to me and it would address my needs.

You would have better focused your energy on the second part of my posting where I basically agreed with you that for OpenHAB it would be most likely of more value to spend effort on increasing the flexibility of pages and widgets instead of improving the Equipment tab.

I also do not understand why you wrote "I fear you are under the false impression that it is actually a lot of work to use these custom widgets". I guess once more you didn't really read what I wrote. I didn't talk about "using" the widgets. I said that I want to create my own widget and that this will be some effort to understand how they are built. With the great possibilities that widgets seem to offer, it is worth for me to dig into it so I can create my own, especially tailored to my needs. I already have a specific use case for it (a "timer widget" for the air conditioner, and I need 8 timers, so having a compact widget template for that would be great).

While I very much appreciate that you take the time to respond and to explain, it is a bit frustrating to read your responses because it's obvious that you didn't carefully read what I wrote. Also, to say it that way, it does not add value to try to prove you are right just for the sake of being right, especially when it is not about "right" or "wrong" but about individual needs.

Let's better focus constructively on what we seem to agree, i.e. how can we make even better use of the great pages and widgets concept that OpenHAB 3 offers :)

[rkoshak]

@rkoshak May I be very open with you? You long posting creates the perception on my side that you do not really try to understand my requirements. You just want to explain to me why my requirements are wrong and that you know better what is good for me. As I wrote elsewhere, I'm an IT project manager for more than 20 years, and the absolut very worst thing you can do is to think you can tell your customers what they need instead of listening to the customer. You clearly haven't listened to what I said and your explanations did not address my needs for the Equipment tab at all.

I'm trying to present alternative approaches and to take consideration of the impacts to the code, impacts to the users, impacts to the docs, etc. I do not disagree that the Equipment tab needs to be made more functional. Where I disagree is whether the Equipment tab should be enhanced with so many customization options (and for consistency sake the other two tabs as well) that it essentially just becomes a generic Layout page with some stuff from the model thrown on as a starting point.

My proposal for the Equipement tab would make sense to me and it would address my needs

And I think there are better alternatives that could be possible that are less disruptive, more consistent with the rest of the OH UI, and will have a better all around user experience. If you like the Equipment tab but now how stuff is grouped there, I'm trying to get you that. My problem isn't with what you are trying to achieve, it's in the how. I'd rather see a way to build the Equipment tab from scratch, using the same automatically generated card widgets with a minimum of fuss and effort than what will end up being a form with 20 options to choose from and Item metadata scattered throughout the hundreds of Items.

My disagreeing with your proposed solution doesn't mean I don't understand it nor does it mean I don't think the need is there.

I also do not understand why you wrote "I fear you are under the false impression that it is actually a lot of work to use these custom widgets". I guess once more you didn't really read what I wrote. I didn't talk about "using" the widgets. I said that I want to create my own widget and that this will be some effort to understand how they are built.

Frankly, because creating widgets is orthogonal to this discussion. Creating new widgets is going to be more work than configuring something that already exists. Therefore comparing the effort to create a new custom widget to the effort required to configure the Equipments tab exactly how you want is an apples to oranges comparison. A more apt comparison is the effort to configure the Equipments tab and to configure already created custom widgets.

But if you feel we are talking past each other, I think I've said all I need to here and saying any more will just be repetitive. To summarize:

• The work of adding too much customization to the Equipments tab would better be spent in making the cards that appear on the Equipment tab available to be used in any layout Page. Then if what the model produces doesn't suffice, one can can build an alternative that does suffice without too much work or trouble.
  1. Users should have more choice in selecting the default page that is shown when first logging in.
  2. Users should have the ability to add-to, reorder, remove/hide the tabs on the Overview page, or have the ability to define their own Overview page that can reuse the autogenerated cards.
  3. With 1 and 2, it should be as easy/simple for a user to replace the Equipment tab with one of their own liking with far more freedom to build it to be exactly what they want than it would be to add a bunch of customization options to the Equipment tab.

I'll watch the topic with interest but refrain from commenting any more unless specifically asked a question.

As for the lengthy posts, that's how I write. To paraphrase Pascal, I don't have time to make it shorter.

[sirupflex]

I'd rather see a way to build the Equipment tab from scratch, using the same automatically generated card widgets with a minimum of fuss and effort than what will end up being a form with 20 options to choose from and Item metadata scattered throughout the hundreds of Items.

No problem, I understand the reasons why my suggestion does not fit into the OpenHAB architecture. Your suggestion is fine with me as well and it would be great to get some flexibility similar to what you described. So consider us aligned on this point.

Frankly, because creating widgets is orthogonal to this discussion. Creating new widgets is going to be more work than configuring something that already exists. Therefore comparing the effort to create a new custom widget to the effort required to configure the Equipments tab exactly how you want is an apples to oranges comparison.

Sorry, here you completely lost me again. Nobody compared the effort of custom widget creation vs. Equipment tab. It is two very different things. I just said that if you, i.e. the OpenHAB developers, need to set priorities on where to spend the effort for tool improvements (and you always need to set priorities), then I agree that the developers shall spend it rather on enhancing the flexiblity and features of custom pages and custom widgets for end-users. This adds more value to OpenHAB and the overall user community, in my opinion, than spending the effort in enhancing the Equipment tab in the way I originally suggested. So, again, here we agree, but I think you missed it ;)

As for the lengthy posts, that's how I write. To paraphrase Pascal, I don't have time to make it shorter.

So you rather expect that everyone who reads in this thread has to spend the time on your lengthy answers because you don't want to spend the time to read responses more dilligently and to be more precise in your responses. Uh, okay.

[rkoshak]

So you rather expect that everyone who reads in this thread has to spend the time on your lengthy answers because you don't want to spend the time to read responses more dilligently and to be more precise in your responses. Uh, okay.

I read and understood everything you wrote. I don't know that you did the same. But I can not post at all. Sorry to have wasted your and everyone else's time. It won't happen again on this thread.