Position based probabilistic completion for tapping input
expipiplus1 TESTER ·
When tapping input on a phone keyboard, it would be really nice to run an experiment where we treat tapping input in a similar way to swiping input in terms of mapping screen interactions to words.
I am making some assumptions about how input works with this keyboard, please correct me if I'm wrong:
Tapping input works by taking the input from a set of buttons and then running it against a (potentially sophisticated) spellcheck to generate words
Swiping input takes a range of positions the user's finger has traveled over and once it's lifted uses a probabilistic model to determine which of these keys on the way the user intended to hit.
I am wondering if tapping input could get better completion accuracy by taking into account not just button presses but finger positions, for example if the user (on a qwerty) keyboard presses towards the very right edge of the A key it's much more likely that they were trying to hit the S key instead. If we could use this information as an input to the autocomplete engine I am sure that it could be used to better determine user intent.
Another example that I personally run into all the time is typing things like 'thenquicknbrownnfoxnjumped' where I have consistently pressed 'n' instead of the space key. Perhaps this input model could help out here also.
Discussion
Sign in to comment or vote.
@expipiplus1 the first part already works that way: every tap reaches the engine with its exact position, so a tap on the right edge of A counts toward S, and it also learns your own offset after about 30 words. The missing-space fix only handled one gap per word, so "thenquick" became "the quick" but anything longer stayed glued. Fixed for build 464 (and the App Store update after 2.2.1): it now splits into several words, and an n tapped low near the space bar counts as a space, so your example comes out as "the quick brown fox jumped".
@efko
I notice that the heat map page says that corrections use only the single shared offset and not a probabilistic input per key. The comments here and on the other thread seem to suggest that the text on the heat map page is out of date
@efko
I notice that the heat map page says that corrections use only the single shared offset and not a probabilistic input per key. The comments here and on the other thread seem to suggest that the text on the heat map page is out of date
@expipiplus1 the page is up to date, the wording just undersells it: every tap is already scored against every key by how far it landed from that key's centre. Fixed for build 468 (and the App Store update after 2.2.1): the text under the map no longer reads like corrections ignore where you tap.