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.
Why do you use the openHAB app for that? That sounds tedious. Either face unlock and voice control or geo-location based pull down menu that you just slide down and click garage door open.
If you do it manually, it takes ages of course. But you are in an automation forum, you know.
This may be a nice approach in your 5 devices world, but if you force every user to start from an autogenerated (=random) sitemap to drag and drop a few hundred UI elements in the desired direction, you do not need to implement anything. Because the user will start the UI exactly once and never again.
Hm. Paper UI did that. Why did you not complain when that feature got introduced? Maybe because also you started small. And the first experience for a newcomer should be a working solution. If the 10000 items in the generated default sitemap don’t suit you, you can click on the nice little trash icon that is presented to you nearby. ^^
Sigh. You should at least read what I’m writing otherwise misunderstanding will be the result. Maybe you can show me the part where I said that I want to “remove” the sitemaps concept. And also: I’m a bit disappointed, you are lacking imagination here.
You are apparently assuming this “setup” of your sitemap must happen on a 5 inch screen.
Also:
I do not understand this. The sitemap creation process is manual, while I’m suggesting that the very first sitemap is auto generated for the user so that we don’t need to show a blank screen although the user has already setup some devices.
I think I’m spending way too much time here. Although it’s sometimes fun to argue with you guys here, I’m finishing my design study now and then do a bit of gyming. Btw did you guys already produced something voluntary for OH today?
I agree it’s tedious and that’s why I don’t use my phone to operate the garage door (except for that one time for $hits and giggles) when there’s a handy switch within arm’s reach (in all the places that we need it).
No face unlock, or even fingerprint reader, on my phone … so you did indirectly guess its age.
As for automating the door’s closure, we’re happy with our current solution that closes it if we happen to forget to close it manually on departure (based on certain criteria, of course).
Back on topic, the idea of creating an app to allow configuration is intriguing. I’ve always thought it takes a fair bit of screen real-estate to effectively present the myriad of necessary configuration information. However, if you can successfully achieve this for a phone, that’s a terrific convenience.
Let’s say whatever is chose as the “default” UI that OH comes with. Though I’m a little uncomfortable throwing out the official phone apps as no longer supporting the “default”.
What makes you think that splitting it into it’s own app will make it any less confusing? If it’s that confusing then we shouldn’t choose that UI as our default.
I’m not saying that Setup & Maintenance needs to support all possible UIs. I’m saying it should support one default UI. Those users who want something different can install the others separately and at that point they have gained some experience with OH and shouldn’t be surprised if these optional UIs are not integrated with the Setup & Maintenance app.
If those apps were adequate we wouldn’t have so many users looking for solutions like OH. Because OH is a HUB, we would need something that can handle simple lights like controls like you describe, Nest like UI for HVAC, can show some camera feeds, and more. Are we saying that the default UI should only support ultra simple use cases?
So no native phone apps for OH 3, or do we need to involve them here too? Because the default UI design and approach chosen has a wider scope than just the web UIs.
I really don’t care what form the default UI takes. I don’t really care how the UI is sorted and configured (for the sake of this discussion). But I do think we need to:
have a default UI
have a way to create/edit/modify what is shown and how the various Items and other elements are shown on the default UI
have a way to prevent the editing or modification of the UI for those who don’t want their five year old messing everything up
Sitemap creation is more involved than that. Webviews? Images? Video streams? What if I want that Switch to be text and this other Switch to be controllable? Using the Group element to build sitemaps is basically useless and I’d kill it dead if I had the power. It’s one of those many places that leads new users down the wrong path to a dead end and they have to back up and start over.
So we’re back in the “Here’s this nice UI for OH.” Oh, you want to actually control all that stuff you’ve just configured, sorry, go get something else." At least that’s better than “here’s this nice Control tab, but it doesn’t work.”
UI configuration is an OH configuration task coequal to all the rest of the OH configuration concepts.
How does the new user discover and get to this separate UI app? You don’t want to talk about it in the tutorial shown in the SM app. You don’t want to have any reference or links or ways to get to it from the SM app. There’s no more Dashboard.
Ah, but from the Wordpress Admin area I have direct links to the live view of the website that I can review as I make changes. That’s all I’m asking for.
Why? We have full control over the order that concepts and information is presented to the user. And I have a real problem if our Beginner’s Tutorial doesn’t include anything about how to configure the user’s UI at all. That would be taking the user’s 90% of the way and dropping them off and telling them to find there own way from there. The Beginner’s Tutorial needs to be comprehensive in terms of covering at least one default way of configuring and using every part of OH, including the user’s ui.
Then why assume I only ever open my garage door using the OH app on my phone when I’m standing next to the button? My point is why is everyone assuming that when I say that I use my phone to open my garage door that I’m “stupid” enough to do it through my phone when I’m standing next to the button? Just because I use my phone doesn’t mean I always use my phone. Just because I use my phone doesn’t mean I always use the openHAB app.
And implying that I do and calling that stupid is pretty annoying. Give me some credit here. I know no insult was intended but it’s hard not to feel that way when the most extreme case is assumed to be true and words like “stupid” are thrown around.
For the record, if I’m in the workshop part of my garage I’ll use Google Assistant on my phone. If I’m in the car I have my phone automated with Tasker so when I arrive home it pops up a dialog asking if I want to open the garage (positive control). If I’m not at home and need to let the pet sitter into the house, I use the OH app.
You may not have these use cases but I do. And I don’t think I’m stupid for building my OH system to handle all of my use cases however makes sense to me.
And to answer the question @Kim_Andersen brought up about why I’d want to set the thermostat from the top floor?
tl;dr: There is only one thermostat for the whole house. There is only one heater for the whole house and if blows hot air. The house is not well insulated. It is impossible to reach the same temp across all three floors. In winter there is usually a 10 degree F difference from the top floor to the basement, but it’s not always consistent and the three floors change temps at different rates. It is essentially impossible to automate this.
If I’m in bed with a fever and a chill, the only way to raise the temp in the bedroom is to adjust the thermostat on the main floor.
But, instead of assuming I have good reasons for the choices I’ve made, let’s assume in the five years I’ve been using OH and the over 15,000 postings I’ve made to this forum that it never occurred to me that I could automate my heating.
Not yet. Could you wait for the next Friday? I like to add a bit to the design study, so that you understand. In words, after your thoughts:
The dashboard will go that is true. But the list of other UIs will stay. It will be incorporated into the default UI.
The main page of the design study will (in my proposal so far only of course) be that place. There will be big picture boxes linking to HabPanel and ControlUI. The user will be very aware that what he is using right now is only for setting up and maintaining openHAB. The last page of the tutorial will show a brief summary of control UIs we have (that is the Android App, the iOS app, Habpanel, ControlUI. Yes still a few).
Each of those other UIs have the responsibility to also have a tutorial for their interface. It’s not the task of the Setup&Maintenance UI to do that.
I don’t assume anything about you, I shared my own experience and how I felt at the time while within arm’s reach of the switch. It felt stupid.
I don’t feel that way when I’ve connected remotely and opened the garage door for a friend or relative (who isn’t privy to our pin-codes but needed to retrieve something we left in the garage for them). Then the whole phone thing feels like pure genius!
We can take as much time as we need. But if you planned on ending contributions to the discussion here for good I didn’t think that there would be any further movement in the consensus. If there is more to come we can leave it open as long as we need.
.
