florian-h05
commented
1 year ago Closing as this is stale and MainUI is in place for some time now.
Closed ghys closed 1 year ago
florian-h05
commented
1 year ago Closing as this is stale and MainUI is in place for some time now.
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:
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:
"ui"or"card", could be used to drive the appearance of a card and/or details about their associated itemThe 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:
Other types of pages which could appear here as well;
(link to a separate tbd issue on storage for additional interactive page definition)