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

On 5 Jul 2018, at 20:49, FlickType <hello@...> 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

On Jul 5, 2018 at 14:49, <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,

Kosta

On Jul 5, 2018, at 13:00, Ed Worrell via Groups.Io <ed.worrell@...> 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@...> 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

On Jul 5, 2018, at 12:49, FlickType <hello@...> 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

On Jul 5, 2018, at 4:17 PM, FlickType <hello@...> wrote:

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@...> 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@...> 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

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

On Jul 5, 2018, at 5:21 PM, Benny Barber <rebelben@...> wrote:

I am trying to work in the iOS native app with the half screen. I can enter the to field and the subject field, but I am having problems with the message body. I can't swipe to it. What am I doing wrong? Thanks.

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

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

I tested sending an email in outlook.

I brought up FlickType and found the to field.

I then started typing alpha.

I dismissed keyboard.

A list of suggested addresses came up.

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’

Numbers 6:24-26

Get Outlook for iOS

---

From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Benny Barber <rebelben@...>
Sent: Friday, July 6, 2018 10:54:51 AM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 132 - Half-screen test

 

Now in the nail app I can't get text to enter into the various fields. I have to dismiss or change keyboards to do so. Thanks

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

Hi benny.

From what I can see. The text does not show up until keyboard is dismissed.

Just tried to send this reply with keyboard up.

But VoiceOver said send dimmed.

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’

Numbers 6:24-26

Get Outlook for iOS

---

From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Benny Barber <rebelben@...>
Sent: Friday, July 6, 2018 11:11:09 AM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 132 - Half-screen test

 

 George, 

 My understanding is that we should simply touch at the top of the screen and the text will be entered. We should not have to dismiss the keyboard to enter text. On what you did, you should have been able to touch at the top of the screen and then pick your person to send to.  Thanks.

Benny

On Jul 5, 2018, at 8:00 PM, George Cham <George.cham@...> wrote:

I tested sending an email in outlook.

I brought up FlickType and found the to field.

I then started typing alpha.

I dismissed keyboard.

A list of suggested addresses came up.

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’

Numbers 6:24-26

Get Outlook for iOS

---

From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Benny Barber <rebelben@...>
Sent: Friday, July 6, 2018 10:54:51 AM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 132 - Half-screen test

 

Now in the nail app I can't get text to enter into the various fields. I have to dismiss or change keyboards to do so. Thanks

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

On 6 Jul 2018, at 10:51, David Nason <dnason@...> wrote:

<mime-attachment.html>

On 5 Jul 2018, at 20:49, FlickType <hello@...> 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

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@...> 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@...> 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