KeyMapper icon indicating copy to clipboard operation
KeyMapper copied to clipboard

Button Click Through Feature

Open githubsterer opened this issue 10 months ago • 9 comments

Developer TODO (don't remove)

  • [ ] update documentation Not sure if or how this can be done, but the inherent problem of on screen buttons covering other functional elements can only be solved with some kind of click through feature that would allow you to get to the screen beneath it instead of running the key map. Not sure if you've thought this through or care, though.

githubsterer avatar Apr 01 '25 22:04 githubsterer

The only idea I can think of is eliminating long press triggers for buttons and use the long press as a click through to what's underneath. So basically either short or double press a button to run a key map but long press to access the screen area beneath the button.

githubsterer avatar Apr 01 '25 22:04 githubsterer

Not sure how common this problem will be yet. If you're using floating buttons you really should be using constraints to only show them when necessary.

sds100 avatar Apr 01 '25 22:04 sds100

That's not the issue. I can constrain a button for Gmail only but that doesn't mean there's a place on the screen without something underneath I need to click on. And when you add multiple buttons that problem magnifies.

That's why being able to store multiple buttons and key maps in a single button is so useful.

githubsterer avatar Apr 01 '25 22:04 githubsterer

The only and best way to avoid the issue entirely is to have an invisible button or two in the notification bar/notch that's completely off screen which you can load with other key maps to run, and or a palette of button icons you slide in from the top or side.

githubsterer avatar Apr 01 '25 22:04 githubsterer

Yeah, after thinking it through I don't like my idea of long press clicking through. The whole clicking through concept is just too clumsy. The user will just have to find places on the screen within the app they're using to place discreet buttons that don't interfere with the items beneath, and then resort to the palette and menu options when the number of buttons starts to really interfere with the screen elements. That's about the best way to do this I think.

githubsterer avatar Apr 01 '25 23:04 githubsterer

And if you don't want to get involved with writing code for a slide in palette, then just allow added functionality for any button to contain either additional buttons as a palette in round button form or additional key maps as a menu in rectangle text form. Using those two options will allow the user to manage a full screen of buttons or key maps from a single button, or as few buttons as they wish to use.

Slide your thumb over those buttons or menu items and let go, and they execute.

githubsterer avatar Apr 01 '25 23:04 githubsterer

I'm just not sure I really believe that floating buttons existing over the top of other elements is a serious flaw.

In Gmail for example, a whole row of floating buttons could be placed along the bottom of the screen next to the FAB reading 'Compose'. You don't really need the entire length of the screen to read, and you could always have some partial transparency if you really want to read under it.

I personally use 2 buttons in Google maps next to the app's built in floating buttons, and one small one in the notification bar. They are nice on the lock screen too.

With proper constraints the buttons should only be appearing where there is spare room on the screen and you may actually want to press them. There is potential for some users to under-utilize constraints and I'm curious to see if they will understand the concept of restricting when they appear sufficiently well to avoid frustration with them appearing when they don't want them.

jambl3r avatar Apr 02 '25 01:04 jambl3r

I agree it's really new territory here with this concept.

My main experience with this has been the Android accessibility button that floats on top as do yours and it became so intrusive over other elements that I had to turn it off.

You've added some nice features that mitigate the issue somewhat, and I think having multi button/menu functionality from other buttons would fully address the issue.

I've come to accept that there's at least one place on a screen that will host a button nicely. Being able to use that button as a launcher for other buttons and key maps gets around the clutter issue nicely.

If implemented, my personal go-to will be an invisible button over the notch that reveals a menu of key maps I've created,, constrained as needed. This would mean no buttons on the screen proper, which would be my preference in most cases.

githubsterer avatar Apr 02 '25 01:04 githubsterer

Just curious, do you not find the forced text in buttons distracting when over other text in the Gmail app, or are you using emojis? And if text, how much text can you take get into a small button and still have it readable? Wouldn't it make sense to also offer a rectangle shape for buttons with slightly rounded edges so that button text could be longer?

githubsterer avatar Apr 02 '25 01:04 githubsterer