Closed ghys closed 4 years ago
FWIW, I think it makes a lot of sense to keep the used web technologies in openHAB limited. As we already have HABot and our website being based on Vue.js, this sounds indeed like the most natural choice - but I am no JS/web developer myself, so take my opinion with a grain of salt.
Alright, here's my suggestions to kick off the discussion:
I have nothing against TypeScript, I made a project with it 2 years ago, and it can really be a good tool to improve the code's quality and robustness. I'm sure it will probably gain more and more traction... but for now, it's one more language to be proficient in... This could reduce the pool of our potiential contributors significantly. I'd stay with regular ES6 for now. @kubawolanin you made the VS Code extension and have probably the most experience with it, comments from your side would be valued ;)
Vue.js, obviously ;) As @kaikreuzer said HABot, Home Builder and the website are already done with it and it's a very good and safe choice - it's also the easiest of the three to learn
I'll get back to it when I'll discuss the component frameworks, and already mentioned it in the question (😆) but I believe we should start the app with the tool provided by the framework we'll choose for 10. which will get us a well-organized skeleton, and iterate on that. External librairies should be added as npm dependencies as a rule, never copied into the codebase; we can and will probably however have to add a few more things but it should imho be limited - Pages in the pages
folder, components in the components
folder, and try to build a folder hierarchy which reflect the features of the app
(pages/settings/things/things-list, pages/settings/things/things-details, components/sitemaps/widgets/generic, etc.)
A tough and maybe controversial one ;) The lack of semicolons in Standard might scare some developers away, but it seems to be popular with Vue projects (the previous Quasar used it as a default and I used it for HABot, it was fine, really), the coding style of choice for official Vue projects like VuePress is also Standard. I'd go with Standard, but again Airbnb is perfectly fine too.
I like Stylus more and more, speeds up development, it's also popular with Vue projects. SASS/SCSS needs Ruby or libsass (I had npm recompile it sometimes while working on HABPanel...).
Webpack, yes, it's the standard now
In my view it would be a mistake to offer a desktop-only experience - Basic UI and Paper UI were designed to be used on mobile too and most day-to-day operations, including configuration, can be done with a well designed mobile-friendly app.
There are a number of challenges to overcome, but I would try to aim for it. Both framework presented below (Quasar and Framework7) offer the option, are ready for it (I tried with good results), and it would be really interesting to have a nice packaged app full screen on your iPhone or iPad - two incredibly popular device choices if we look at the website's analytics - with the same features as the web app, but without the browser. I believe it can really be done, so let's keep our options open!
We can restrict ourselves to Material Design but if we're looking to do a hybrid Cordova app for iOS, I would try to skin it according to the OS's guidelines - it would feel less "native" to have a Material Design app on iOS.
The toughest decision by far. I have tried both Quasar v1 beta and Framework7 and I've been impressed by both. Feature-wise they're almost the same, beside, the structure of the skeleton apps built using their respective CLIs (https://v1.quasar-framework.org/start/quasar-cli, https://framework7.io/cli/) are almost the same, so switching from one to the other, at least at an early stage, could actually be possible. Quasar seems to be the more popular option in the Vue community, makes more opinionated choices, and has the better integrations with Vue and HABot was done with it (the previous version), but I must say I've been really impressed by f7's attention to detail - I have spent a few hours on a prototype with f7 and have migrated one page to a Quasar app to evaluate both, I'll share my thoughts later - and some of its components (Smart Select and some others) are simply brilliant and would be a great help to design screens like item pickers that work well. Quasar's previous version had an iOS theme but for v1 they're only targeting Material Design, f7 offers both (and potentially a desktop theme in the future). In a nutshell, while I really like Quasar, today f7 would have my preference.
a. Axios is great. f7 has its own request library, which could be enough. Both really are fine and would probably be abstracted by a wrapping for our use b. Vuex c. I don't consider i18n/l20n to be a priority right now, but we shouldn't code our way out of it. vue-i18n is the safest and a good choice d. echarts - it's great e. Leaflet probably
No opinion right now, it can probably be done with some v-if
directives and results of API calls in the Vuex store.
I'll give an in-depth comparison of Quasar and Framework7 in a future post.
Some small additions:
d. Another option: d3.js e. Do we need an extra map library give that both echarts and d3.js support basic mapping features?
Vuetify ... great !
👍 @ghys sounds great
Totally agree, its one more language we really don't need with your proposed ecosystem
As a IOS user primarily, I think this is a noble goal, and if it's within the framework, then let's support it. However, if you find a framework that is material focused, but makes our lives that much easier and delivers a great UI/UX experience, then i can live with material design on my iphone. So many apps are now using their own look and feel on IOS i'm not sure who's following Apple's style guide anymore.
Thanks again for this @ghys, this sounds really promising.
Just my 2 cents:
When considering VueJS, please take a look at Nativescript VueJS. If you design the UI right, you don't need a Cordova hybrid app, but can release a native app.
Greetz
Secure by design - https only.
should we consider TypeScript
I'm sure it will probably gain more and more traction... but for now, it's one more language to be proficient in... This could reduce the pool of our potiential contributors significantly. I'd stay with regular ES6 for now. @kubawolanin you made the VS Code extension and have probably the most experience with it, comments from your side would be valued ;)
I agree with your reasoning. While it's a great language that takes all the goodness from JS and adds strong typing on top of it, I think it would make contributions reduced because of a little bit steeper learning curve than plain ES6 and beyond.
I would really love to see some tests, though. UIs are vulnerable to all kinds of (visual) regressions. A strong testing frameworks integrated into the project are something that would ensure quality on different levels.
This is why I'm more leaning towards Quasar. Its Testing monorepo has everything preconfigured right our of the box. You get Cypress, Jest, Lighhouse and more - everything nicely packed and ready to go.
More docs on that can be found here.
11. The libraries we settle on for:
Not sure if Quasar or f7 comes with something alike, but I would add date-fns to the collection. Lightweight alternative to moment.js. We really need relative time support in the new UI ;-)
Can't personally vouch for it but have read about Day.Js as an alternative
⏰ Day.js 2KB immutable date library alternative to Moment.js with the same modern API
https://github.com/iamkun/dayjs
reference: moment/moment#2373 (comment)
Vuetify
Vuetify was on my mind of course, I feel it's lagging behind esp. Quasar now.
When considering VueJS, please take a look at Nativescript VueJS. If you design the UI right, you don't need a Cordova hybrid app, but can release a native app.
I like NativeScript, have done a prototype for a customer (but with Angular), even if we find a project template to build both a webapp and NativeScript apps with the same code I'm afraid we won't have the development power to maintain both versions of the UX, even if we could share some code. Today's web frameworks and devices are IMHO fast enough to make a Cordova app "good enough". Good suggestion though.
Not sure if Quasar or f7 comes with something alike, but I would add date-fns to the collection. Lightweight alternative to moment.js.
agreed! 😄 Moment.js is bloated! Day.js is interesting as well.
So I have continued to evaluate Framework7 but have also ported part of the same app to Quasar 1.0 beta for the sake of comparison, and just made public the 2 repos I made with both prototypes, there are also releases you can try on your instances and deployed demos:
Framework7 Version | Quasar version | |
---|---|---|
Repo | https://github.com/ghys/openhab-ui-f7 | https://github.com/ghys/openhab-ui-quasar |
Release | link (web+Cordova APK/IPA) | link (web) |
Demo | https://habot-demo.azurewebsites.net | https://habot-demo.azurewebsites.net/quasar/ |
(note: I haven't reimplemented all features in the Quasar version, just a few screens - sitemaps, settings menu, things/items lists w/o details, addons, service configuration - the goal was to get a feeling of the framework with an app as scaffolded by the official CLI vs. the same with f7). (note2: this is NOT good code so don't look at it too much 😆 - some things have not been migrated to a common API and most of the API calls should be migrated to real state manangement with a Vuex store, which doesn't exist yet!)
Here are some thoughts:
Both apps scaffolded with the frameworks' CLI have roughly the same structure modeled after Vue-CLI, offer a webpack-based config and a development server with hot module reloading. Quasar abstracts away all the webpack wiring with a custom configuration file (quasar.conf.js) and plugins - which also helps with the treeshaking which is the standard, all used components must be added to that file, while Framework7 is more "bare-bones" with a standard webpack config and includes a bundle with the whole framework by default (treeshaking is however also possible). Compilation or linting errors should they occur are also displayed on an overlay over the app on Quasar, this is a nice touch while not really that useful. As Kuba said, Quasar offers some plugins for installing and integrating testing tools, which we should (😏) use - jest & Cypress could also probably be integrated in the f7 app manually, albeit in a much less convenient way.
Overall, while I had a pleasant experience with both (hot reloading etc.), clearly with its bold choices, sensible defaults and great tooling Quasar is a step above in this area.
Again both frameworks offer a wide range of functionality, but as you can imagine the devil is in the details ;) Quasar is a Vue-only framework so it respects the Vue overall philosophy best (v-model
etc.), while Framework7 is a pure JS framework with Vue/React wrappers on top. Still, they are sensibly similar and make good use of features like slots, events. Mostly redeveloping a single-file component or page for the other framework is often a matter of changing the <template>
section.
You can find the usual suspects in both, inputs, modals, swipers, sliders and toggles, which work well. Quasar has more CSS classes for styling & positioning and some interesting utility modules. That being said, f7 has more components that inspired me, in particular for displaying, searching or picking an item out of potentially large lists - a very common scenario in our case, think item pickers and the like. I'm not saying it would be impossible to bring the same UX quality by redeveloping some custom equivalents with Quasar, but that defeats the purpose and what's on offer out of the box felt inferior IMHO to f7 in some many regards.
I have also a good feeling about the timeline, sortable list (for ordering rule modules), stepper (for setpoints in sitemaps) and the timeline (both vertical for events and horizontal/calendar for scheduling). Quasar however notably has a knob, builtin support for more iconsets especially MDI and can deal with multiple layouts within the same app.
Overall, I would still say Framework7 wins here.
A very subjective topic... while the app Quasar feels lighter (perhaps due to the code size and the lack of transitions and animations by default), the f7 app feels more "fluid", "smooth" and modern in my opinion, it mimics the look & feel and transitions of Android & iOS nearly perfectly. Having a good quality UX could be in my view a key differentiator to make openHAB appealing to more users, so I'd say we have to take this very important factor into account. For example, using a f7 Smart Select popup in https://habot-demo.azurewebsites.net/#!/settings/services/org.eclipse.smarthome.core.i18nprovider vs. a QSelect in https://habot-demo.azurewebsites.net/quasar/#/settings/services/org.eclipse.smarthome.core.i18nprovider for the region/language/timezone makes a big difference, especially on smaller screens. Having a good "native" feeling on iOS devices too is a differentiator, not only another "generic" (!) Material Design app which we can see everywhere now - especially since both frameworks can build fullscreen apps and that could become a nice way of interacting with openHAB.
To me, Framework7 wins here too.
Both documentation sites are well thought out, with Framework7 you sometimes have to deal with the core JS docs as well as the Vue.js components docs, the new Quasar docs are really well done, and the community on Discord and the forum is very friendly. Framework7 has an active Discourse although you might encounter some Russian ;) Both project leaders are friendly and available and fix bugs swiftly. Quasar is however more popular in the Vue community, so I'd say it might have an edge here.
--
In a nutshell, I think Quasar has the best development experience, and f7 the best feature set (at least for now) and the best look & feel. I'd say we should try to bring some of what Quasar offers with its tooling and its general "sensible defaults" approach to the f7 prototype and give it a shot, so we could get the best of both worlds - IMHO it's easier to port some configuration from Quasar to f7 than components from f7 to Quasar. I don't expect we'll hit a roadblock and if so, it's not too late to switch to Quasar (or Vuetify or another framework), like I said all non-UI related code could be reused - Vuex store etc.
Feedback appreciated as always, before @openhab/webui-maintainers can cast their vote ;)
I see a lot of 👍 here and no vetos or other suggestions, so I'd say: Go for a formal vote and start realising it!
Does this UI stuff in any mean fit to or contradict what @davidgraeff is piloting?
It is not related :) Competition is good for pushing each solution. As long as the OH core makes it easy to install other solutions it's a good idea to have a default one in place.
Not sure I can fully agree here as I see the primary value of open source in the way it fosters collaboration. Competition is something for commercial solutions... Furthermore, the main driver behind this effort was to reduce choices for users and not to end up having more doing very similar things.
I'd agree usually.
But here we have no choice. I fully disagree with Yannicks proposal and I think he is heading in the wrong direction. But I'm not involved in this repo or decisions taken here.
I'll advertise my solution to people that are interested.
@davidgraeff so what do You propose? Your next-gen UI is a replacement for basic UI and Paper UI and other UI's. You wrote many times that there should be one UI and now You are proposing that everyone should create their own UI. Yes, everyone can do that, that's the beauty of opensource. Currently, the development should focus on single UI, that will be the default one. As @kaikreuzer wrote, the new user should have everything installed without the need to pick the UI. Each UI will have cons and pros if You pick one something won't work, pick another and something else won't work or won't be available.
I'm not suggesting to drop development of Your UI, that's too much hard work to be throw away, but maybe try to settle on the technology and merge two UI's into one that will become the default one.
I'm not saying that one is better than other, colors, looks, animations, etc are a matter of individual preferences.
Try to think about what will be better for a new user. OpenHab is awesome, new fresh and unified UI will make it even better 😊
@Misiu You got a few things wrong here. I have never developed an UI that is capable of replacing all existing Web-UIs for control & setup of openHAB. I have developed a design study to find the shortcomings of openHABs API.
And I think Yannick did the planning wrong here, because he did not fix the messy REST API situation we have at the moment first. (I have written about this in detail in several community posts, if you are interested in details).
That means as soon as we start breaking for OH3 (which in my idea includes breaking the REST API to finally bring it back to a consistent state) the UI need adaptions all over the place.
Currently there is no mechanism in place to install UIs in an easy fashion. I'm discussing this in the core repo already. That's what I'm saying here, nothing more. I want it to be easy to install something else, because Yannicks solution will break down.
My personal opinion about this UI is a different topic and does not matter here. Briefly: I don't think this UI is suitable for "Configuring your smarthome" with all potential that OH includes. And there are no thoughts put into repo-management, user-management, security-management like I did in my design study.
Remember that I'm assuming that we remove .thing, .item files at some point (maybe exposing the internal database to user-editable files). So the UI MUST be capable of allowing the user to edit all kind of configurations via text interface, next to a graphical one, at all times. This UI here does not provide this advanced editing. And that's fine. You cannot have everything in one project. That's also what I'm saying, separation of concerns.
This is more of a control UI that allows a few configurations to be done on the way (like approving Inbox things etc). And I very much appreciate that this UI is developed, because all other projects in this repo apart from HaBot are absolutely outdated.
And I think Yannick did the planning wrong here, because he did not fix the messy REST API situation we have at the moment first. (I have written about this in detail in several community posts, if you are interested in details).
GitHub is perhaps the better venue for discussing technical matters, the forum is more suited to end user support and general community talk.
That means as soon as we start breaking for OH3 (which in my idea includes breaking the REST API to finally bring it back to a consistent state) the UI need adaptions all over the place.
I think the REST API is rather clean right now (being mostly RESTful, relatively well documented thanks to Swagger etc.) and actually a strength of openHAB compared to other open source home automation software I've seen. What are you referring to?
Currently there is no mechanism in place to install UIs in an easy fashion. I'm discussing this in the core repo already. That's what I'm saying here, nothing more. I want it to be easy to install something else, because Yannicks solution will break down.
Why the negativity? The whole point of this issue is as much trying to settle on a visually appealing look & feel for openHAB's UI to get that "wow" factor (I won't deny I still think it's important for the overall "reputation" of the project) as trying to rally potential developers around a common set of standards that will make the UI as easy as possible to develop in conjunction with the changes in the core and other areas. The easier it is to get into code-wise (so a well-organized folder structure, Vue's single file components and other niceties, a baseline components framework that's easy to grasp and actively developed and a test infrastructure will help a lot here), the less likely it is to "break" because more people will be able to make sure that doesn't happen. This isn't supposed to be a competing personal project, or a personal take on what openHAB should become like your design study, rather the way to develop the UI to guarantee it's viable as a mid-term "face" of the project as it is evolving as a collaborative effort. When changes in functionality to the core are agreed by all stakeholders after cross-team discussions, and then introduced, I don't see why the UI wouldn't follow suit.
Regarding the installation of other UIs and functionality, that's another strength of openHAB, they can be installed easily because of the add-on paradigm; it's not any more difficult than installing other kinds of add-ons like a binding or a persistence service. If you need specialized UIs like HABot, HABPanel or a more advanced administration UI (maybe something like https://github.com/hassio-addons/addon-vscode to edit configuration in a browser-based embedded VS Code, a Z-Wave network viewer, or your design study which might become "the new HABmin"?), it's already easy to install them. The goal is to let users have a basic experience they can already do much with, and let them discover and install more powerful UIs when their needs evolve.
Finally, I'll grant you that this project has a less ambitious goal to only become a more modern replacement for the Paper UI (+ a sitemap viewer), because its concept wasn't bad IMHO, it has only been outdated in terms of web development standards, so it's time for a fresh new take on it for openHAB 3.x as will probably happen again in a few years for 4.x.
And I'm very thankful for your UI.
they can be installed easily because of the add-on paradigm;
I have this discussion in core in the Issue about Extensions. I think java bundles are not the way to distribute webuis. tl;dr of that discussion (please head over for your valuable comments): I like npm to be an official ExtensionService for retrieving additional web-uis. That should attract frontend-developers.
I think the REST API is rather clean right now
In HabPanel you stored a big json blob as configuration value via the service. In HaBot you introduced the cards REST endpoint (with CRUD capabilities). Why didn't you add your cards interface to core? That is soo much cleaner than sitemaps.
I first considered that we should just have multiple endpoints for different kinds of UIs (cards vs panels etc). I rethought that. IMO a generic store-retrieve interface is the solution. So that UIs can apply whatever concept (cards, pages, sites, panels whatever) they uses and store/retrieve their data.
Because we would use a Registry
for storing (following the concept from above), that would even allow the user to configure his UI via a Yaml file, next to editing it via REST (with writeback), eg:
- habpanel#myFirstPage
name: Main Page
description: My main page for the living room
widgets:
- w1: ...
Swagger is nice, true. But in the end it tells you the same:
Now that I know the core code in detail (and after I spend some hours to modernize our current REST code via using the OSGi R7 whiteboard pattern, see the PR in core), I would remove all specific REST classes actually.
We automatically have a harmonized and consistent API if we create CRUD REST endpoints automatically for each Registry
(plus some hardcoded endpoints to retrieve the oh-version).
And yes I was also thinking about GraphQL and made a small proof of concept build. GraphQL allows "joins" and could allow a Setup&Maintenance UI to retrieve exactly the fields and cross references it requires.
In both cases the swagger/graphql documentation can be auto-generated if we annotate our registries (like "name", "description") and have our DTOs annotated.
Our REST interface is nothing more than what we call an "IO Service" in openHAB. Just like the Hue protocol or the HomeKit protocol that we offer for external services. If we auto-generate: That would happen in a single bundle very analogue to the mentioned bundles and not distributed all over the place in different bundles like it is now.
PS: I'm not subscribed to this topic, please reference me for responses, thanks :)
Thanks for your detailed breakdown of proposed changes in the core, that's very helpful and valuable. Cross-references and parallels to GraphDB are fair. (on a personal note, I must admit I have limited time to dedicate to active openHAB development these days but will follow these evolutions more closely).
In HabPanel you stored a big json blob as configuration value via the service. In HaBot you introduced the cards REST endpoint (with CRUD capabilities). Why didn't you add your cards interface to core? That is soo much cleaner than sitemaps.
HABPanel's storage was kind of an afterthought, it works but technically I'm not proud of it. With HABot it's cleaner but still too tightly tied to the frontend framework's capabilities (Quasar in this case) so it was a good call to keep it separate from the core at the time, Sitemaps have their problems but they're what we have and still a good concept for generic UI regardless of the underlying implementation. Your "generic store" idea for UI artifacts is very interesting though and it'd be very cool to have it come to fruition. It'll come in handy for the "card+minisitemap" idea I'd like to being forward eventually.
Off-topic, but for writeback or lack thereof in general - I've read the community threads - my preference would be the JSONDB to become the single source of truth then have something like Kubernetes' declarative configuration for the textual part i.e. "apply" your textual configuration (in YAML or even the current syntax with a custom parser so that the docs don't become obsolete overnight) with an API to send the file and ideally a similar command-line tool ("ohctl
" - maybe that could also be done in Karaf?). This would allow users to define their own folder&file structure for their textual configuration (by location, by type of equipment etc.) grouping the things, items and rules by domain if they wish. The UI could also offer a way to copy-paste and "apply" some ad-hoc configuration, like the k8s dashboard UI does. And it might even pave the way for tools like Helm equivalents, but for openHAB - basically packages that would include several objects (items, rules, persistence, you name it) to be configured for your specific configuration with a template syntax.
In the blog post of the 2.5 release I read the following: The existing UIs will be replaced by a single one, completely implemented from scratch.
This is great. But here I read from @ghys about the new UI proposed here (And which is seen as the new replacement UI, correct me if I'm wrong): Finally, I'll grant you that this project has a less ambitious goal to only become a more modern replacement for the Paper UI (+ a sitemap viewer), and in that same comment he referred to the user to install 'specialized UI's'. This seems to be different from having 1 UI to rule them all. My preference would also to have 1 UI or at least one entry point where possible different apps can be installed (like with hass.io, not like our dashboard) But such seems to be out-of-scope here and what would be needed to get such a UI? I'm currently professionally working with vue due to other projects and was fiddling with the openHAB API to get some more experience with it. So I might as well use that to help with the new UI. But maybe it should first be clear what we actual want with the new UI?
I think what @kaikreuzer meant in the blog post is that the UI will replace the 2.x "dashboard" with something which could handle the main use cases (day-to-day operation and administration, the latter behind some kind of protection), but it will also still offer the ability to launch other UIs if desired. It is not in the plans to deprecate HABPanel or HABot or the Swagger UI for the API, or even Basic UI.
Launching other UIs is less emphasized in the current design than in the current dashboard, it's hidden behind a button on the home page, but it still exists (the design can of course be discussed and changed):
Currently UIs are distributed as addons and can be installed like any other addon, and are responsible for registering a DashboardTile for themselves, and tiles linking to external programs can also be added to the dashboard by the OS (e.g. openHABian). If there's a viable and agreed upon alternative coming up, it could change, otherwise we would only need a REST endpoint to get the available tiles.
It is not in the plans to deprecate HABPanel or HABot or the Swagger UI for the API, or even Basic UI.
To be discussed to be honest and we already spoke about this a while ago. HABPanel uses a different technology and has its own ecosystem already, so this will have to stay. But HABot and Basic UI could be merged (and that would imho be very desirable) into the new UI. We said that as a prerequisite for this, we will definitely need role-based authorisation support ready.
Note that in the description of this issue you mention as (2) the feature parity with Classic/Basic UI 😎.
So I might as well use that to help with the new UI
@Hilbrand That would be excellent, because what we definitely want is to have a team of people being able to maintain the new UI!
It is not in the plans to deprecate HABPanel or HABot or the Swagger UI for the API, or even Basic UI.
To be discussed to be honest and we already spoke about this a while ago. HABPanel uses a different technology and has its own ecosystem already, so this will have to stay. But HABot and Basic UI could be merged (and that would imho be very desirable) into the new UI. We said that as a prerequisite for this, we will definitely need role-based authorisation support ready.
Note that in the description of this issue you mention as (2) the feature parity with Classic/Basic UI .
Yes l agree, HabPanel has its own ecosystem already but needs major overhaul. I have posted several TODO's https://github.com/openhab/org.openhab.ui.habpanel/issues/286 in the old repo. It still have inline styles in many areas, something in most organizations will simply not pass. There's not a single unit test, no linting rules, no public method documentation (JDoc, etc). The multi-language support was a headache, you need to know which key was previously used in what context. Kudos to @ghys , but these are some of the reasons I stopped developing for HabPanel as I used to, and simply refer people to my fork. I believe I still have some PRs in the old repo that were rejected because of coding styles.
I believe the biggest setback was that there's a single reviewer, a single person who approves PR. For that PR to get approved, you would need to please that single reviewer to the T.
I got to that page from @kaikreuzer OH 3.0 announcement and I found it very interesting. The addition of charts in the UI will be very useful.
One doubt I have is if the new UI will contemplate some extension system to display custom widgets. For example in the F8 demo application there's a Weather widget, will it be possible to create add-ons to support such features with complete custom rendering?
For example, I'm thinking about the small card library from HomeAssistant that is provided as an extension there. It will be very nice for me to be able to adapt it, and possibly a simple adaptor on top of its config parameters will do the job.
I hope this is the right place for adding wishes for openHAB 3 and the new UI. I am no developer and from the time line of openHAB development a fresh user with round about nine months of using openHAB 2.4 and 2.5. From one view, the text based setup was nice to grow a openHAB installation step by step and solve one problem after the other. But I run fast in limitations I did not know how to solve and for some things I found the message, that there is no solution.
Example 1 -> Basic UI and long text items. I use the binding from "DWD Deutscher Wetterdienst" and actual there are some warnings with additional information. The Basic UI and the openHAB iOS app can't show this text completely. Only in a browser it is shown as an mouse tool tip when I go over the item and the Paper UI shows this also. But here I had to much room definitions that the horizontal room list is not readable. So my wish for the new UI in openHAB 3 is a more flexible way to show (long) text on the web interface and also in the app.
Example 2 -> Definition of items from a binding. The DWD binding offers also a number if there is more then one warning. But items are defined in the text file. As the result there is no dynamic way to create items and there UI parts. In comparison to the other smart home project ioBroker they create in there database the "items" like they where fetched from the service. And the user has a more comfortable way over an GUI.
And this is the second wish for the new UI in openHAB 3. A more graphical way for creating rules. I tried out the Next Rule Engine in openHAB 2.5. But there are many problems with truncated text and it is not so intuitiv like the Blockly way in ioBroker. I saw that there is a Blockly in HABmin but also in the forum are some entries about non functionality in the actual version.
Example 3 -> reading and offering lists for users. A little bit frustrated I had the last days a look to Home Assistant and installed it in a virtual machine. It finds in second things like my Sonos Systems, offered a nice UI and added also a choosable list of our favorite radio stations without one click of programming and defining something.
Finally I must say, that I like certainly the way over text files, because of backing up before changes. But the best for the future would be a way that the UI creates the textfiles, changes would be possible over the ui and the files and the the inflexible display system in the Basic UI gives a way to a modern responsive UI.
Hi :-) I don't know of I'm in the right place here, but as Habmin ist already removed a long time, I wanted to ask the status of the new ui...Habmin was very usefull for Z-Wave devices...
@ghys I guess we can close this issue, since the new UI is established, fully functional and part of the openHAB 3 snapshot distro, right?
Agreed - on the new UI being feature-equivalent to HABmin, Paper UI and others, I believe good beta-testing will be crucial in identifying the major pain points so we will hopefully be confident of having a working replacement by the time openHAB 3.0 is released.
Context
(scroll down to the next separator line for the actual purpose of this issue)
The openHAB Architecture Council (@openhab/architecture-council), after some deliberation and having taken into account the many views expressed around Web UIs - including, but not limited to the several topics in the community forum - has reached the following conclusions:
Therefore, in an unanimous decision, it has agreed on the following:
Which means, in terms of functionality for this new app, it roughly translates into:
1. Dashboard feature parity:
a. Helping the user configure openHAB with a basic setup when starting it for the first time b. Presenting a list of the current "dashboard tiles" representing other UIs (and tools with a frontend) and offer a way to launch them
2. Basic/Classic UI feature parity:
a. Displaying sitemaps - updated in real-time and with all available controls
3. Paper UI feature parity:
a. Listing, installing, configuring and uninstalling add-ons (presented by type: bindings, actions, etc.) b. Configuring the services which have "config descriptions" c. Managing the Inbox and the discovery: starting a new scan (global or by binding), listing the inbox entries, ignoring/un-ignoring/deleting entries, promoting a discovery result to a full Thing d. Managing Things: create manually, list/search, enabling/disabling, delete; show details: configure settings, list channels, link/unlink items from/to a channel with an eventual Profile e. Managing Items: create, list/search, delete; show details: configure basic settings, assign groups, tags/semantics*, metadata, (linking to a Channel?)* _Note: tagging is not actually a feature Paper UI currently offers but it probably an oversight, so we can safely consider it already **Similarly, not a feature of the current Paper UI but defining a Link from the Item page may also make sense, so let's consider it too?_ f. Managing Rules (from the new automation engine a.k.a. "NGRE"): create, list, enable-disable, delete, run now; show details: manage triggers, conditions and actions (add, reorder, configure, delete)
4. Essential features from HABmin
a. Interactive chart display for persistence data b. Z-Wave network management: visualization, actions on nodes (heal, pair, unpair...).
(please let me know if I forgot something)
This is not a definitive list (having HABot and Home Builder reintegrated is on the roadmap as well), however, this is, in my view, the agreed set of functionality we should focus on before adding new ones, in order to achieve the goal stated above - merging the quintessential experience for the average openHAB user into a new "default" app which would appear in lieu of the current Dashboard. There are surely some unknowns about the future of some specific feature, whether it should be considered or not (firmware management, rule templates, Eclipse Marketplace?) or how it should be implemented/how close to the current look&feel it should be. Those would be addressed in additional, separate issues. Therefore, may I please ask for your understanding, and for the sake of keeping the debate here on topic: this issue is not another discussion venue for ideas of features the new default openHAB UI should have. There are multiple topics already opened for that purpose in the discussion forum, where everyone can take part - rest assured they are read and taken into consideration by the stakeholders here (@openhab/webui-maintainers).
The purpose of this issue is to reach an agreement on the technical aspects of the implementation of this new app, with a focus on trying to bring up a friendly and experience for potential new contributors, with as little barrier to entry as possible, namely we have to decide on the following:
The development language - Which flavor of Javascript, transpiling yes/no, and should we consider TypeScript?
The general-purpose framework choice - Angular, React, Polymer or (most likely ;)) Vue.js
The design patterns and overall architecture, folder structure etc. - which will depend on 2., for instance Vue has single file components and probably also on 10. below ;) I'd recommend we should stick to the best practices and tooling provided and maintained by these frameworks (most of them have a CLI to scaffold a new app in a standard, predictable way), to minimize custom code & headaches for new contributors;
The coding style - Standard or Airbnb. We should set up a linter and one of those two will be used as a basis. Additional recommendations welcome!
Which CSS preprocessor - LESS, SCSS, Stylus?
Webpack?
To what extent we focus on a great mobile experience (incl. phones and tablets) as well as the desktop - influences the choices below;
Whether or not we should consider building Cordova apps for iOS (mostly) and Android (possibly) with the Web UI's code (Android can "add to homescreen" with PWA features which are IMHO a must and shouldn't be up for debate). Note that this is not a push to replace the current native mobile apps for sitemap viewing, rather an interesting option we can keep in mind to bring the other features esp. the administration features to the mobile world;
What UI theme(s) we choose - a variant of Material Design is likely, it was already the choice for Basic UI and Paper UI, and it will fit desktops and Android very well but depending on the decision on 5. we may decide to provide an iOS theme as well;
An overall frontend framework covering at least Material Design - may also depend on 2. Examples include: Quasar, Framework7, Ionic, something else?
The libraries we settle on for: a. API calls and AJAX (Axios...) - the framework chosen in 10. might also provide one for us b. State management (Vuex, ngrx, Redux...) - depends on 2. and maybe 10. c. i18n/l20n - if we consider it at all - depends on 2. d. Charting: echarts (used in the HABot analyzer), chart.js, ... e. Maps: leaflet, ... f. Icons: Material Design Icons probably, the framework chosen in 9. might also provide additional sets... f. others, tbd... Minor library choices can be decided by the developer
(optional at this stage but still to keep in mind) How to plan the restriction of certain features to authorized users, which will obviously be influenced by the choices made in openhab-core (RBAC system of similar)
I'll offer my personal preferences in a separate post below this one, to make it clear they are not to be considered as the final choices. A word about the decision process: @openhab/webui-maintainers will be responsible for these choices and will make a final decision when there's a consensus on each of the above questions, according to the governance rules in place, with a possible escalation to @openhab/architecture-council only when necessary.