Hi everyone, I am a Developer currently working on a new UI Tool App for openHab.
The App will be available on Android, iOS and Web maybe as DockerContainer. It will be free to use and there wont be any advertising so don’t worry.
With the App you will be able to build a UI as multiple Widgets in a ListView. You’ll have to connect your openHab REST Api to the App and after that, every Item you’ve configured in oH will be available in the app. Main Goal is, to make building an UI as simple as possible but still keeping the costumization.
My Question is, if you could wish something for an UI Tool like this, what would it be ?
What are the biggest Issues you run into currrently when it comes to an UI ?
Remember, the App is not for people who want a lot of costumization or are good at building UI from scratch because of coding experiance. It supose to take all the UI stuff away from you so you can concentrate on managing your openhab items, rules and so on but still have a beatiful UI by just some simple config.
Backup of the configuration, means even if I delete the app and install it again at a later point in time I should be able to restore the UI with minimal fuss.
@MitchMcKean Just as something to contemplate over: We had in the past many people building new UIs for specific reasons, many of them were indeed helpful and thus made their way into the official distro. We hence ended up with a pile of UIs in openHAB 2.5, which caused a lot of confusion and it actually raised the entry barrier for newbies instead of lowering it (what seems to be your intention). We thus decided to merge those efforts into a single UI in openHAB 3, which guides the user and reduces the complexity for everyone.
So when asking what are people currently missing, the best action is to contribute those missing features to the existing UI and make it even better.
Locked UI is isolated with the reboot or reopen the App. (I mean that the APP will not go back to the login interface for the next activation.)
(I am still thinking of a way to unlock it without too much effort like reinstall it or clean up settings in the App. If there is any good method please inform me of it. Thank you very much in advance.)
The reason why I need these features is that most users in my circumstance have no idea which interfaces to choose and some of them will mess up the interface setting.
Yea, I understand that but still the point is, as I know even in oH 3 the UI is Web based. No native performance and still not possible to take advantage of the full screen of Mobile Devices because of that. I dont wanne be rude and I really love oH but all the current UIs and specially the current available oH App have a big lack of design in my opinion and really this is a hard problem to solve because often it comes with taking away customization from the user and need much more time to develop.
And I dont want to say here that thats something I will solve but its something I want to solve. Its not that I dont want to contribute something but I want to build something useful for oH wich is not locked in to oH if you understand what I mean…
It will be completely free! There will only be an option to donate and additional themes in the future maybe.
Here is my point. I am coming from full-stack web development currently learning App development and needed a project to start with. So here I am trying to create a UI Tool App. Its not the point that I dont want to cooperate and not that I dont want to contribute anything. Its not my goal to make as much money as possible out of this, just to make that clear.
I really understand what you are saying, specially font-end developers are mostly bad at cooperation but thats not why I started this project.
Currently a got my App working at Alpha. I am on my way to beta and as soon I got something to show and learned enough, maybe even released the app and got some more feedback, then I would say I am in a position where I could really offer something and maybe cooperate. Like ok, now I know what I am talking about, done that, been there. Hope you understand what I am trying to say here.
So I need a special UI for my home, so I need to finish my App anyway.
The only way for a mobile device to have native performance og OH would be to run OH on that device. That is the definition of native performance. Otherwise there needs to be some mechanism to transfer data from the server to the device. A web interface is one such mechanism.
I understand some of your points and also see the need for a native App with a good UX and native OS support - but why not putting your much appreciated efforts in creating a native App in cooperation with the new UI of OH3?
I´m not a developer so maybe there are limitations that Im not aware of, porting elements of the current only web-based UI into a native App… but this would solve the issue that @Kai mentioned (and I definitely share that opinion as a long-time OH user) as well as your purpose to learn more in terms of app development.
But nevertheless, I appreciate your work for the community!
We already have fully supported apps for openHAB on both Android and iOS. We already have too many UIs and while OH 3 helps, we still have too many IMHO. And if you do build a brand new, not officially part of the project UI, I suspect your user base and therefore overall impact to OH and the world at large will be greatly reduced.
And your building a brand new UI solves this how? If everyone who saw a problem with OH and instead of going off and building something on their own instead focused their attention on making those improvements to OH itself imagine how much better off OH overall would be.
But as was mentioned, cooperation is hard. And as a collaborative project, not everyone gets to have their own way. And so we all suffer.
Its like standards if their is 15 standards to follow then why don’t we make 1 global standard. Now there is 16 standards.
@MitchMcKean you have decided to make your own APP to learn which is the only way to learn. Just build something that’s excellent.
Once you have figured it all out see what is lacking in the OH3 app and add it in. It can be daunting task adding stuff when you are new to any group. Just know if you make a mistake around here others have you back. There is nothing that you can break that you and others can’t fix.
I migrated with reluctance from OH1 to OH2 solely due to the UI mess (as I perceived it) at the time. One UI did half of this, the other another third, and not one did all, other than textual config, which seemingly got buggered up when using whatever UI. So I, for one, stayed away from all UIs.
I second the denominator (Creating a UI APP for your Smart Home / openHab), build your own, then you know what is involved, then you can collaborate. I am not a programmer, but write code in C/C++ … but wouldn’t be good with collaboration, as I do not have the proficiency to be of real help to others.
… off the soapbox
One thing I can say, after that v1 to v2 UI experience, it will take me a while to adopt any UI …
This exactly! If it’s good (enough), people will use it and then the existing UIs can benefit from concepts and from code.
@MitchMcKean
My understanding is that you want to build an UI for displaying items and while we already have enough administrational UIs we lack UIs that display items nicely.
Please don’t get discuraged, just build something. Worst case is you learn something, best case is you make lots of people happy.
If I were to design a new UI for interacting with openHAB on mobile devices, I’d probably use “panels” as basic UI elements representing the controls and items to display, and place them in “cards”. In this context, it could be useful to have a fluid layout which allows rearranging the panels on a card, depending on available screen space.
Navigation between “cards” should be intuitive. For instance, swiping up could mean “up 1 level in the hierarchy” while swiping left/right could mean “switch to previous/next sibling card”.
Cards should be assigned weights to enable ordering them. An option to have a card carousel could be useful as well: when you reach the last “card” in a level, you could go to the 1st card in that level by swiping past that card. And the other way round, of course.
Ideally, you should also have a shortcut to quickly select a card on a card map.
One of the bigger problems with UIs is that there’s a lot of subjectivity and personal tastes involved and people will in general tend to feel more strongly when things don’t look or behave the way they want. This sometimes leads, when the person happens to have the necessary skills and will, to something new being built, often primarily tailored to their author’s own needs. Of course it’s also true in other areas (see HABApp) but from personal experience I found this to be particularly true for frontends. When you’re a hobbyist and not doing this on a payroll there’s also the fact that you may just want to spend your evenings building things as you like without getting involved in work environment-like debates, which perhaps might be what you want an escape from in the first place - and that shouldn’t be discouraged either.
When I did HABPanel back in 2016 I ended up providing the tools to empower users to build their own widgets, rather than playing cat and mouse with feature requests, and it was somewhat successful and even was humbled by the ecosystem that was eventually created (see for example New Pride Theme for HabPanel (Based on Matrix Theme) - Optimized for iPhone or Matrix Theme for HABPanel - among others!). This proves there’s a need for these types of tools which allow people to be creative. I hope we can achieve the same with this new main web UI which tries to be as universal as possible, with a good-enough default look but customizable as well. Of course there will be expectations and they will be hopefully addressed as much as possible but the focus should be on providing support to build new designs, rather than minute details and changes to a mandated design.
Perhaps most important, I hope this upcoming major 3.0 release, with this fresh coat of paint, will make a lot of people take another look at openHAB - because a fraction of them will also become contributors and that would get the ecosystem going!
