make extendedkey quickly usable

[lduboeuf]

For now , as a French, in order to use accents keys, i have to long press and wait 750ms to be able to select accent keys in ExtendedKeys overlay. Let try to reduce the timer so that i can quickly select the correct key.

[lduboeuf]

fix https://github.com/ubports/keyboard-component/issues/116

ready for test: sudo ubports-qa install PR-115

[lduboeuf]

as said on TG, i don't get why initial setup have a 750ms timer before we can select the correct key

[Flohack74]

I am not sure, if 150ms isnt too fast? But we could change it if it fails to be usable =)

[Flohack74]

Still I would ping @cibersheep for his opinion on UX ;)

[cibersheep]

Testing in 3, 2...

[cibersheep]

Feels really good. I'll test next days if something is funny

[UniversalSuperBox]

This is a case where Android provides an option, mostly because it is better for people with impaired motor skills to have a slower timeout. Basically, some people cannot (or will not) remove their finger from the screen fast enough and activate the extension instead of the key they expect. For us it does feel better to have a faster option, however I would not discount the accessibility value of making this an option slider instead.

[lduboeuf]

humm ok. this timer does not manage the visibility of the ExtendedKey but only the ability to select or not an Extended key after the component has been displayed. How you would name this option on settings ?

[UniversalSuperBox]

Ohhh, so this is the delay between the menu appearing and you moving to another thing. For example, being able to move from the question mark to the percent sign.

This is also interesting for accessibility reasons. I do wish we had some people we knew experienced difficulties with motion, to be able to ask them about situations like this. I will have to give it a try after I'm home, if it isn't merged yet.

[UniversalSuperBox]

How does this change layouts where the extendedKey's default selected character is not the one directly over your finger? English is one, the percent sign appears directly over the key while the question mark is default. Does this change cause the percent sign to be selected more quickly than before?

[cibersheep]

I've been using it for some time now and it's true that, even if feels nice, selecting the default keys is weird. I.e.: trying to type 9, selects Ô

[J053Fabi0]

I've been using it for some time now and it's true that, even if feels nice, selecting the default keys is weird. I.e.: trying to type 9, selects Ô

That is a problem that I also came across, but I think it can be fix if the array of characters is changed. The problem is that the way you arrange them in the qml is not the way they show. I have seen that in my last pull request.

[cibersheep]

The problem is that the way you arrange them in the qml is not the way they show. Mmm... I don't know the code but I checked this: https://github.com/ubports/keyboard-component/blob/xenial/plugins/ca/qml/Keyboard_ca.qml#L43 So, in my case this is the extended keyboard. ["9", "ö","ô","ò","ó", "º","õ","œ"];

I would say is something like [default symbol, list by order], then, the default symbol must be automatically placed in the center

[lduboeuf]

That is a problem that I also came across, but I think it can be fix if the array of characters is changed. The problem is that the way you arrange them in the qml is not the way they show. I have seen that in my last pull request.

is it related to this issue ?

[cibersheep]

That is a problem that I also came across, but I think it can be fix if the array of characters is changed. The problem is that the way you arrange them in the qml is not the way they show. I have seen that in my last pull request.

is it related to this issue ?

Shorting the time, makes typing the default symbol (extended keyboard) more difficult

[lduboeuf]

humm sorry i don't see that ( at least on french keyboard ), so the value might be a setting somewhere. For french accents it is annoying to wait so much time

[cibersheep]

Yes, for the rest of the accents is annoying as well, but this change introduces a bad behaviour:

I have tested with French layout and is the same behaviour, try this:

• Tap and press A, the default symbol for extended key is 1 but it jumps to À
• Tap on O, default is 9 but it jumps to ó
• Tap on full stop, default is ? but it jumps to %
• Tap on comma, default is apostroph but it jumps to ad

[lduboeuf]

I see, it selects the key above in the extended key. So it should not select anything IMO until we move the finger in the area

[Fuseteam]

@lduboeuf i think rather it should select the default shown on the key, like on the o there's a 9 annontated so tappinngto extend without moving your finger should select 9

[kugiigi]

I think the real solution for this is to make sure the default one is always displayed directly above the key so that we don't even need the delay. This is what I observe on other keyboards like Gboard. But of course it'll need a lot more effort and analysis :sweat_smile:

[Fuseteam]

uhhh i don't think that will be enough, the delay seems intentionally chosen

[cibersheep]

@kugiigi I think it's design to show the default character in the middle. The delay is to avoid exactly what happens with long extended bubble thing (like the one in the picture) or we are looking to the wrong delay :)

[kugiigi]

I'm not sure if we're understanding each other correctly or maybe I'm the one confused 😅 I tried the shorten delay I encountered the issue of selecting another character because the default 2nd layer character isn't directly above the main key. I think if we can make sure the default character is directly above then there's no need for the delay.

[cibersheep]

For example: is here https://github.com/cibersheep/keyboard-component/blob/xenial/plugins/ca/qml/Keyboard_ca.qml#L43

["9", "ö","ô","ò","ó", "º","õ","œ"] in this case, 9 is the default and it's placed in the middle of the bubble (between ò and ó).

There are two delays, you tap and hold and you see the letter, and then the bubbel (focus on the default character) and after a moment, it focus where the finger is. I don't know if the strategy could be reduce the delay of the first one.

[Fuseteam]

wait it already focuses directly on tap and hold? hmmmm

[cibersheep]

wait it already focuses directly on tap and hold? hmmmm

If you tap and hold the default character is «focused», then it will focus under your finger (if it's in a different position)

[lduboeuf]

If you tap and hold the default character is «focused», then it will focus under your finger (if it's in a different position)

Is this something to keep ?, i don't find it usefull personaly. I would naturally point to the extended key character i want

How is it on Android/Ios?

[cibersheep]

If you tap and hold the default character is «focused», then it will focus under your finger (if it's in a different position)

Is this something to keep ?, i don't find it usefull personaly. I would naturally point to the extended key character i want

Yes!

[kugiigi]

For example: is here https://github.com/cibersheep/keyboard-component/blob/xenial/plugins/ca/qml/Keyboard_ca.qml#L43

["9", "ö","ô","ò","ó", "º","õ","œ"] in this case, 9 is the default and it's placed in the middle of the bubble (between ò and ó).

There are two delays, you tap and hold and you see the letter, and then the bubbel (focus on the default character) and after a moment, it focus where the finger is. I don't know if the strategy could be reduce the delay of the first one.

In this case, if 9 is placed directly above the key then there's no problem if the delay is short or even non-existence. Although, I think this will be complicated to implement and maybe it's easier to just make sure the position of the finger won't be evaluated until it is moved as mentioned a few posts above.

[cibersheep]

[...] maybe it's easier to just make sure the position of the finger won't be evaluated until it is moved as mentioned a few posts above.

Sounds good

[UniversalSuperBox]

There needs to be a pretty large margin of error for the "has the finger moved" decision. Anything from differing pressure on the screen to tiny twitches of the finger could trigger that, leading to the same thing we have already.

[kugiigi]

Hmm...that's actually true and especially since you usually type fast.

[Fuseteam]

or we could include the "O" as the default focussed character then the user will have to deliberately choose one of the extended characters. or am I missing the point?

[cibersheep]

or we could include the "O" as the default focussed character then the user will have to deliberately choose one of the extended characters. or am I missing the point?

Well, for that you can tap on O and you're finished :D

[lduboeuf]

So how can we move on about it?

[Fuseteam]

or we could include the "O" as the default focussed character then the user will have to deliberately choose one of the extended characters. or am I missing the point?

Well, for that you can tap on O and you're finished :D

true, but the primary concern that was supposed to be addressed by the (long) delay is to prevent accidentally inputting an alternative character iiuc

[UniversalSuperBox]

I believe this PR should be closed. The proposed change could make the keyboard less usable.

Every key has two displayed characters. Take the O key in the QWERTY English keyboard, for example. It displays the O as its primary character and 9 as its secondary character.

Pressing and holding the O key causes the extended character selection box to appear with 9 selected by default.

Releasing the key again within 750ms will type a 9. Holding your finger on the key for over 750ms will cause the extended character selection to become active. When it is active, the selected character will follow your finger. For example, the O key has a reverse grave accent directly over the key. So, if you press and hold the O key for too long, the selected character switches to an O with a reverse grave instead of the 9.

The keyboard should instead be changed so the secondary character is always selected by default, and will remain selected unless the user moves their finger. If the current UI is kept, this must be done by putting the secondary character directly above the selected key in the extended character selection box.

Google's Gboard on Android achieves this by reducing characters near the edge of the screen. Gboard also offers multiple rows of characters, if needed.

Note that making a threshold for finger movement before selecting a different character won't work: There is already a different character above the user's finger. In my previous example, if I wanted to type O with a reverse grave and there was a threshold, I would have to overshoot the threshold left or right and then come back to the character I needed.

If the extended key selection was fixed so the secondary character was always over the user's finger, this timer would not be needed at all.