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:
openhabianpi:8080/master
openhabianpi:8080/girlfriend(boyfriend)
openhabianpi:8080/guests
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.
Quite good, but commercial. Look at their price tab. They will probably have a special deal for open source, but then why not use the complete open source, Google supported flutter.io.
you need to enable pairing at the zwave hub and then press a button at the sensor
Homematic devices
you need to start the pairing mode at the CCU or Homegear and then press a button
Some sensors could be paired while at your desk while others (like thermostats) need to be installed first.
Please don‘t limit this view to the openHAB administrators but also to family members.
No sensor or rule can determine if my wife wants the livingroom heated or not.
Never let voice control without voice recognition control something that is security relevant.
And that‘s only the part when leaving the house.
How many cars are able to send this information to a smart home?
My BMW already has some informations that can be used in openHAB but the information is polled and doesn‘t have a parameter for the engine.
And what about the other way?
I‘m coming home and just want to park in front of the garage instead of driving inside because i just hop inside, grab something and leaving again.
It‘s not always black or white and it‘s hard to tell what someone will do with openHAB or not.
Most users want smart controlling instead of home automation.
It‘s easier to have an sitemap with controlling for everything instead of tons of apps to control everything one by one.
Guys! Seriously! Please stay on topic. @Kim_Andersen did a hypothetical suggestion (on the wrong topic!). But nobody wants to remove UI. And its not part of this topic. If you continue like that the AC will continue to look down all future decision taking threads. And the look down is the pure reason for this topic.
Just to make clear… I´m not speaking for removing Web UI´s.
What I´m trying to say is, that in my opinion there are two major parts.
One for setting up the system, and one for using the system.
The second could be several/different kinds of user-interfaces, (different designs) like we already have today. But I would prefere one powerfull and flexible option to design the front-end user design.
This is basicly how it is today - But they need a facelift, a clean-up, as well as new and more powerfull functionallites in both parts.
Openhab dont need to get rid of any of the UI´s we´re having today. But they could become optional during the installation of openhab. In time, when new or better UI´s have been made, I´m pretty sure the old ones will dissapear.
I made a quick strategy plan to show my idea… Just to make sure everybody get it
You´ll probably notice, this is not much different from what it is today. But it should be optimized alot.
First of all…
The administrator tools should contain every possible setup options. We can not have an administrator tool, which isn´t capable of handling everything, (like PaperUI cant set taggings for items today). This is very wrong.
The administrator tools (green Web-UI) could be alot better than PaperUI is today. By the use of a better design and drop-down menu, things could be alot better giving a better overview.
I wonder when I enter PaperUI/configuration/Things, all things are listet. Why aren´t they sorted in a sub-menu (fold-out option) from the bindings installed? The same goes for the items. They could be listed and sorted by things (fold-out option). I know there is a filtering options, but why use a design like this. It´s old-school design.
There should be NO control-panel inside the administrator tools. (like PaperUI has today). If the administrator need to control/test/whatever anything, create a front user-design or use frontail log/logfiles.
Second…
The tool for designing the front user-end should be alot more powerfull. (I like the idea of using an scalable vectore graphic design for big screens (tablets etc), like the one in the Habpanel/SVG design.
Unfortunatly habpanel is not powerfull enough to make this fully scalable.
And then a more “simple” BasicUI-like design for mobilephones/small tablets.
This can become a problem where the administrator has to build two different designs). Using scalable vectore graphic design, it could become a plain drag and drop directly from items/functions, if the icons are vector graphic as well.
The Front-user design is the finished design for monitor and/or controlling the system…
My wife and family doesn´t really care about, what I´m dealing, (struggling), with when setting up the system. They care about the end-user interface, the end-user design. This is important to make this a userfriendly and logical as possible.
Please notice - None of the above has anything to do with main installation of openhab!!
Also notice, none of the above interfere with the idea of having control-buttons in the front-user design. Infact, anything should be possible.
My idea is mainly taking from the strategy behind the IHC system, for those of you who are familiar with that commercial “Intelligent House Control” created by LK/Schneider.
You have seen my Paper UI NG design study, have you? I agree with almost all of your points.
The day is unfortunately only so and so long, otherwise I would think about the frontend controlling part as well. I hope that Yannick can help out.
HA has more developers and they penetrate more and more projects, and we only have more “users”. That does not scale well for us at the moment. But yeah one step after the other.
Just fyi: There is no free developer slot for “refrehsing” or enhancing habpanel atm.
I have, and I like it alot… It´s a major step in the right direction of my idea. (I dont like the design though, but thats a matter of taste ).
I know, this is open source and rely on free an volunteer programmers… I do respect that, ofcouse. But to archive this goal, there is a need for more or things will be getting along slowly.
I wish I could provide some more help, but I cant code anything. It has been a few decades since I did, as well as web designs and havnt done since. So I would be of no use today.
What I can do is to provide my idea of the way I see things, just as well as I believe anyone else should provide their idea. Then it´s up to the AC/coders/whoever to pick what may seem to suit openhab best, and work on that part. AC/coders should not be locked onto their own ideas only.
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?
I can see value for sensors etc
yet I know that i’m using my phone/tablet or website a lot for controlling
what I tried to say, was I never use my phone, or tablet for administrating/setting up the system.
I 'm a text person, so I will not use anything else for setting up, yet the new users that I know, usually prefer to not use their phone for administrating stuff, because it’s damn hard to get a good admin site on a small UI like a phone.
that was what I was trying to say in that part
Using a phone for control is even more stupid than using physical switches/buttons.
You might not like it
yet I do, so you just called me stupid. Probably not your intention, yet that is what you did.
Many users have different needs. a sensor and a physical button is the same for every users.
with sitemaps I can offer more different options for different users.
that works for us.
many UI specialist think that is a very confusing for new users.
when they see a greyed option they know faster they need different rights
if they don’t see the button, they thing they look at the wrong place.
==> less questions on the forums
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.
the confusion here seems to be lacking of the features
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.
here it seems to many options. not two clear different interfaces with different intentions.
But if we keep the user’s ui and admin uis completely separated doesn’t address the apparent
I was not talking about two different interfaces. One interface with different parts
one part for controlling and one for admin /setup
I think we actually say the same, with me more in detail on how to combine them
I agree, controling the lights from a phone app is suboptimal
I’m thinking more about settings scenes. TV/ romantic/breakfast etc
I don’t have enough buttons in my (new) house for all the options I can already now think of.
Many users do not have voice command either, because it isn’t available in their country,
We are also a long time away from having good enough voice control in all languages.
some things end up being more convenient to control from my phone
A phone is location independent.
I work at home from a walking desk. with a tablet/phone website I can contor my whole house, without the need to leave my walking desk.
And when my family is a sleep, I don’t want to talk to alexa to turn of the television my son forgot to turn off (and I don’t want automatic turn off the TV when someone has just left the living to go to the toilet)
Using a phone for control is even more stupid than using physical switches/buttons.
No, my intention was not to call you stupid, as a person… It´s the act itself which doesnt make much sense. Like I wrote to Rich…
Standing in my garage right next to the physical pushbutton to controle the garagedoor, or should I go for the phone in my pocket?
We shouldn´t be arguing which option requires less handling (= beeing smart). But we can have different opinions about, which option is “smart”. I know my opinion in that specific situation. I would feel rather stupid going for my phone
This is basically what I´m trying to advocate for, in general! As well as the UI´s for openhab (trying to get back to topic). Think smart, be smart. This is what smarthomes is all about, in my opinion though!
like I said , not your intention, yet when you say “using … is stupid” and I like to do that, you are telling me that I’m stupid.
I would much rather prefer you asky what is my intention in doing it that way, you will lget the same answers without making me feel insulted.
Standing in my garage right next to the physical pushbutton to controle the garagedoor, or should I go for the phone in my pocket?
yes when I’m close to a button that is configured to do exactly as I want, I will use that.
yet most of the time:
I’m not close to the button:
On the couch
on the toilet
in my car trying to get into the garage
I left the garage with my hands full of groceries and It’s raining cats and dogs and I want to close the garage from my house.
I want more sphere’s then I have buttons.
about smart homes:
There is a training facility that I used some time ago, not had buttons that activated sphere’s, like presentation mode, video mode etc.
all great if you know what switch does what and works when.
when you only hire it for an afternoon, they don’t bother to explain the buttons they give you a tablet where every button has the name of the mode, much easier for newbies
With all due respect to people’s “feels”, I’ve used my phone to open the garage door, while standing next to the door-opener switch, and it felt … stupid. Using a boatload of technology to activate something that was well within arm’s reach (and activated faster and with less hassle) is silly.
Opening the garage door while on the toilet? I’m offended by this vulgar imagery. Ought to have been a trigger-warning at the beginning of the post.
/s
Enjoying the technical aspects of this discussion. Nice to see the planning of next-gen openHAB out in the open.
I do agree with that. I’m mainly pushing from the user’s perspective and the sorts of confusion and things that users try to do with the current PaperUI and get frustrated about.
But your girlfriend won’t be creating sitemaps even in the other UI.
To me, if we are going to default on sitemaps, which seems reasonable, then the creation/modification of the sitemap(s) is a setup & maintenance task. Is it not?
My fear is that we will be right back in the same situation we are now. This UI which get’s installed by default can do almost everything. But if you want to create a UI for the users of your home automation, take your pick from these separately installed and configured options. We will be getting rid of one (i.e. replacing BasicUI/ClassicUI with whatever this new things becomes) but the users are still left without the knowledge of the compromises they may make if they choose one UI over another.
At a minimum I’d want a link to the sitemap building UI from the Setup & Maintenance UI, but once you’ve done that, from the user’s perspective, is it really a separate UI?
Personally, I don’t really care if the code baselines are built and managed in separate repos. But from a usability perspective, there really isn’t anything special, conceptually, about building sitemaps compared to any other OH configuration activity that would explain why I have to go to a separate tool to set up and configure it.
The only reason I want to viewer to also be available is so we can more easily bring up the stiemap we are working on.
So my thinking goes…
There is nothing conceptually different, from the user’s perspective, in configuring Rules or configuring the sitemap, or configuring Items, etc.
Therefore building sitemaps is a setup and maintenance activity.
Therefore building sitemaps should go in the setup and maintenance UI.
If I can build sitemaps in the setup and maintenance UI I want a link or access to a viewer so I can see my changes “live” from the tool where I build the sitemaps.
Thus, one UI makes sense to me.
If you can convince me that building a sitemap is indeed conceptually different, from the user’s perspective, then my train of logic falls apart. I concede that from the coding perspective, it may be fundamentally different.
I don’t think we would have the same confusion as we have with the Control tab in the current PaperUI because we are already in a configuration context (i.e. build sitemaps here) and presenting the viewer is part of that configuration context (see what you’ve built live).
Maybe this is a disconnect. I’m not talking about something like Yannick’s UI where there are two entries on the left side, one for setup and one for sitemaps. The viewer that is part of the admin UI is kind of like the play button in the Rules builder. A way to see and test what you are building. Thus access to the sitemap viewers would be only from the Sitemap page, and that access would be labeled something like “see it”.
I don’t think we are talking about replacing the native apps.
I’m strictly speaking from the user’s perspective. As long as the user sees a unified interface it is irrelevant to me whether the code for those is stored in one repo or a dozen. Absolutely, if it makes sense to develop the app like that please do. But needing to open this URL to configure Items and this separate URL to configure Things doesn’t feel right from a user’s perspective.
That’s what I mean by separate apps. Truly separate web pages that at most have links to each other but which do not appear integrated into a single whole.
In many cases I would agree but in this one I don’t know.
Think of Wordpress. Do you really want a grayed out administration bar across the top of every Wordpress site you go to? You can never do anything with it. It is even relevant to you as a reader of the web site. In fact, it shouldn’t even be apparent to you that you are looking at a Wordpress site (though you can always tell ;-).
Or should that administration UI element only appear to someone who is actually logged into the Wordpress admin page for that site? It’s kind of the same thing in my mind. Why clutter the UI with elements that don’t even make sense given the role of the user? That will serve to confuse the users of the home automation. I don’t think it will confuse the administrator/builder of the home automation. Plus see above, I don’t think people have the same thing in mind when I say they should be one UI that I mean.
At the risk of bringing down David’s ire.
You make a ton of assumptions here, none of which are true. Of course I push the button if I’m standing inside the garage. But what if I’m in the car arriving home? What if I’m arriving home from a walk? What if I’m not home and want to let in the pet sitter? As Yves said, which interface is most convenient to use is location and context dependent. Multiple types of controls must be supported including the phone apps.
I never said I’d use my phone in that specific situation. But you treat that one specific and extreme situation as if it was the only situation that matters.
Do people never open their garage door from outside the house? Like when arriving home? Sheesh.
You are currently restricting yourself to sitemaps. But there will be more ways of controlling. A chat bot like way, maybe just a list of sortable scenes to activate. You also need a list of alarms/scheduled tasks. And so on. Such an app would at least resemble the Hue app in its functionality.
And that alone is soo much functionality that I don’t want to integrate that into a Setup&Maintenance interface. I can’t think of any way to present that to a new user so that it does not look confusing.
Your probably not so tech interested partner can however operate the Hue App. And the Amazon App. The Ikea app. They all provide ways to configure groups, sort your lights, create alarms on so on. And even non techie people are used to that.
I tend to not agree with you in this point. Sitemap creating is basically sorting your items, add items to screens (in other apps called “Groups”), remove items. And: We can generate the very first sitemap that the user will ever see automatically. That will basically look like what Paper UI did. So the sitemap is structured by Things and Channels. But the user will be able to control his system very early.
The user will then in a second step wonder how he can re-order his items, maybe different for different devices, on some devices with sub-pages etc. And if we provide a simple UI here, long-press drag&drop, floating buttons for adding etc sitemap creation is basically sitemap using.
Different design language
The most important aspect why I struggle to accept one UI is however this:
The different design language elements and interface concepts. For editing you want something more like an office product. Like in your example the Wordpress Admin area. It looks totally different than the actual blog. (And code-wise it is separate as well.)
For controlling you want something “fluid”, animated, big, touch friendly buttons, not so much text. A different font even. You want to edit the control interface that you see by directly interacting with it. (Like habpanel more or less.)
User-centric
I think a user will understand this concept with separation of concerns way better. And think of the (interactive / guided) tutorial for a new user. If we have both UIs in one, that tutorial is super long and need to talk about stuff that is not even relevant at the beginning (like how to do sitemaps, if the first sitemap is auto-generated anyway, but not a single Thing is setup yet).
The current solutions that were presented are showing one or the other interface depending on the access role. I think that would cause a lot of confusion. The role based login should be reserved for deciding which Things/Channels/Items you can control and not which UI (admin or control) you are getting to see.
I think you have a good point here which I (and may be others) not have thought of.
On the one hand creating/sorting sitemaps is an administrative task, yes. But your approach here seeing it not as “that” administrative is good because the different users/family members can make their sitemaps like they want and tend to use it more/like to use it more than having “one admin” making a sitemap. I like your perception on this.
.