Over the years there’s been a lot to say about the OpenHAB GUI:s. They’ve been split, there’s been custom ones, there’s been 5 installed at once and it never really started to come together until “Main UI” took over. In fact I’ve kind of started to like main UI for creating dashboards.
However, there’s a really really big issue with “Main UI”. Every single time I try to use it either on my phone or on my dashboard display I turn on everything by accident. When scrolling a list of sliders, if you happen to “scroll on the slider”, it sets the slider.
When I scroll my dashboard I put my finger down on top of a button to scroll the view, it presses the button. The UI becomes unusable. One night I had apparently turned on all the lights in the bedroom with someone sleeping in there without even noticing, simply by browsing the UI.
There needs to be some debounce or something. It’s completely unusable on touchscreens. I can’t be the only one.
I have the exact same issue, and I don’t remember the details now, but I think I found that there is something that can be done with the inidividual controls, especially the slider. Sadly, it doesn’t help much when I don’t remember any of the details.
Technically, it probably shouldn’t set at control until either a delay has passed since pressing or until press ends. If there is any scroll action in the meanwhile, the “press action” should be cancelled.
The problem might be that much of this is dictated by Framework7, and they don’t like flexibility, they usually just force whatever “they think is right” on everyone. But, I can’t say for sure if this is the situation here.
I guess technically I could have some setting or old remenant of something on my side since this is an OpenHAB instance that has been upgraded for probably close to 10 years now.
Here is an example of where it becomes problematic. There’s three sliders in a row and they go for almost the full widith of the window. Almost no matter where I put my finger I will modify the dimming value of at least one of the lights. Almost impossible to scroll without doing so. I’m not aware of any setting that could affect this.
If it is a case of the used framework simply acting this way I think it really needs to be rethought somehow.
The problem isn’t limited to your installation, I have the exact same problem. The sliders in particular are very problematic when scrolling, but I’m not sure that they are the only controls with the problem. They are definitively where the problem manifests most often though.
oh-knob and oh-gauge suffer from the same problem (learned the hard way with an air conditioner set to 62 and running for hours). I moved to steppers and a customizable selection widget for this very reason. Plus, I don’t need that fine of a step on a dimmer. All my dimmers look like this:
I don’t think there’s any specific setting to fix it at the moment, but you can mitigate the issue, perhaps. I use MainUI exclusively and I use it heavily on several different touchscreens and I had never encountered this issue until I saw this post. I was curious why this had never been an issue for me until I saw your example image.
The lists in the model cards by default are expanded like in your image, but I long ago changed the setting that makes each equipment a collapsed accordion button. Scrolling does not interact with the accordion items. Yes, there’s one extra click to open any equipment you want to interact with, but on the other hand, I’ve never once touched a slider while scrolling.
I suspect that the problem is inherent to the f7 library, but it might be fixable by simply setting draggable-bar to false on the slider items when they’re in a model card.
Yeah I did the same. I like main ui but when adding “all” channel items to the model I would get bottomless scrolling in some so I moved to using the accordion UI element. The extra click is irrelevant, at least my wife never complained because the original complication was finding the right light in the middle of it all.
While that would probably improve the situation, it’s still essentially a workaround - and one that might make the UX worse - since you now have to “fish and drag” the knob to move it, instead of simply clicking where you want it to be.
I don’t know if anybody has given solving this a proper attempt, it’s certainly one of the major factors in why I’ve stayed with Sitemaps.
From what I understand, the logical flaw is, as expected, in F7, for the slider. The knob uses an external component, roundsliderui.com, and the gauge isn’t interactive so I don’t understand how it can be affected. It seems like any components that use drag-and-drop potentially has this issue.
