Did you by accident or on purpose locked the other referenced threads?
Did you by accident or on purpose locked the other referenced threads?
That’s on purpose, see The Road Ahead - Reintegrating ESH. Please note that the idea is only to decide whether or not to reduce/merge the existing UIs, it is NOT about any technical decision, what framework to use and what exactly to build - that’s up to the developers then.
Love this idea! It is possible to vote for this somewhere or indicate that it would be great that this UI should replace the existing one (mainly PaperUI)?
Don’t know why you deleted but I was able to read it through fastly.
In my opinion (as only a 1 year old user of openHab), your way could be the best I think. We will still need some HabPanel or other UI which can be optimized just for display&control, but it would be much-much easier to understand. Just one Next-Gen PaperUI and a HabPanel like UI.
At first sight when I saw openHab, the main problem was that I didn’t really know why it has so many interface. Somehow I found that PaperUI seems the ‘most advanced’ I started using that as an ‘admin’ panel. Later I just read that this is what it supposed to do. However since then I have seen many others who gets confused what to use for what.
Also you wrote there or in another post, that usually people configure their OH on a bigger screen. That’s right, but if it’s possible, the new ‘PaperUI’ should have a mobile friendly version. Sometimes I need to configure something simple (like adding a new IP or similar) and if I don’t have my laptop/PC turned on or nearby to me I usually use my phone for these simple tasks.
Again two UIs… Please just one UI and the option to arrange touch-friendly favorite controls on the main page…
It can be one, but then that one should have much-much configuration option. I have a wall-mounted tablet with HabPanel on it, I don’t want to see anything other than controls on that tablet (no big menus with inbox, maintenance and others in it…).
I disagree, I think you need at least two UIs. One user UI and one admin UI. In my perception, and many others, that’s exactly what PaperUI and HabPanel currently are.
Agreed. But this is a question of layout. What I wanted to point out of that I dislike two separate GUI engines with decoupled design processes.
I experienced both separate and unified UIs. What I found to be optimal for me is one UI which allows you to pick “favorite” controls that appear on a “main controls page”.
I have opened a separate thread for it.
UI reduction is necessary. But habmin for instance has a super advanced zwave UI for example. And nobody talks about rescuing all those man hours that went into it.
I have some advanced proposal in this design study as well. And the way how the AC is currently acting is not correct is my feeling.
To be clear, I understand your point completely, but my perspective would be to have two separate interfaces, and they can be using the same engine or backend or whatever (or not), but I would provide a clean user-only interface to the other people in my home, to avoid “Daddy, what does this button do?” kind of situations.
Exactly. No one talks about and (now) you have to keep habmin just for that (because it is useless for other things…)
Why? What is the current standing?
Is this UI in the sense of graphics, or the logic below? I.E., could the work be acting under a unified UI?
Both. It adds Java code to extend the rest interface and it presents a graphical representation of the zwave mesh.
I have considered that in my design study: A binding can have additional self provided HTML pages that are accessible from the binding screen.
Yes, really cool! Also the ‘Maintenance’ page is awesome! Now if I have to access infos like on this page I have to use SSH… this can be also very handy
We will never have the case where there will be only one possible UI. It just isn’t going to happen. The API the UIs work with are open. Anyone can create a UI for it if they want to.
But what we can and will have, IMHO, should the AC vote for it (this is all just discussion at this point) is one main UI that is the default UI and the one that all the docs work with and which is capable of doing anything that can be done in a UI. Then, for those who so choose, there will be the option to install additional UIs.
If you only want to use the one UI, that’s your prerogative and the idea is to support that. But I don’t think your prerogative should trump the preferences of those who desire a UI with a different look and feel or want to have completely separate UIs for admin and for users.
Then don’t install any other UIs. Your preference is honored and supported. But don’t take away the choice from those who disagree.
I have thought about it though. It comes up frequently when users try to make it do things that it doesn’t really support anymore like building Rules in the Scratch like Rules builder. There are a lot of brilliant ideas in Habmin and it is the best for administering zwave.
If you read the original proposal, along with creating the single UI that can do everything would be role based access where what parts of the UI that are visible depends on what user/role you log in as. A “user” would only see the clean user-only interface. The “admin” role would get that plus all the administration controls.
I like that approach. Then the binding can provide it’s own additional administration capabilities.
Well, the AC has been stood up for all of two days. There are clearly going to be some growing pains. I’ve tried to address one of them (how to handle community involvement so it’s not just the AC saying “thou shalt”). If you have suggestions for further improvements I’m all ears.
It is also important to realize that the AC can decide the what, but not the how. The AC would approve “merge the UIs”. What that looks like (whether it’s your approach or Yannick’s approach or a combination of the two) is up to the developers.
The most logic is actually on the server side and visualising the mesh should not be too hard.
But it simply does not make sense to have a specific UI just for Z-Wave, which otherwise duplicates a lot of functionality. We should really get to a team of people maintaining one UI code base instead of 5 people maintaining separate UIs with different technology stacks. I very much hope that @chris will also be a part of this team, because clearly, he has good ideas as well as coding skills around that.
Maybe you perceive it the wrong way. The AC is meant to help and not to deprive anything from anyone. It should be summoned upon discussions that are otherwise blocked - like the one about future configuration options or this one here about removing existing UIs (adding new ones is a much simpler task).
I’ve read the original proposal, no worries, I basically read every single reply here. That does however not mean that the replies all steer in the same way as the original proposal, so that is what I have been replying to as well.
To the point:
So would the clean user only interface be something like Habpanel, something like Basic UI or like the control part of Paper UI? All these have their specific uses and specific groups of user that prefer that certain type of interface.
And what if I don’t want a login section as part of my clean user-interface?
And what if I want interface A on a tablet on the wall, and interface B on the screen of my phone?
If one would like to accommodate all that, a jack-of-all-trades interface would have to be made, which I imagine would be a nightmare to maintain and would steer far from the far more modular type of system OpenHAB is now.
So what I am (probably) really trying to find out and to convey, is if there should be a single user interface, or just a single admin interface?
For some of the users, OpenHAB is barely a home automation system, for example, when you just use OpenHAB to connect your smart bulbs and control the color and intensity of the lights via a tablet with a certain user interface on it. For other users, they barely ever perform any action, as everything happens automated after setup, and maybe just check graphs with temperatures/energy usage. Ideally all admin and setup work should be possible to perform via a single admin interface: so you do not need to use multiple interfaces (even though you could/might). In my perception, that is the main point of concern here. There shouldn’t be a need anymore to do admin tasks in UI 1 (now Paper UI), then switch to UI 2 (now Habmin) when you want to do some advanced Zwave things, then switch to UI 3 (Visual Studio Code) to setup persistence, for example.
What I really like about the system of @David_Graeff is the extensibility and thereby built-in modularity of the proposed next gen UI, which could basically provide all of the above (so as soon as you install the Z-wave binding, get some extra admin pages purely for Z-wave, for example)
At the same time, you will want to break out of the “shell”/“framework” that this next gen Paper UI would form then, when it comes to user interfaces. Keep in mind that people have also made several widgets or changes to Habpanel that basically break out of the DOM structure that is implemented in Habpanel. That alone already shows that there is a demand for this freedom to shape a UI completely as you like it.
That will ultimately be decided by whomever takes up the effort to build the new UI and very much wish of discussion here.
I can and would imagine the default no login would be a user role login. But that’s a detail to be worked out by the develops and worthy of discussion here.
Add I replied earlier, you will always have more than one option in choices of UIs. But to turn adding my same logic as I used for my for my reply to Tobias. Why should your preference trump the preferences of those who may want only one interface? We should be able to sort both preferences.
Perhaps, perhaps not. I don’t think that is a foregone conclusion.
But I don’t have a week go by where I don’t have to explain at least three times to different users what UI should be used for what and I get the joy of dealing with the frustration caused by having too many choices without a clear intuitive way to know on their own.it’s not like the proposal is capricious and not caused by a real perblem.
We have a single admin integer now really. Rarely do users happen upon Habmin and when they do they quickly realize it’s limitations. But even those who only know about PaperUI become confused, frustraited, and annoyed that they can’t do it all through PaperUI.
So why not extend it to also support the end user UI with role based access? It is modular and can extend to full every other function? That works make a sizable portion of new users happy, reduce the time the sport folks spend explaining yet again why they can’t do everything through PaperUI, and those who want something different have the option to install and use Habpanel or something else.
Personally I like the proposal because it:
Looks really Cool…
Way to go