I think it’s important to bring up the other part of the proposal which is role based access (RBAC). This would be required to achieve on UI because we all agree, you don’t want to give access to administration stuff to normal users.
So when you log in as a “user” you see “sitemaps” just as now.
The phone apps continue to render sitemaps.
But if you log in as an admin role, you also gain access to the Setup & Maintenance parts of the UI.
I’m not trying to argue one way or the other, but this detail seems to be lost in the discussion. The proposal is not “everyone uses PaperUI all the time”, its that what a user sees depends on their role. If they are a user, they see just sitemaps. If an admin they get the whole enchilada.
That is not part of the proposal.
And if you check the AC thread you will see that Kai put a stop to Yannick and my discussion as out of scope. The AC’s job is to say “we should merge the UIs”. It’s the developer’s job to figure out the how and most of that discussion Yannick and I had was regarding the how, and therefore outside the purview of the AC.
Like I said on the other thread, we’ve been at this for two days. We are all trying to figure out how this is going to work.
But let me say this clearly. There are no plans. No decisions have been made. There are just some proposals that have been offered. And discussions like what is happening here and in the other threads are exactly what needs to happen. If there is a consensus out of this thread, that will become the “decision.” If it’s contentious, the AC can become the arbiter of last resort (if I understand Kai’s vision correctly).
Tomorrow I am tasked with adding this process we are currently engaged in to the Governance policy. This is how it was always meant to work. A thread opens for general discussion and the AC records the consensus or breaks the impasses.
I’m not against a shared code base. It is actually very reasonable to have one code base. I always tried to think about the newby user while making the design study. I’m already feeling like the main menu at the top provides too much options for someone new. (At the same time openHAB is just very powerful and you can’t break it down much more). But if sitemap creation, controling, interactive habot controling and whatnot is also part of the very first interface a newby sees: how do you present that in a reasonable way.
I’m not sold on the paper UI concept (that Yannick picked up to a certain degree) in which setup& maintenance is hidden in a single menu option called “configuration”. So everything that I have multiple main pages for in the design study is ONE single option in a control centered app. How is that user friendly, especially if you are in the setup phase and don’t want to see all the control parts.
So that is basically my concern. Two UIs make sense. It addresses two use cases. The only other way I see is that you present two totally different interfaces based on the logged in user role. Which is two apps again though.
Complexity is a good point. I guess I was envisioning something like the following:
When the the user role logs in (or no login) all they get is the configured default sitemap and there is a menu somewhere that make sense to select other sitemaps. So this part is simple enough whether it is included in the one UI or not.
For the admin UI I figured when the admin role logs in they would be presented with the Setup & Maintenance UI, either something like yours or Yannick’s “Welcome to openHAB”, or configurable like in your study so it comes up immediately on the maintenance page with the charts and such.
I don’t particularly like hiding the UI under a two entry menu either and I don’t think we need to.
As for the complexity of the admin UI itself, no matter how we break it down we have the following X concepts to deal with:
Bindings (install and configure)
Rules (install and create)
User’s UI creation / configuration / sitemaps / test (i.e. access to the working sitemaps)
I don’t really see how splitting the last part into two separate UIs helps. I would not like it if we had to split the last bullet in its entirety into a separate UI because then we are back in the “Why can’t I do it in PaperUI” problem we have now.
I don’t know if I’m totally sold on HABot being included either, though support for adding the semantic tagging to the Items will need to be supported in the Items UI portion regardless.
You are right, perhaps listing the categories across the top may not be the best option but I don’t really see how adding one more category, one that probably needs to be there anyway, would be the straw that broke the camel’s back. Is the difference between seven options and eight options at the top level really so disruptive that we are forced to provide one UI to allow users to configure everything but the sitemaps and force them to go to some other app to build those? Or even worse, allow them to configure their sitemaps but not actually look at them unless they go to some other app?
My 2cents. I dont see why HabPanel should be kept seperate from a user perspective - it’s not like the UIs other than HabPanel allow you to do much, HabPanel is what makes it sexy to have it seperate seems odd to me.
I’d like to see more intergration and features in it.
Let‘s not forget how complex RBAC is.
The software i‘m daily working with and selling to customers has RBAC.
Sometimes it‘s very hard to setup the correct RBAC in terms of allow/deny and i‘m not sure if this fits the proposal to make things easier for new oH users.
An easy implementation would only allow pre-defined roles like administrator and user.
But this wouldn‘t fit for power users of oH, so there needs to be a basic and expert setup for RBAC.
From my point of view it‘s easier to work in two browser tabs instead of one and switching between options.
It‘s the question what users oH wants to address.
Power users that are working with software on a daily base or users that are new and want to build a smart home.
Some of the discussions sounds like making it easier and simplier for new users but forget about the power users.
The main reason why i switched from the Telekom Qivicon system to openHAB was the ability to control/automate my home like i want it to. And not what Telekom thinks a user would like to do.
I don‘t want to see myself confronted with this again.
Yes, a simple UI that makes the start easier is great and will bring openHAB to a bigger base of users. But i‘m concerned that some power user functions (like working with text/code instead of UIs) will be lost or reduced.
As you said, no decision was made.
I just want to bring this part on for discussion.
Agreed and I said so on the AC thread where this was brought up.
I believe the consensus is that the GUIs address “users that are new and want to build a smart home”. “Power users that are working with software on a daily basis” have already made it quite clear they don’t want no stinking GUI in the first place so those users will be supported through text based configs.
This is going to be a rant. But why why why does everyone seem to think that if we are talking about new users and GUIs and making things easier in one thread where that is the topic it means we plan on breaking everything for the power users. And then you go and talk about how to support the power users and everyone starts to shout “what about the new users?!”
Just because we want to make the GUIs easier to use does not mean we are taking away from power users.
A user need for controlling the house
An administrator need for configuration, creating sitemaps (or the replacement)
Even new users needs that administrator part.
Combining both needs into one UI, will be very confusing for all other users of that are using the same house/building.
With RABC, some tabs /parts of the UI could be turned off/grey so they can’t accidently use that.
I agree that RBAC can quickly turn ugly. That could be simplified if we stick to just 2 (or a limited number of roles) (My propose two roles: controlling, admin)
When I work on a system where I do know the administrator password, I still prefer to work as a normal user, only using administrator rights when I need to, which I consider safer.
F ex when I’m openhab on my phone, I’m only interested in the controlling part.
I can imagine that for new users, it might be strange to have a mode to be able to do more and a mode just for controlling, yet I can imagine that especially for a new users, it’s good to have to consciously swap between controlling and administrating.
But why? What kind of sensor needs you to run back and forward between anything? Thats sounds more like some design problems you´re suffering.
And this is actually the first thing to think of… What IS openhab? And whats is it suppose to be in the future. Do we need a user interface at all, except for setting up the smarthome system (openhab)?
Where is the need. Is it because everyone else is having nice looking apps for mobilephones/tablets, where the user can click a button, and then the light turns on? It doesn´t make sense (to me). Why even bother with all these buttons and stuff. Its a nice to have feature, specially when testing and setting things up. But in daily use, it´s not a need to have. Not unless something else is missing, like physical buttons and/or voice commands. I have yet to see a home build without physical buttons.
What we do need is a good and easy way to provide a monitor for our smarthome. A monitor which main purpose is to monitor, and when automatic things not working, then the use can overrule the monitor and have a functionality, like buttons etc.
I feel the main reason why we dont see smarthomes like this are:
You´re used to have something to push/click/switch and then something happens.
We do not trust our smarthome, at least not fully, yet.
But what if we fully put our trust fully in the smarthome?
This is where the monitors become important. We need to be convinced somehow. And the monitor is the one to tell us things are working, so we can calm down not running back/forward between anything.
Why do you need to controle anything? And why do you need to controle it from your phone? Do you have your phone in your pocket all the time when at home?
As I just mentioned… This sound more like a basic missing act somewhere. What if you could control whatever you need to controle, without the need of the phone?
Voice commands, sensors etc is doing a hell of a job simulating a human act. Why not use that? Thats one of the huge idea behind a smarthome. Let the smarthome learn your way of living, and when you need to “help” it, (you step out of your daily habbits) interfer with it, by the use of sensores and commands, and as a last option, physical buttons. Using a phone for control is even more stupid than using physical switches/buttons.
Phones should be monitors. This is where you look at your smarthome, getting convinced things (your home) are working just the way you have told (programmed/coded) it to be.
I dont agree.
I believe a system like this should be build in two pieces.
For setting up the system.
For controling the system (when its fully automtic, there is no need to control anything, just monitor).
I believe this is/was the main purpose with openhab as well. PaperUI to set up the system, and UI´s like BasicUI, ClassicUI, Habpanel for using the system.
Problem today is, PaperUI cant handle all whats needed. And second, the UI´s (basic/classic/habpanel) are stupid to setup, and limited as well.
In my experience on the forum so far I’m not sure that would be the case. The main source of the confusion so far stem from two “feaures” of the current UIs.
PaperUI has that damn Control tab that looks like it is useful for controlling the home automation but it’s incomplete and doesn’t show everything. But the number of folks who try to use it for control clearly, in my mind, shows a demand for some new users to want to do it all in one UI.
There are so many UIs to choose from which creates a burden of choice on the new users. And there is no “official default” UI except for PaperUI. This is addressed a little bit in the Beginner’s Tutorial where this is explained but clearly users are not reading that tutorial.
When we replace PaperUI with something more complete, problem 1 may go away or at least reduce. But if we keep the user’s ui and admin uis completely separated doesn’t address the apparent expectation that the current admin UI should also be used for controlling else why would so many keep asking “why is my Item x not on the Control tab?”, “how do I get my MQTT 1 Item to appear on the Control tab?”, “Missing Items on the Control tab”, and so on.
When I think about it, having one tool to build the UI and a separate tool to view the UI is really counter intuitive. But if we extract the “user’s” UI in total from the admin UI so you have to both build and view the “sitemap” in a separate tool, I feel like we are right back in the same place. Only this time I’ll start getting complaints about wanting to change the organization of the Items page because users will be wanting to control their home automation through that UI (assuming the idea of being able to sendCommand or update an Item from the Items page which I think was part of the study becomes reality).
When I look at software services of similar complexity to OH (OpenMediaVault, pfSense) I find a similar approach, so it is not unheard of. When an admin user logs in they get the full UI with all the bells and whistles. When a non-admin logs in, they have a greatly reduced UI where they can only have UI elements that let them do the things they are allowed to do. It is not a unique paradigm and I don’t think new users will find it all that confusing.
Also, keep in mind that I am certain that David’s plan to embed a new and improved Beginner’s Tutorial where this can be explained in a couple of sentences would address the confusion for a number of users. We can’t solve all confusion for all users but I do think a unified UI as the default would be an improvement over the status quo.
While 100% automated is a great goal, and one I push users to stretch towards, there will always be a need for control as well. For example, I want positive control over my garage door openers. I don’t want it to automatically open or close, ever. So I need a control for that. And control will require some sort of UI. These can be physical buttons but for many use cases a screen on a phone is going to be most convenient.
I agree, controling the lights from a phone app is suboptimal. But that ignores a whole host of other home automation use cases where the behaviors must be controlled and monitored.
Yes, a controlling UI is a requirement. We cannot just skip it.
Physical buttons for everything one would want to control are almost always missing in most user’s home automation. Many users do not have voice command either, because it isn’t available in their country, a desire not to be reliant on cloud services, privacy fears, etc.
Why should I have to fully trust my smarthome in order to have anything at all? Why should I have to automate absolutely EVERYTHING or nothing at all?
I understand the philosophy presented and have even advocated it on this forum in the past. However, it is not a philosophy adopted by all nor even adopted completely like users like me who subscribe to this philosophy. And whether or not there is a UI, we can still adopt this philosophy. But if we allow this philosophy to rule the day, those who don’t subscribe to is are s%!^ out of luck. They have no recourse.
From a technical perspective, there is no difference from a UI that lets you primarily monitor with some ability to control and a UI that lets you primarily control with some ability to monitor. The only difference is the intent of the person who puts together the UI. You still need the same UI elements to do either job.
Because there are some cases where a device has health and safety concerns like a garage door opener. Because sometimes there is no way to automate the action because there is no event to OH to tell it to do something except for one manually submitted by a user.
Because when want to open the garage, whether I’m driving my car or home from a walk with the family, my phone is what I’m most likely to have with me.
Yes as a matter of fact. But like you advocate, most of my home automations do not require my use of my phone to control them. But there are some things in my home automation that I will not completely automation and those require some way to control them which requires a controlling UI.
Some things end up being more convenient to control from my phone like adjusting the thermostat on the main floor when I’m in bed on the upper floor.
Sometimes voice commands are awkward or disruptive. It can be REALLY hard to develop sensors that tell you everything you need to know. For example, how many people are in the living room? Sensors can become expensive too.
That’s one option. Another options is to deterministically determine how the home should behave and program it to do that. I don’t particularly want my house to “learn” what to do. I want to know what it will do and why. That is one thing AI really sucks at, telling you why it made a decision.
Except when it isn’t. And should you chose to live without a controlling interface, you’re good and well supported. OH has your back and can meet your needs. But why should your preference trump the preference of those who want to have more direct control?
And like I said, the elements necessary to build a UI that is a monitor with a few controls or a UI that is a controller with a few monitors is the same.
I respect your opinion of not having an automatic garagedoor. But honestly, using a phone for closing/open it? I have a switch in my garage to do the same, my phone is in my pocket. Why they heck should I:
take the phone form the pocket
find the app
push the button
When standing right next to the physical button doing exactly the same?
Or even better, just tell Google to open/close the garagedoor?
Next step is to connect the garagedoor to the car. When you start the car, the garagedoor opens.
Ofcouse there will be situation where you start the car, but dont drive. These situations are minimals, and this is where you may have a need for a button in someway, to stop the garagedoor from opening.
I agree, some may not trust the voice commands from google home, Alexa, Siri etc… and specially not when they´re cloud connected. But I have to admit, this is a task we cant win, not unless we remove any kind of connection to our homes, which means getting informations from our smarthome when we´re out, will be removed as well…
And thing of it… Lots of “smart devices” comes with apps and beeing cloud connected as well. And things are just getting “worse”.
You dont have to. The question is, whats the reason for not doing so.
I know there may be reason where a button could be more optimal, (like the garagedoor you mention). But think of it, the main reason is, you dont fully trust the automatic way… Questions like, what if it fails… It´s moving/closing just when your car is under it etc, or even worse, a child/pet…
I understand and respect this, truely… But again, think about it… Do you feel the same, when you enter an elevator etc? You probably dont, because, you trust the elevator.
I know, Rich… And I was provoking, trying to move openhab towards another way of thinking, insted of beeing focused on controlling all the time, then look at the perspective where controlling is secondary.
My main opinion is not to avoid any kind of controlling. I do have buttons, both physicals and virtuals (sitemaps). But the virtuals I hardly ever use. The physical I still use, mainly because my smarthome isnt quite finished yet, still lacking some sensors as well as the voice control in all rooms… But my main goal is to move away from buttons and let the home beeing controle another way programmed from the family needs.
Why do you need to controle the thermostat on the main floor, when you´re at the upper floor? (this is back to the questions of, why). I believe you have a sensor measuring the temperature in the main floor, right? Why do you need anything else? Alernative, a motion sensor could come in hand, maybe even combined with a present detection in the upper floor. When there are no movement in the main floor, set the thermostats to xx degrees, otherweise, yy degrees… Isn´t this the way smarthomes are suppose to be?
But for most basic controls, I would say things are going from okay to alot better. I know language is still a problem somewhere.
Ofcouse… Smarthomes are not easy tasks. And it´s surely not inexpencive.
Well, “learning” is not the right word. I dont want my home to “learn” either. I want it to know and to react from it, including what I have programmed/told it to do from a set of rules I decide.
I understand what you´re getting at, but I dont fully agree. “a few monitors” is the part I dislike. I cant think of any situation where I could accept " a few monitors". Unless you´re speaking in a physical amount? I need a full monitor, and then, as you said, some controles. The controles would not be at the front screen, cause it simply dont make any sense to me. They would be kept somewhere behind the main monitor and only beeing used if something goes wrong/doesnt work as it´s suppose to.
Ehm. I tried to read both of your rather long posts, but… they are long and not really on the point. But what I have noticed though is, they are not belonging into this topic
The goal of this topic is to be the complementary topic to “Web UIs for openHAB 3” of the AC. I had the feeling that the AC is deciding there on behalf of everybody (but that fear was taken, thanks to @rlkoshak) without listening to users and especially contributors.
My opinion on this topic is: Two separate UIs are required. And I want to comment on some misunderstandings
A agree. I’m not separating those two parts. For me it is more like one UI for pure Setup&Maintenance: Install/modify bindings and the setup, check the logs, backup/restore, install new devices, create channels and items. Edit rules, do some batch editing in a text view mode.
Another UI for viewing sitemaps, modifying sitemaps, creating widgets, etc, everything that has to do with controlling and manipulating the view for controlling.
That’s why I think it should be two independent projects. If a new contributor want to add a fancy widget, he has not to learn anything about the Setup&Maintenance codebase (which is naturally different than the sitemap UI codebase).
just quoted because this sums up a new user perspective of openHAB so perfect, wtf… Paper UI appears to be the UI interface but… it doesn’t do everything, and when you don’t understand why… you are told it’s not supposed to be a control interface, but basic UI doesn’t work out of the box… neither does habmin… wtf???
At first with zero knowledge, PaperUI is the only one that self populates and appears to work
well there goes an hour I won’t get back. But I figured it was on topic because kim is advocating for doing away with the “user’s” UI entirely because OH should be about automation, not control. If there is a place for a “user’s” UI it is strictly for monitoring with maybe support for a couple of buttons.
So his answer to the topic would be there should be only one UI, the admin UI. I was arguing against that position.
So how much is shared between the Rules page and Things page? Presumably a lot more or else the same argument could be made to split all the different categories into their own app.
Do we need 3 apps? 5 apps?
Are there synergies that are not apparent between the Rules page and the others? From the outside looking in a siremap builder/viewer seems no more different from the rest of the maintenance UI than the Rules builder/editor.
You got me here. I just wanted to mention that there is no technical reason to have the ONE UI.
I think it’s more like different usage patterns for my two UI ideas. One is being used often in the beginning and then more or less only when new hardware is added.
I mentally categorize all functionality if its one of these setup&maintenance tasks or something that the girlfriend need to operate as well. The controlling UI has actually no reason to mention “Rules”, “Things” or “Channels”. It also looks different, bigger touch friendly buttons etc. I’m feeling uncomfortable to have a UI that tries to suit both. The result will be a paper ui 2 - disaster in a second edition.
I am mostly just reading the topics and don’t have to say much, because the relevant things are said. But sometimes I like to chime in to give my opinion, so…
When I used this other project I mentioned in the other thread one main thing I missed was a native app to control things. I use the openhab-app quite often, because some tasks aren’t good to automate at my site and some tasks I don’t want to automate. But I have my phone most times with me and sometimes the hardwareswitches are out of reach for my lazyness So at least for controlling things I like to have a native app like now.
If otherwise there are two UIs or one or administrative things can be done in the app or not I don’t care that much. Of couse it’s convenient to set up things on a nice app on the phone but for that many items you can have quickly in OH it can get cluttered very fast and for the most time you don’t have to do administrative tasks on a daily basis so the assumption you can have a PC or tablet for this and this kind of UI seems reasonable to me.
Just my 2 cents, hope it’s on topic enough.
What if the parts of the UI are kind of structured as a microservice UI.
In fact we could have 5(x) different Apps (Controlling, Inbox, Things, Items, …).
On top of it all theres the “master view”, which is configurable and shows exactly the parts that the user needs to see. The “Admin” of the OH installation can configure these, so we would have in the end:
Combined with an easy 2 roles RBAC (admin, user) where you just separate the master view from the rest.
As a PWA you could just save the respective links as webapps on the phones / tablets.
I agree though that the mobile apps don’t receive enough love. And if the OH REST API changes for OH3, those apps will barely catch up is my assumption. One (web) app would solve this. I just want to throw in another thought: https://flutter.io/ Just as an example for a technology stack for united iOS/Android native development.