Topics

Build 132 - Half-screen test

 

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

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,

Ed

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


George Cham
 

Hi costa,
Like the half screen keyboard.
The text on the keyboard is smaller.
And text does not show up until keyboard is dismissed.

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 Ed Worrell via Groups.Io <ed.worrell@...>
Sent: Friday, July 6, 2018 6:00:13 AM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 132 - Half-screen test
 
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
>
>
>




Paul Sutton
 

Hi kosta,
To be honest this build is brilliant. I actually haven't noticed any problems as yet..
I tested it out by creating a new text message and typing the letter R and I successfully managed to scroll down all my contact's starting with that letter..
Well done
Paul.

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


Michael Maslo
 

 Hi kosta, 
 
 I really like the new version. It works really well. I can now input a persons name in messages and doubly tap on the name. Also I can hit send button. The problem is I have to flick to send instead of exploring to it. 

Sincerely,, mike 


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



 

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




Chanelle Allen
 

Hi Kosta,
I think that I could get to like a half-screen option for the FlickType keyboard. I am not sure if I could use FlickType effectively if the keyboard is the size of the iOS keyboard, but it would be worth a try. Also, my iPhone is always set to portrait mode, and I prefer to use FlickType that way as well. So, I would prefer a full-screen portrait FlickType keyboard if the half-screen doesn't work out for me, or better yet, giving people a choice would be excellent. I have had the most trouble testing the half-screen keyboard in Mail. Because FlickType occupies 60% of the screen, it is not possible to flick to all text fields or to locate them via touch and explore.
After updating to the latest build and then restarting my phone, I tested FlickType in the Drafts writing app and then decided to write myself an email. I wanted to find out how well I could move to different text fields without dismissing the keyboard. First, I used FlickType to type a few letters into the To: field. My text was not entered, and autocomplete suggestions did not appear even though I retyped the same letters with FlickType followed by a space and then again followed by a new line. Eventually, I dismissed the keyboard, and found the autocomplete suggestions. When I say that I “dismissed" the keyboard, I actually mean that I pressed the Next Keyboard button or performed the gesture. After typing in the Subject field, I tried locating the Message Body area without dismissing FlickType. I was finding the From: and CC: fields, but I could not move any further. FlickType was in the Subject field, but I could not locate the Subject label. The standard VoiceOver three finger gestures for scrolling did not work to show the other fields on screen. When I have trouble accessing controls or information in any app, I find the last item that can be located via explore by touch, place my finger an inch or two from the right hand side of the screen and then I perform a double tap and hold gesture, which I think is the VoiceOver pass through gesture. Still holding my finger down, I move it an inch or two to the edge of the screen and then release. After typing a few sentences into the message area, I did not dismiss FlickType but placed my finger above the keyboard to look for the Send button. When I found Send, the button was dimmed, so I used the method I described to locate the Subject field, which was blank. When I typed in a subject and used the every method to bring up the message body, my text had gone. This occurred at about 1:40 p.m. I will send you crash logs if I can find them. As I have been writing this email and inserting or changing text as I go along, certain sections have disappeared.
The half-screen FlickType keyboard will be useful once some of the kinks have been worked out. When I write, I will just dismiss FlickType to prevent text loss.
Thank you.
Chanelle

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


Ed Worrell
 

Hey Kosta,

Yeah, I am not really seeing the benefit of the keyboard showing at sixty percent. If you could get the size of the keyboard closer to the iOS keyboard that would make it much more functional to me. I find myself dismissing the keyboard anyway with the current build. I just don't find it intuitive to use the small sliver of space at the top of the screen.

The keyboard does seem much more stable.

Ed

On Jul 5, 2018, at 4:17 PM, FlickType <@FlickType> 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=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 <@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





Benny Barber
 

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


Chuck Dean
 

Hi Benny,
I slowly slide my finger down until I hear message body.
Chuck

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




Benny Barber
 

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


George Cham
 

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




Benny Barber
 


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




George Cham
 

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




David Nason
 


I'm glad that you are looking to implement a half screen mode. The current build has some problems for me though. 
 Firstly, its too large. I would like to see more of the app screen than I currently can. 
 More importantly, honestly it's a mess when I try to do anything with the top part of the screen. If I put VoiceOver focus up there, I have trouble then swiping to other elements on the screen. 
 If I move the cursor to the start using the VoiceOver double tap method, then start typing in FlickType again, the new text either inserts itself at the end instead of the start, or the first chunk of text I typed is lost altogether. 
 
 What I really want is that if I tap in that app section at the top, VoiceOver will behave perfectly normally, including moving the cursor with the rotor etc. And when I tap in the bottom half of the screen, on the FlickType keyboard, I can then start typing and it will enter the text from where I put the cursor. 
 
 Good first run at it of course, so I look forward to future versions☺️ 
 
 Dave 
 . 


On 6 Jul 2018, at 02:18, George Cham <George.cham@...> wrote:

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




David Nason
 

PS: I am also not seeing text unless I do not perform the switch keyboard gesture.

Dave

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

<mime-attachment.html>

George Cham
 

I think what is happening, the text is being populated in the body of the document, as you type.
But the keyboard needs to be dismissed inorder to review text.
Not sure if this is an iOS issue, or a development feature.

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 David Nason <dnason@...>
Sent: Friday, July 6, 2018 7:53:58 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 132 - Half-screen test
 
PS: I am also not seeing text unless I do not perform the switch keyboard gesture.
 
 Dave
> On 6 Jul 2018, at 10:51, David Nason <dnason@...> wrote:
>
> <mime-attachment.html>



Paul Sutton
 

Hi,
I am starting to notice that FlickType seems to be getting a little sluggish for sung reason and every now and again it seems to be not registering taps.
Kind regards, paul

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


Benny Barber
 

Kosta,

I believe you have heard the basic issues that some are having right now
with the half screen. I just wanted to reiterate my issues.

1. When in the iOS Mail app, I have no problem entering text in the "To",
"CC" and "Subject" fields, but getting focus in the "Message Body" is very
difficult. I try to swipe to it from the subject field, but I end up in
FlickType. I have to do a cumbersome 3 finger flick up in the upper half of
the screen to scroll up and then double tap in the message body. I don't
know if it is the size of the 5S screen or what, but getting to that message
body field is tough.

2. Another major issue is sometimes after typing in FlickType, I tap at the
top of the screen to enter the text that I have typed and nothing happens.
The text will not enter. I have to restart my phone and it will work
properly for a couple of emails and then it doesn't work again. The only
fix is to restart the phone. The only other option is to dismiss the screen
or change keyboards and the text is then entered.

I hope you can find the answers for our issues and thanks for the great app.

Benny

-----Original Message-----
From: alpha@flicktype.groups.io [mailto:alpha@flicktype.groups.io] On Behalf
Of FlickType
Sent: Thursday, July 05, 2018 2:50 PM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Build 132 - Half-screen test

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

Salman Haider
 

I have to agree with Kosta here. About the keyboard size, the smaller
it gets, the more the possibility of accidently tapping above the top
row. It must be noted that many people have no usable vision at all to
help them in visually seeing the boundry (where the keyboard/typing
area ends and the app screen begins). Considering how Flicktype works
(which is, simply tapping in the general vicinity of the letter you
want, rather than touch typing or exploring the keyboard), having a
smaller keyboard size will be less forgiving for such users, rather
than users who have some degree of usable vision to assist them in
determining the boundary of the keyboard area.
For many with no usable vision, the only way to determine where the
iOS keyboard ends for instance, is by exploring the keyboard and since
that is not how Flicktype is supposed to be used (apart from when
manually entering a word), I do think there needs to be a difference
in the sizes of the iOS keyboard and the Flicktype keyboard. Just to
provide some leeway and that slightly extra bit of room for error.
Therefore, I do not agree at all that the keyboard size should be
exactly, or extremely close to the iOS keyboard size, as that
increases the possibility of accidental taps above the keyboard area.
Also keeping in mind that the way it's set up, accidentally tapping
outside the keyboard area will end up entering the text immediately
into the text field, which can cause even more confusion as to where
one is in terms of typing.

I also want to say that a full screen keyboard option as it exists in
its current state should also always continue to be provided for those
who don't find the half-screen keyboard very benefitial, or too
difficult/inconvenient.

Coming back to the keyboard size, maybe a happy medium would be to
provide different options for adjusting the size to suit the users
needs. Like, 60%, 55%, 50% and so on. Without compromizing on any of
the other functionality of the keyboard of course.

Just my thoughts.

Salman

On 7/5/18, FlickType <@FlickType> 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=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 <@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