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:
- From a user’s perspective there are too many options and it is hard to understand, which UI to use for what.
- Technologically, we have a big zoo of different frameworks and usually only zero to one maintainers who know how to use them.
- Our goal should be:
- to have a single (web) UI, which guides the user through the features
- to have a modern technology stack for which we have a team of capable people that can work on the UI code base.
- to make it easy for new developers to join in, so the stack should not be too complex to get into.
Therefore, in an unanimous decision, it has agreed on the following:
openHAB (3) should have a single Web UI that can be used for all administration tasks as well as for “normal” operation, thus combining the features of the current Classic/Basic UI with the Paper UI + HABmin as well as of the current Dashboard.
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.