Re: Build 132 - Half-screen test


 

Thank you Ed.

Regarding the size of the keyboard, we have to balance being able to interact with the rest of the current app you are in, as well as preventing accidental taps while you’re typing that happen to be above the keyboard. That said, a little smaller than the current size might be best.

When you say there is no benefit as it currently is, do you not find it more convenient that you can access things like the send button in messages without having to first dismiss the keyboard?

Thanks,
Kosta

On Jul 5, 2018, at 13:00, Ed Worrell via Groups.Io <ed.worrell=icloud.com@groups.io> wrote:

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,

Ed

On Jul 5, 2018, at 1:49 PM, FlickType <hello@flicktype.com> 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,
Kosta




Join alpha@flicktype.groups.io to automatically receive all group messages.