toggle quoted messageShow quoted text
Thank you Dave. I reproduced the deletion announcement issue. This should be fixed soon, together with the same incorrect announcement when flicking down to change the last word of the document.
On the accuracy issues, I'd love to get a reproducible example. Any time something like that happens, please make note of the two words before the word you were trying to type, delete the failed word and try to reproduce it. If you can reliably reproduce it, sharing the two words before and the word you're trying to type would be enough for me to reproduce it as well.
Regarding the forgiving area on the top row, the pattern of a manually typed word has never been taken into account. There is no change to the forgiving area when tap-typing. Are you saying that manual typing is so common that the reduced height of that row would significantly affect use? And if so, is there not some height beyond which there is no benefit at all?
On Sat, Sep 1, 2018 at 3:09 PM David Nason <dnason@...
Just a follow up on the issue I mentioned when deleting words in WhatsApp using the minimal and half screen keyboards.
It turns out I'm seeing the exact same behaviour in the demo tab of the container app too.
I've mentioned some accuracy issues too. For example, I tried to type the word "we're".
It offered me "were" as the first suggestion, and "Were" as the second suggestion, but "we're" didn't appear in the list at all. This seems mad to me.
I had similar experience with "does", being offered only "dies" and "dues".
I do know that typing accuracy is down to my effort too sometimes though☺️
I quite like the new one finger tap and hold for read back. But I do see that, in particular people with no usable sight, some people want and need a very forgiving typing area, depending more on the pattern than the correct starting row height, if that makes sense.
> On 1 Sep 2018, at 22:32, FlickType <hello@...> wrote:
> Thank you George, we will fix this bug on the iPad.
> Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.
> I also want to add a couple of points regarding the new 1-finger read back gesture:
> - Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
> - If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.
> I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.