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.
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.
I have a user story in my mind and I recommend to create some stories on your own.
John has bought the Philips Hue system. He also got an Echo and a Xiaomi Vacuum.
He decides to combine all this with openHAB.
He installs openHab and starts it, according to the instructions linked from the download page.
He opens the webpage of openHAB in his browser (he already knows this procedure because his smart wall sockets required him to enter the wifi credentials via embedded web pages, too)
He is greeted by a tutorial that explains him some OH concepts, like bindings, things and channels.
John doesn’t want to read soo much, but thankfully there are many pictures and even an embedded video.
He knows now that he need to install bindings for Hue, Xiaomi and his Echo.
His Inbox shows him already his hue bridge and the vacuum. He adds those. While adding the things, he is questioned if he want to automatically create Items. He knows Items from the tutorial and accepts.
He can’t see his Echo though.
But the Binding page has the documentation linked and he finds out that there is no auto-discovery, before he has entered his Amazon credentials. Sounds logical.
He adds his echo manually via the Thing page. Again he is asked for automatic items.
He now wants to set his hue light on and off to have a first success feeling.
He is not seeing any “control” part in the interface though, but wait. He remembers from the tutorial but also from the start/home page that there was another interface very prominently linked.
He opens that other interface. It looks awesome, fluid and animated. He sees his light bulbs on the first page already. Not sorted by rooms, but that does not matter yet for him. He turns the lights on and off and is happy with his selection of openHAB because it was so easy to setup.
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.
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.
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.
I assumed you use you phone to control your garageport, as you mentioned that. You didnt specific mentioned any situation.
I never said that… Actually, I asked!. I guess asking isn´t good enough either… Ofcouse, I should had assumed, that this was the only way for you to controle it, like its all that common.
I dont…
If I cant even take a shit without my phone, then something is very wrong, (my opinion).
I dont carry my phone with me, when taking a bath either. Infact, I dont even carry my phone with me when I´m at home. Its laying on a table in our kitchen/all-room for charging. At night I bring it to the bedroom, cause I use it as an alarm clock. All other kind of notifications are put to silence.
Do you guys have a single UI in your bathroom? As defecating and urination are completely different user demands, it definitely needs separate interfaces!
Hmm, or maybe someone invents something that very well works for both. Ideas?
Number of UIs
I like the Idea of having a combined UI for users and admins, but controlled with a right management system. And a special one for tablets seems reasonable to me. At the end I think, that the discussion about one, two or three is a bit unnecessary. Why?
If I change the configuration in an administrative view, I want to reach the result without entering another URL. I think most people would agree. But whats the difference between a link to the user-view in the same or a different UI? There is none in my opinion.
If an end user does not see the admin-gear-wheel-icon, whats the difference? None.
Rights Management
I like the idea of having a rights management. I would expect it to allow different sitemaps for different users or hiding parts of a sitemap. I would like that a lot! And…
Security
Having an integrated rights management and user authentication would make things easier without doing that reverse-proxy-magic stuff, that no normal non-it user would be able to implement.
Ease of use: UI widgets
Why the hell do we all need to fiddle for hours to get the functionality running everyone likes to use? There are some approaches with Habpanel’s widgets and the Paper UI control part. But in my opinion it is not enough. Why?
There is no default widget for most used things, like SONOS.
The design differs, if different people start building those widgets with a lot of HTML/CSS code.
Taking Sonos as an example: Today the basic functionality is done by combining sliders, music-control, text fields and images for the cover art. Takes time and may be acceptable. But did you try to make multi-room audio work? This is a huge task to do with loads of items and rules. If we talk about the common user (non IT programmer guy), in my opinion a binding should provide a nice looking widget, well designed by using the standard style guide, with all needed basic controls and - in this example ideally - multiroom support.
That could mean that a binding should have a further way to define the standard widget for specific things and a way to include necessary rules and how channels have to be linked to the widget and rules to work.
Voice
I would really love to have an on-premise (non-cloud) voice recognition integrated with ease of use as the future UI…
I once tried to carefully ask Kai if we could introduce more Item types or composed Item types (for expressing for example a coloured light with a light temperature, but also for an advanced music control item). The answer was no.
Binding provided widgets is not going to happen. The UI is not only for the Web but also for other REST consumers like Apps etc. There’s not yet a good solution. Maybe a new sitemap concept might help here. A binding could provide sitemap “elements” (that consist of multiple existing item types in the end).
The base is not basicUI. The android App is rendering everything on its own with its own styling guidelines. They should of course change to a Material Design soon to match the rest of the platform.
(joking)
