Openhab-android: make switch touch targets full-screen

[Human]

For simple binary switches, the "button" can actually be the full width and height of the cell containing the icon, text, and button.

[curlyel]

I'd like to encourage you improving the size of the controls too. I'd love to see wider sliders and buttons (at least on tablets in landscape mode). A seven inch screen is big enough to control my home usually. But in recent versions (using 1.6.0.4 currently) the switch controls are way too small for my finger tips ;-)

btw.: Thanks for removing the GPS requirement. It maked habdroid available for my android desk phone.

[belovictor]

@Human , I don't clearly understand what do you mean by this description :-)

[cribskip]

@belovictor IMHO he'd like to be able to touch either the icon, label or switch and trigger the switch of the item. Also, sliders should stretch to allow more precise control, especially on bigger screens.

[Human]

Actually, I'd delegate the touch detection to the whole row.

[curlyel]

I've just created a custom image representing the switch handle of binary switch widget. This image increases the width of the widget (twice the width of the thumb image).

@belovictor I'd appreciate if you could check my pull request.

Here is a screen copy out of android studio how the binary switch will look like if merged:

[Human]

In the attached image, the row I outlined in yellow would be the button for the tivo, not just the logo, and not just the switch itself. If you're interested, I'll see if I have time this weekend to submit a patch to make that change. (I've made it once before locally.)

[curlyel]

@Human Using the whole row for toggling an item slightly breaks the ui concept of the app from my point of view. Touching the row usually opens a sub pane or group item. When trying to send a command then you have to touch or draw directly at the widget's graphic currently. This is quite intuitive.

If changing that behaviour to the whole row you may toggle an item accidentally when just trying to scroll the screen. Depending on the item this may be more or less severe.

Therefore I'd prefer to stick a the current behaviour.

[curlyel]

I've just added some transparency to the proposed thumb image to lighten the appearance on the screen. See the picture below how my local build looks at my desk phone. It's a seven inch screen and the current size of the toggle switch widget is well suited for me to be hitten at the first try. Probably we'll need a second size of the image for lower dpi screens.

If the contributers may like that approach, I'll be happy creating another pull request for it.

[Human]

@curlyel

_Touching the row usually opens a sub pane or group item_

To me, it's unintuitive that tapping on the row does nothing for switches. I just want everything that can handle it to have large touch targets. Sliders can't benefit from that, nor can more complex controls, but a switch and a group are dead simple.

_When trying to send a command then you have to touch or draw directly at the widget's graphic currently. This is quite intuitive._

My change doesn't take away that intuition. People who prefer to can still tap the switch; the entire layout acts as the switch, so it doesn't care where the tap is.

_If changing that behaviour to the whole row you may toggle an item accidentally when just trying to scroll the screen. Depending on the item this may be more or less severe._

I use the OnClick method, which is never called while scrolling. A click has a very well-defined meaning in Android.

[Human]

See pull request #100 for my implementation.

[curlyel]

@Human I see your point regarding difference between tapping and scrolling ;-) But: It happens sometimes to me, that if trying to scroll down I generate a OnClick event accidentally. I guess, others had experienced this too. This will lead to unwanted toggling of an item.

If the item toggled is a light switch, this is not a big issue usually. But if this switch item represents a power circuit with computers (HTPC, office wall outlets etc.) or similar sensible devices attached to it, this may become a bigger story. For my KNX installation this is the reason for not having these items on the sitemap currently.

To be clear: I could live with your implementation and I aprecciate the work you've provided. But - if @belovictor decides to merge your request, then the possible applications for the toggle switch widget will be shortened for me.

Yes I know: I can replace the toggle switch for the severe items by two rows of button switches or a selection widget. It's slightly cumbersome and prevents the use of group items (which I like very much). But it will work.

Let's ask the others, how to proceed.
I'd further prefer just increasing the widgets width to be controlled safely.

[resetnow]

@Human controls appearance probably should be kept as close to native as possible, we have had enough Android UI modifications performed by device manufacturers. If it's possible, it would be better to keep native look and give an option to scale the switch.

[ThomDietrich]

Hello,
I want to revive this ticket as I am a new user to HABDroid and this is the first UX "issue" I encountered with this app...
All mentioned arguments and opinions seem reasonable but you should seriously take the Android Guidelines (including Material Design) into consideration. A typical user will always try to interact with an app like with any other:

• a Short Press on an element should trigger the obvious action
• a Long Press on an element should bring forth a menu with alternative actions
• (scrolling on an element should of course do nothing)
• whenever a user performs an action (click, slide, pinch) and there is no desired app response, that's a sign for needed improvement

As an obvious example, please take a look at the android settings menu. Switches are triggered on the full row and sliders span over the full row in order to discourage meaningless clicks.

@curlyel this applies to HABDroid's rows as well. Switching a light should be handled in the same UX fashion as entering a group. Clicking one row should always trigger the expected action.

[ThomDietrich]

@curlyel I thought about your power socket example, I have the same situation with my fridge. That's complicated indeed.
If one switch should not be switchable but rather be just a view, you should cancel corresponding actions on openHAB side... I did this by defining a virtual switch receiving the hardware switch state.

Btw.: in my installation, I tried to keep the number of elements on each view below the point of scrolling because I found scrolling to be a usability killer :)

[CWempe]

I second Thom`s suggestion.
If the "admin" does not want a switch to be switchable in the UI it should be configured so in the backend.

I think you can integrate a switch as "Text" i a sitemap.
This should display the state ("On", "Off") in the UI, but would not be switchable.
Somebody mighjt say: "But I don't want the state to be diplayed as text. I want a visual switch!"
Maybe this could be implemented in openhab itself rather than HABdroid.

[digitaldan]

Sorry I'm late to the party, I think @ThomDietrich makes a very good point about this having precedent within Google's own apps, and I think that additional functionally (device configuration and such, see #100 ) could be implemented through a long touch. My opinion is to accept #100 . Is there anyone who thinks we should not?

[kaikreuzer]

I so far was very strongly on the side of @curlyel's argumentation and I also hate the accidental clicks that are provoked by making the whole row being the switch. About the Material Design UX guidelines, I would have said that the referred "element" is only the toggle image and not the full row, so that should not have been a pro-argument.

this having precedent within Google's own apps

Trying this out, I just realized for the very first time that Google is indeed doing it that way - I had never known... So this is also a killer argument for me: Let's do it the same way as Google in Android, because that is naturally the reference and the behavior people will expect. So no veto against #100 from me.

(But on a side note: We should also definitely use the standard toggle and slider images and NOT do any custom larger ones as suggested in https://github.com/openhab/openhab.android/issues/90#issuecomment-93753281.)