I have added a “Repositories” page. Feedback is welcome.
Technical background: You can install extensions that provide further extensions. One example is the Eclipse Marketplace. Such an extension is configurable. The Eclipse Marketplace for example can provide bindings and also rule templates. Another extension could manage arbitrary maven repositories where add-ons can be found. The extension I have in mind adds npm as source for openHAB UIs. A dedicated repository page might help in organizing add-on sources.
Items
Group functionality (more complicated than I thought to model this)
and writing the tutorial pages. We need some nice diagrams, videos, pictures and of course text to introduce newbies to the interface and openHAB in general. The text should be concise still, no complete novels
It already supports this. Just nobody has uploaded templates yet, I guess, which is not surprising considering that we only do negative marketing (“experimental”) and have no easy to use tools at hand.
FTR, as this is “merely” a design study to drive some discussion about potential future options, I’ve now started the decision process on how to evolve the web UIs for openHAB in general. I think it is pretty important to streamline different efforts and to have a rough official roadmap.
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.
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.
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”.
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.
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.