Re: Build 132 - Half-screen test

Ed Worrell <ed.worrell@...>

Hey Kosta,

This is a great first step. I would love to see the size of the keyboard foot print decreased dramatically. As it sits this would not be functional for me at all. There would be no benefit to me to have the top of the screen showing. If it were even slightly bigger than the default iOS keyboard that would be great. A half scree mode would even be a little better than the current size. For me the closer you can get to the default size of the iOS keyboard the better.

Great job as always,


On Jul 5, 2018, at 1:49 PM, FlickType <> wrote:

You will probably need to revert back to build 131 after this, but we really wanted to get a very first round of feedback and ideas on the half-screen mode that has been in the works for some time now. In this highly experimental build, the keyboard will only take up 60% of the screen height in portrait mode, and will always take up the entire screen in landscape mode as before. We are looking for feedback on what the biggest issues may be that prevent you from utilizing the keyboard as you'd expect. Assuming we eventually get this to work properly, we are considering having an option and/or a gesture to toggle between full screen and half screen modes, as well as eliminating the dismiss function altogether.

For those who'd like to know the details, here's what's going on behind the scenes: As before, FlickType does not immediately send keyboard events to the textfield, in order to prevent problematic VoiceOver feedback which includes delay, stutter, and perhaps most importantly a lot of erroneous feedback such as "End of document" which would happen with almost every word typed or changed. Instead, FlickType will hold on to all the new text you have typed, and only commit the changes upon dismissal or switching to the next keyboard. But with the half-screen mode, FlickType will also commit all changes as soon as the VoiceOver cursor moves away from FlickType. This means that as soon as you touch above the keyboard, you will hear the text being entered in the textfield. In principle, most users shouldn't even realize what's going on since the text will appear to be in the field as expected. I should note, however, that I've experienced instances where the cursor will move outside of the keyboard, but iOS will not notify FlickType about it, and the only solution in that case is to make the keyboard active again either by touching it directly or by moving to the next screen element, and then touch above the keyboard once more. I have no sense of how common this may be under normal use.

Eager to hear back any and all feedback you may have.

Thank you for testing,

Join to automatically receive all group messages.