I would like to discuss a couple of aspects regarding the design (architecture) of the way the User Interface/Frontend output can be configured in OH3. Although I raise several issues below, please regard this post as a starting point for discussion and for finding solution for issues I (and probably others) have when using OH3. I highly appreciate the great work @ysc and many others have put into making the new release happen!
As a background information: I consider myself as a OH(2) PowerUser who is able and willing to spend many hours/days on configuration, can write extensive and advanced rules, is able to tweak CSS and understand code; I am not a developer who can write full (web applications), but have a good understanding of software architecture and a passion for user experience.
Moving OH3 UI to the next level by using state-of the art frameworks like vue.js and Framework7 (F7), support for creating reusable Custom widgets etc. was definitely the right thing to do. When I saw the presentation in the Openhab Virtual meetup, I was blown away
After I have now tried out OH3 myself and spent more than a full week on getting familiar with the new UI capabilities, I must say I am quite disappointed. I get the impression that many, many new features got implemented, but we missed to get the basics working properly first. I still can see the potential (and some minor things will get fixed over time as usual), but by now I have the feeling that some fundamental aspects are wrong.
Here is my point of view of what does not seem to be right:
1. Blackbox Predefined widgets limit possibilities:
It is mandatory to use certain oh-… widgets and to use them in a certain structure (e.g. rows/cols, cells etc.) which influence (HTML-)structure, design and behaviour. Some aspects of them can be overrriden, but by far not all.
Also, the Predefined widgets are not available as (yaml) source so that they could be used as template and modified according to the user’s needs.
Overall, it is easy to get a first UI with several widgets quickly, but if you seriously think about what’s good UX, you immediatly run into limitations.
2. “Hardcoded” Styles
index.html, Framework7 CSS and JS are hardcoded in OH UI bundle. As a result, there is no easy and reliable way for custom/additional styling or CSS tweaks. Also F7 Plugins might de desirable, but can’t be used.
3. Inline Styles everywhere
Due to the missing option to change the F7 CSS, people start to put all kinds of inline-styles in custom widgets, which is not a good basis to keep your app maintainable or even for exchanging widgets among users.
4. No documentation available
There is no documentation available even explaining the basics (Purpose of available OH Widgets, Layout examples, which way of nesting of components is allowed). I know and highly appreciate the forum thread [wiki] Building Pages in the OH3 UI: documentation draft but I think even when its finalized, this is not sufficient. Rather than developing new UI features I think we should prioritize creating a proper documentation thats suits a major release like OH3.
5. No possibility of UI debugging
Many changes in the YAML lead to blank pages or widgets. In such cases, there are no error messages in the UI or OH logfile (even on loglevel DEBUG). That, combined with a non-existant documentation, makes UI development a rather nerv-wracking exercise.
6. No editing of pages and widgets outside OH Admin UI
The built-in YAML Editor is OK for a few basic changes, but overall it is not very developer friendly and IMHO not suited for larger, more complex layouts. Would be great to use an external editor like VS Code (with Code validation through LSP).
7. No Code versioning
Even more important: there is no way of code-versioning for pages and widgets. No rollback whatsoever possible (except for JSONDB file backup). In OH, I simply use git to version-control all my sitemap, thing, items etc.
8. Limitations/Flaws in using F7, Predefined or Custom widgets, e.g.
- broken f7 components: e.g. try to put a “media” slot inside a f7-list-item component (it does not appear in the HTML output)
- when adding a widget “from model” the widget that is set in the item configuration is used. Any later changes in the item configuration regarding the default widget are not reflected in the UI
- Nesting of Custom Widgets does not seem to be possible (e.g. custom f7-list, into which custom f7-list-items can be added in the visual editor or in yaml code)
- UI styling out of the box not consistent (Cells vs. Cards)
- When using an oh-list-item in a custom widget, the properties of the widget cannot be edited on a page (but only the configuration of the underlying oh-list-item), partly defeating the purpose of a reusable design component.
9. No Demo/Template UI
There does not seem to be templates for pages and Predefined widgets showing all design possibilities of the new UI (except that the demo on www.openhab.org has been relaunched just lately), similar to the F/ reference and Kitchensink. I am wondering how the Predefined widgets have been tested during development (I guess a visual check of all possible configurations of widgets is needed here as well).
10. Insufficient iPhone UI
(same probably applies to Android - not tested). I believe that this problem derives from F7, since there does not seem to be a way to control a flexbox behaviour for displays smaller that 480px wide (e.g. iPhoneX). The result is that if you have a oh-grid-row with multiple oh-grid-cols containing e.g. Listcards (which is fine to be displayed side-by-side on tablet), you can’t have the cols/Listcards wrap underneath each other with 100% width on an iPhone. The only way out seems to be creating separate pages for tables and phones, which does not make sense in a Responsive SPA.
According to the new docs, you can set attributes to control the default width, and for other screensizes (xsmall, small etc.). This seems to be OK (however, it would have been simpler to use the (already documented and working) f7 CSS classes ( rather than encapsulating this with OH-specific parameters).
On another note, landscape mode is currently not well designed (too large paddings/safe areas).
11. Too many abstraction layers creating complexity
Editing in an abstraction layer (OH-specific yaml) (which gets stored as JSON internally) of an abstraction layer (oh-specific widget structure) of an abstraction layer (vue components) of an abstraction layer (F7 components) that creates HTML/CSS/JS does not “feel” right. At least you can see the limitiations and flaws that get introduced with each additional layer when working with pages and widgets.
As I stated in the beginning, I am not a developer myself, so I can’t make proper suggestions for solutions. But wouldn’t it be possible to use a more standard-oriented approach in the sense that
- Pages and (even more important) Custom widgets are created using “vanilla” Vue/F7 components (for which already a good documentation is available)
- Keep all customization options from the underlying Vue/F7 frameworks (at least design options like app.css) available and unchanged
- OH core provides a method for data-binding the vanilla components (similar to the “props” approach)
- OH comes with predefined Widget templates, which can be used as-is by entry-level users, but also be changed by advanced users