Merging the Web UIs

[kaikreuzer]

As a very first concrete proposal, I would like to come up with 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.

I would leave HABPanel + HABot out of scope as they are technologically&feature-wise quite different, although I’d hope that features from those UIs could slowly be migrated as well to a such a new UI.

A few motivations for this suggestion:

• 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.

Suggested resolution:

• remove Classic UI, Basic UI, Paper UI, HABmin and Dashboard
• create a new UI as a replacement
• (finally) implement role based authorisation, so that admin functionality can be hidden from users

Although it sounds pretty tough to implement a replacement for all those UIs, @ysc did a pretty convincing prototype a few weeks ago already, which makes me hope that it can be done. Likewise, David did some experiments with a Paper UI replacement 50, which also shows that there’s enough energy in the community to work on this.

Let me know what you think and whether you see any further things to discuss before going to vote!

[digitaldan]

That's a great start for sure, and I agree with all of it. One thing i will bing up is mobile support for such a UI. I think there are two concerns;

First is that it renders well on a mobile browser, this I think is required and probably not disputed.

The second is that the new UI be able to be deployed as a native/hybrid mobile application with something like Apache Cordova. I am not arguing for or against this last concern, only that we should weigh the pros and cons of it now. I have had mixed results with such an approach in the past, but having a single unified user experience does sound very appealing.

[rkoshak]

Yannick has had some promising results in deploying his prototype replacement UI as a Cordova app. But I'm hesitant to really go for that approach unless there are assurances that we will not be losing any functionality that we currently have in the mobile apps. Notifications is a big one but I know that the Android app supports other capabilities like voice commanding as well.

I completely agree that we need to reduce the number of UIs. I'm totally in favor of removing ClassicUI, BasicUI, PaperUI and the Dashboard. I'm in favor of removing HABmin pending support in the new UI for those things that only HABmin does right now, namely zwave and zigbee administering tools. There is already an issue open for that so I'm sure it will get addressed.

Does it have to be just one UI or could creating up to two UIs be a choice left to the developers whether it makes sense to split admin and user's UIs in two? On the forum thread some good arguments were made as to why it makes sense to split them and if the docs and presentation are handled well I don't see a usability problem nor a problem with too many choices.

How thorough of an RBAC are we talking about here. Two roles, user and admin, or are we going full out with the ability to define which Things or Items each Role has access to? I suspect the former but want to understand the scope. My primary concern is that the new user experience is relatively intuitive and seamless. If they have to go through a whole RBAC/ACL activity before they get a UI with a toggle switch to turn on/off a light I think we will have failed.

Is this too far down in the details and something for the devs to decide as they build it?

[ghys]

Here are some (maybe long overdue) thoughts from my side:

First, I think we all agree openHAB needs a great new "default" UI - the one users will be seeing when they click on the Demo button on the website, and the one they will see when they start openHAB for the first time. It is the "face" of the project, and a major selling point, so it has to look good and clean and appealing - it might sound frivolous, but I believe it really matters.

That's why choosing a good-looking as well as feature-packed frontend framework is paramount - I'm currently quite sold on Vue.js as the foundation and torn between https://v1.quasar-framework.org and https://framework7.io for the presentation, with a preference for the latter (mostly because of the iOS theme and some brilliant components), I can expand on the reasons in a later post, as I feel this one will already be a long one.

We must be careful about that choice, and obviously not bet on a dead horse - I know there are fears of merely choosing the framework "du jour", which will be obsoleted in a few years, to which I'll simply say... yes, the UI could have to be rebuilt again in 5 years. So what? That's web and frontend development for you, that's just how it is. Fighting it is missing out on the great things that are being done right now.

Next, that UI should cover the following use cases:

• the onboarding experience i.e. "first-time setup wizard" - the equivalent of the package selection in the current dashboard, with some more obvious basic settings like: set your language & region, your location, maybe choose a password for your first admin account when the auth/RBAC part is done, a few add-ons you know you'll need right away, etc. No need to provide them with walls of text or a complete tutorial, just clean, minimal, intuitive screens, like when you boot up your phone for the first time: you have a dead-simple, 4-5 step tutorial and then you at least have some essential options set - by the way, I'm against embedding some sort of "alternate documentation" in the app, just link to the docs on the website, they're here for that (and maintained separately), open them in a new tab/window so you don't lose where you are. However, to "finish" the onboarding experience, you could still show a quick card (like "Next steps" in the prototype) where you present actions new users would usually want to do after completing the setup wizard- including concrete stuff like "set up openHAB Cloud". You can design additional wizards for those or link to the relevant screens. Those "next steps suggestions" could be dismissed by the user or the system when they're not needed anymore.
• launching other UIs i.e. the current dashboard functionality - when this UI will be done, I believe nobody will miss Paper UI or HABmin ;), but I can see even Basic UI keep being relevant, if you need a no-frills, blazing fast experience to view your sitemaps. Then there's HABPanel, HABot, the REST docs, tools installed by openHABian like frontail... and an eventual and as of now imaginary "expert IDE" UI where you can do advanced configuration, make changes "en masse", design rules graphically etc. This expert UI would probably be out of scope for the mobile world and tailored for the desktop since you would need a keyboard and more screen real estate. Launching other UIs would not be the main use case I believe, if you're able to do much with this one, so they don't need to be front and center, just easily accessible. In my prototype, they're put in a hidden drawer you can pull with the button on the right side of the home page's title bar. I think there are better things to put on the default landing page/Home screen (need to think about what though, probably some contextual info and suggestions like you get on the left side page of the iPhone menu) than big "dumb" tiles for other UIs.
• "basic" configuration, like the ability to perform discovery, adding and configuring things, link channels, manage addons and configure services, basic "IFTTT-like" NGRE rules etc. - so you can do the full UI-driven journey from nothing to "I added a few things and hurray, they work together" with one app. If you compare to dedicated apps for like Philips Hue, you don't have one app for discovering and adding new lightbulbs and one app to control them - you have the one and only Hue app. openHAB has everything (discovery, a simple "inbox" paradigm, a good REST API) to be configured by a newbie (in certain conditions) even from a phone. And even for a non-newbie, just using my phone to put my Z-Wave dongle into pairing mode while I'm trying to pair a device in the basement is a valid and desirable use case.
  • A quick side note about the dual way of configuring things (and items): I don't have a miracle solution to solve this problem right now, but how about this: when you're about to do something that could also be done with textual configuration (add a new Thing, link a channel...), the UI would present you with a screen basically saying "Hey are you sure? By the way, expand this little widget and here's how you would do the same thing you're about to do with configuration files, just add this to a .things file and this to an .items file and cancel this." Just an idea now. If you look at the prototype and go a Thing page in the settings, you'll have a blue button in the lower-right corner to get the textual definition equivalent - maybe not an accurate one, I coded it in half an hour. I haven't thought about this too much TBH.
  • Of course, the "configuration" part should be put behind some authentication - could be RBAC, could even be a master password or even a PIN code which would get you a short-lived bearer token for the "danger zone" of the API if it's easier and quicker to implement... After all, why not? Most installations won't have HTTPS locally so security is a moot point anyway, and we're not exactly talking launch codes for nuclear warheads here.
• control: sadly that's the missing, and most important part of the "fully UI-driven" story, because you can't currently build sitemaps with the API. The default UI should IMHO however still be a sitemap viewer, since they're the established UI concept for openHAB and honestly, it's a good concept. But you can't edit them from the UI.
  • As an alternative and in an attempt to solve the above problem with minimal changes needed in the core, I'd like to explore the idea of having semantics automatically build a page hierarchy to browse your items. What I mean is you would have a "by location" entry point, a "by equipment" entry point, a "by property" entry point, and then it will automatically build a hierarchy (an automatic sitemap, if you will) driven by "isPartOf" relations, and group membership. For example, if you take the demo setup, "by location" would get you the floors, then the rooms, and direct equipments which are members of those locations by group membership. For one thing, it would give users some incentive to actually use the semantic tags, and who knows, it could end up being a decent way of browsing even larger configurations once they're properly semantically set up?
  • As I said in the forum I'd like to bring over the Analyzer window from HABot (https://community.openhab.org/t/habot-walkthrough-8-n-analyzing-historical-data/59878). It'll be a killer feature and works well on all form factors. Ideally it would be available when you view the "details" of any item that has persistence attached, but I don't know how to present that, esp. in sitemaps, right now. It would also be great if persistence strategies could be set up from the UI too, I don't know if it's feasible in the OH3 roadmap.

Finally, to address the "one UI for all" point Dan & Rich pointed out above, yes, I think especially for iOS where the webapp can't be installed as a PWA (and isn't as well maintained as the Android one), Cordova apps could make sense, so it's good that both Quasar and Framework7 allow that. You would get the same feature set, the admin/basic configuration functionality, the graphical analyzer, etc., push notifications could be handled too I think. That being said, I wouldn't want it to replace the native apps: we'll try to make a potential Cordova app perform great, and look great, but some users will still prefer the native app as a simple matter of feeling for certain cases (I know I will). Then we'll have to decide about how to call them (the default UI would become "openHAB" then what about the native apps? "openHAB Light" or? Would they have different icons? How to market them in the app stores?).

Here you have it, I'll follow up with a more technical perspective later, but that's it for now 😄

[digitaldan]

@rkoshak and @ghys all good points.

@ghys Couple things,

• as for UI frameworks, my criteria would be to use what has strong community support, good documentation and is not yesterdays technology. I am fine with what you suggest.
• You have brought up a lot of topics around the UI that would be great to fix, but i fear swallowing the elephant whole, how do we eat it one bite at a time? Should we map out the priorities and talk about what's important first? Since you have many thoughts, maybe you should give this a try ;-)
• You mentioned launching the other UI's from the new one which are in a hidden drawer. I'm guessing that we will be introducing yet another UI that will have to co-exist with the old ones for some period of time. I wonder if we could present a single, navigable interface that somehow includes bits of what we have until we can replace them? Just a thought. I'm not worried about the Swagger/Rest page or Habpanel (which i both use ), linking to those is fine as separate apps. I also don't have an understanding of how long it will take to build out the replacement parts.
• Hybrid mobile support I think is something we should not code ourselves out of, but i don't think we should be looking to replace our existing apps today. That said, i think having a cordova build (or equivalent framework) to play with as the app progresses would be great to have as an experiment to validate if it would be a suitable replacement.

@rkoshak

• I agree about removing the Classic UI, Dashboard and Habmin (once zwave functions are moved), BasicUI and Paper UI would need to have one to one replacements however to remove, correct? So we would need this new UI to support their current feature set?
• I'm not caught up yet about RBAC, i was on very old ESH issues around those at one time, but lost track of where support in the core is for this.

[kaikreuzer]

BasicUI and Paper UI would need to have one to one replacements however to remove, correct?

Yes, the new UI obviously needs admin & control features. Not necessarily 1:1 in functionality, but with features that don't let anybody miss anything important.

I'm not caught up yet about RBAC, i was on very old ESH issues around those at one time, but lost track of where support in the core is for this.

I have summarizes the state and open issues in #791.

Sounds as if we are all on the same page here and the discussion already goes into far to many (very good!) details for the moment.
What @ghys describes is also my vision: Effectively, we will have a "Web UI", which replaces the Dashboard - and this is the face of openHAB to the user. You can consider today's setup also as single modular UI: The Dashboard is the UI and it has sub components to which you can navigate. The issue is that all those components are based on different technologies, have duplicate features, etc., i.e. they give a bad UX.
We should get to a point where we have a technology stack, where someone that can work on admin features can also work on operation features - whether or not those two parts are kept as rather separate technical modules internally is not important for the decision here; but it should be a seamless experience to the user.
As @digitaldan said, I also believe that we should choose a technology where there's a high chance to find people jumping on it and contributing.

So let me now call for a vote:

• We deprecate Dashboard / Paper UI / HABmin / Classic UI
• The aim of the new UI should be to also replace Basic UI / HomeBuilder and HABot on the long run; I'd leave this open for now and leave it to how progress goes. But this should imho be our vision.

[digitaldan]

We deprecate Dashboard / Paper UI / HABmin / Classic UI
The aim of the new UI should be to also replace Basic UI / HomeBuilder and HABot on the long run; I'd leave this open for now and leave it to how progress goes. But this should imho be our vision.

👍 Good with this, what are the next steps? I know there are some very passionate opinions on the next generation UI on the forums :-)

[wborn]

It would be great to have a more unified UI that is maintained by everyone!
So I also vote in favor of Kai's proposal. 👍

In the long run I also think using the same (mobile optimized) UI in the Apps would greatly reduce the time spent on maintaining all Apps. It will probably also result in more UI contributors.

[rkoshak]

👍 I vote in favor of the proposal. I think it will clearly improve the user experience in many ways and hopefully it will make it easier on the devs to keep it maintained and improved over time.

[kaikreuzer]

Ok, cool. So if @ghys votes in favor as well, I'd think the further discussions should be driven by the @openhab/webui-maintainers, @ghys likely being the best one to lead it with his input given above already.
Imho what is required as a very first step is an agreement on the chosen technology whether be it Vue+Framework7 or anything else. @ghys Would you push this forward from here? Up to you whether you start in the webui maintainers team, as an issue in https://github.com/openhab/openhab-webui or even in the forum to maybe directly find developers that want to participate in the effort.

[ghys]

So if @ghys votes in favor as well

Yes, of course, it's in line with my proposals above, so I'm all for it ;)

Imho what is required as a very first step is an agreement on the chosen technology whether be it Vue+Framework7 or anything else.

Agreed, I wanted to a pro-con analysis of what I suggested above - Vue+Framework7 vs Vue+Quasar 1.0 (still in beta), I'm not against other proposals, so I'll open a new issue in the new repo this week - maybe along with a forum post - so that interested developers can voice their opinions. I remain convinced though that scaffolding the new web app with a set of frameworks that are well-documented (so new contributors can jump in more easily) and well-supported by strong communities, embracing their philosophy and guidelines and reducing the glue code in the codebase is the best choice.
Those frameworks may well go out of fashion eventually in a few years, as has happened with AngularJS (1.0) but that would only mean we'll have to yet again embark on a new UI rewrite for OH 4.0 - which is okay in my book, UIs need to be refreshed from time to time ;)

[digitaldan]

I think either is a good choice, but i think Vue+Quasar 1.0 has the most momentum from what i can see on the interwebs, so thats what i would start with. Very excited to see whats possible!

I think there might be some push back from a few in the community about using large frameworks like this at all, but I am not one of them. If you are going to expect to have multiple people contributing its better to have a well documented framework that enforces some consistency into how components and views are designed, vs re-inventing that wheel organically over time with no consistency or documentation. In the end, when someone want to contribute, it's easy for them to read up on how it works.

[digitaldan]

@ghys any updates?

[ghys]

@digitaldan sorry for the delay, I was both busy and sick these last few days ;)
I will definitely have more time in March.
As a starting point, this issue: openhab/openhab-webui#24 sets some IMHO objective rules for the debate to come, I'll expand with some subjective proposals later - you're welcome to give your opinions there or your feedback on the approach here ;)

[digitaldan]

Awesome work @ghys ! That post looks great, the only thing i would add is that i think you have a preference for many of the questions you ask there, i would state those preferences as a starting point (vue.js, es6, Quasar for example) so to focus the discussion.

[ghys]

@digitaldan thanks and you're right, but it was a little late yesterday for one more post ;) I finally made it this morning.