Fortunately I’m not doing that anyway.
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. ^^
I never did use PaperUI for controlling the devices.
I use BasicUI with a custom made sitemap. The problem is, you want to replace the current sitemaps with your manual configuration UI.
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? 
Cheers, David
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.
Only because that is what we have now.
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:
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.
Does this mean you are ready for a poll to see if there is a consensus?
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.
You want to replace the current sitemaps concept (predefined, administrative task), with an autogenerated sitemap which has to be arranged per drag and drop, etc. by the user. This is exactly removing the current concept. Or are you thinking about two different elements each called “sitemaps”?
Wow. You should not assume that much. It gets worse if you assume what others are assuming.
As i wrote above, you want to replace the administrative task of defining the control ui with an user task of customizing the control ui starting from an autogenerated one. What happens if devices are added, removed or adjusted? Every user needs to adjust the sitemap manually?
No… no … no. You misunderstood me. We already today have the concept of a “_default” sitemap. And I just want to pre-populate that. Nothing more. I haven’t even thought about interactive adaption on new devices etc. You can simply remove what has been auto-generated.
But I really thought that I have expressed myself clear enough. Might be the fact that English is not my first language. Who knows.
Ahh. I see. Nothing wrong with pre-population.
But it was everything but clear, because that doesn’t fit in the two-apps-concept and seperation of concerns. The sitemap must be prepared in setup & maintenance app (admininistrative) not in the control app (user). Otherwise you’ll get tons of problems with removed, new or changed elements. Multiplied per user, if OH3 is becoming multi-user.
As you wrote above:
Not even sitemaps!
I have a user story in my mind and I recommend to create some stories on your own.
This is just on the fly invented and not complete.
But user stories like that help a lot to streamline interfaces and work flows to get something done with OH. Of course we need more expert stories as well. For example, if you move to another place and want to rename 100 items at once.
Cheers, David
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.
One of the reasons for our family to use openhab, is to get rid of all the different apps.
We want to use one app/website. That is what attracted us to openhab.
And when me, or my kids are not doing the administrative parts of adding functionality we just want to use the app for controlling the house.
And yes when I’m on the toilet I’m using my phone I have a hard time believing no-one here does use it’s phone while being on the toilet.
and yes I did already open the door of the house because a kid had forgotten it’s key and I was the only person at home and I was stuck ill on the toilet.
I gave real live examples. I’m ok with other people never doing that, I’m not ok with removing options to users that the developers don’t personally find interesting.
if it’s ok to call these users stupid, so it is, yet I’m sad that even in that case, these options are removed because someone uses your software in a way that you can’t imagine.
Most users have used software in a way that the developers haven’t imagined.
I consider that a feature, not a bug to be removed (if not illegal or life threatening)
You are not talking to me are you? I mean, in this thread, I’m not removing anything. Although Joachim first thought that I have proposed that. The configuration part is another story, but not part of this topic.
I think we should all write user stories like above where the use-case that we are concerned about is described. The AC can then decide, if there is no agreement, if the described user story is of relevance for the OH project. But I have the feeling that you are referring to configuration files here.
Cheers
True.
the first part was for you.
I lost track who proposed to remove the phone interface
I should have made that a second reply. sorry
I do Rich…
Then why did you assume I don’t? My entire point was everyone has their own use cases, requirements, preferences, and restrictions. “Automate all the Things!” isn’t always possible, desirable, or worth the cost/effort. I happen to have use cases where it is most convenient to use the phone app to open my garage. That doesn’t make my requirement stupid. That doesn’t mean I never considered other options. I’ve been at this for over five years. The garage door opener was my first home automation. Do you really think I haven’t explored ALL the options? In total I have five different ways to open my garage door, including physical buttons. I use what is most convenient at the time and sometimes that is indeed the phone app.
But the only use case you saw was being “stupid” and standing next to the button and still pulling out my phone to open the garage. Or being stupid by controlling my ONE thermostat which is on the main floor from my bedroom on the top floor.
I don’t lack imagination or drive. I have different requirements and restrictions from you. OH needs to support both of us.
Stay tuned. I would say your user story is a bit of a breadth first approach. Some users will take a depth first approach (i.e. I have Phillips Hue, Echo, and Xiaomi Vaccuum, let’s get one Hue like on a webpage I can control it from). I’ll flesh it out tomorrow, gotta run too soon to start it right now.
Where do you think I’m typing this from? (joking)
I would say this, is not a very common situation… Forgive me for not thinking about this specific situation, which is the reason for asking!