Date   

Re: Build 133

George Cham
 

I’m having the same problem, in  deleteing  a  word however I also am in the habit of flicking  right when in  half screen mode thinking that it will automatically put a space. I would like to see  ability  of flicktyping in half screen mode as Wellers full screen mode

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 Chuck Dean <cadean329@...>
Sent: Saturday, July 7, 2018 5:03:40 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 133
 

 So far, I like the idea. A couple of bugs.
 I couldn't delete while in the half screen mode.
 I am having the same problem with messages, repeated text and those less than and greater than symbols.
 
 
 I'd like to see the ability to move the cursor between fields by flicking. But I like the concept.👍
 
 Chuck

> On Jul 6, 2018, at 11:57 PM, FlickType <hello@...> wrote:
>
> Another experimental build, based on some of the earlier feedback.
>
> - Added a 3-finger flick up and down gesture to switch between fullscreen and standard size modes. Standard size is the same size as the iOS keyboard, and only supports touch typing. The idea is that you would use the standard size mode instead of dismissing the keyboard entirely, and potentially resume fullscreen typing with a 3-finger flick up. The keyboard will commit all changes to the underlying textfield upon entering standard size mode. The keyboard will always default to fullscreen mode when popping up.
>
> Please keep the ideas and thoughts coming, smile!
>
>
>




Re: Build 133

Chuck Dean
 

So far, I like the idea. A couple of bugs.
I couldn't delete while in the half screen mode.
I am having the same problem with messages, repeated text and those less than and greater than symbols.


I'd like to see the ability to move the cursor between fields by flicking. But I like the concept.👍

Chuck

On Jul 6, 2018, at 11:57 PM, FlickType <@FlickType> wrote:

Another experimental build, based on some of the earlier feedback.

- Added a 3-finger flick up and down gesture to switch between fullscreen and standard size modes. Standard size is the same size as the iOS keyboard, and only supports touch typing. The idea is that you would use the standard size mode instead of dismissing the keyboard entirely, and potentially resume fullscreen typing with a 3-finger flick up. The keyboard will commit all changes to the underlying textfield upon entering standard size mode. The keyboard will always default to fullscreen mode when popping up.

Please keep the ideas and thoughts coming, smile!



Build 133

 

Another experimental build, based on some of the earlier feedback.

- Added a 3-finger flick up and down gesture to switch between fullscreen and standard size modes. Standard size is the same size as the iOS keyboard, and only supports touch typing. The idea is that you would use the standard size mode instead of dismissing the keyboard entirely, and potentially resume fullscreen typing with a 3-finger flick up. The keyboard will commit all changes to the underlying textfield upon entering standard size mode. The keyboard will always default to fullscreen mode when popping up.

Please keep the ideas and thoughts coming, smile!


Re: Build 132 half screen keyboard.

Ed Worrell
 

Hey Chanelle,

I would have to agree with everything you just said. I wasn’t sure about the half screen build at first. The current status of the “half screen” keyboard is limiting in my view. I would like to see the keyboard as an option to be half screen or full screen with a toggle or gesture to switch between the two modes. I honestly feel that it the keyboard is closer to the size of the default iOS keyboard the voiceOver rotor gestures for text navigation would be amazing. In it’s current state this is simply not an option. I love the direction it’s going, and I can’t wait to see what happens next with the half screen options.


Ed Worrell
CEO’/Co-Founder: OverHere Consulting LLP
“Bringing Technology into Sight”
www.overhereconsulting.net

On Jul 6, 2018, at 1:34 PM, Chanelle Allen <chanellem.allen@...> wrote:

Hello,
After further testing FlickType,
I have noticed that sadly, my iPhone must be restarted after writing three or four messages/emails for the half-screen keyboard features to work correctly. I experienced the same problems that were reporter yesterday. Text does not get entered into a field unless the keyboard is dismissed, and navigation without dismissing or switching keyboards is difficult. Whether text entry is working or not, using standard VoiceOver rotor gestures to read back text is impossible without dismissing FlickType. I am able to find the area where my cursor is located, but using the rotor gesture or flicking down to read by word/character causes FlickType to either change case, insert additional punctuation, or change a word. In this email, text has been inserted in odd places. I went back to add the word "Hello" to the beginning. I thought VoiceOver confirmed that I was at the top of the document. I am not sure where my cursor was because once I deleted Hello, which seemed to be on the same line as my name at the end of the email, my cursor was back at the beginning of the message. I have an iPhone 7 running the latest version of iOS 11.4.
I was not at all thrilled at the prospect of a half-screen keyboard, but I am excited about the potential it could offer so long as VoiceOver navigation is fluid. Otherwise, going back to switching keyboards and editing from there would be easier.
Chanelle


On Jul 5, 2018, at 17:16, Chuck Dean <cadean329@...> wrote:


Hello,
Try restarting your iPhone. It seems to cure those problems on my phone.
Chuck

On Jul 5, 2018, at 5:13 PM, Chanelle Allen <chanellem.allen@...> wrote:


I am also finding that dismissing or switching to the next keyboard is more useful than taking advantage of the half-screen keyboard. Getting text entered into a field happens most of the time when dismissing the keyboard. When attempting to navigate and enter text by placing a finger above the keyboard, text is either not entered or sections get deleted. Maybe I should reinstall FlickType as Chuck did.
Chanelle

On Jul 5, 2018, at 15:20, Chuck Dean <cadean329@...> wrote:

I use the classic app because I am confident it will work perfectly, not so sure with 132.
No matter what I tried, the only way I could get text into a field was either changing or dismissing the keyboard. As I understand it, I should be able to tap above the FlickType keyboard and the text should be entered. Correct?

I'll go back and try again.
Chuck

On Jul 5, 2018, at 3:13 PM, FlickType <@FlickType> wrote:

Thank you Chuck.

I’m not sure what you mean when you say you cannot get text into a field unless you change or dismiss the keyboard. Has anyone else experienced that?

Regarding text replacements, these can actually be used once I implement them, and are unrelated to how FlickType interacts with the text fields. So that’s good news, smile.

Curious, what’s the main reason you used the classic app to type this?

Thanks,
Kosta

On Jul 5, 2018, at 14:26, Chuck Dean <cadean329@...> wrote:

Build 132 half screen keyboard.
Hello Kosta,
First, I like the half screen keyboard because I can interact with all the fields while sending an email.
I understand this is experimental, but I can not get text into a field unless I change or dismiss the keyboard,. The ability to interact with all text fields without having change the keyboard is paramount to its success.
But you already know that.

The size of the keyboard is fine, smaller may be better.
Typing is just as good as the other keyboards, no lag or stutter.

Its unfortunate that FlickType can't enter the text directly into a text field, this would also allow text replacements to be used.

I was wondering if turning off all typing echo and feedback would stop the stuttering, but a quick test with fleksy told me no.

Obviously, the half screen keyboard is much more complicated than any of us expected. But this shows great promise.

BTW this was typed on FlickType Classic... Old reliable! 😎

Chuck








Re: Build 132 half screen keyboard.

Chanelle Allen
 

Hello,
After further testing FlickType,
I have noticed that sadly, my iPhone must be restarted after writing three or four messages/emails for the half-screen keyboard features to work correctly. I experienced the same problems that were reporter yesterday. Text does not get entered into a field unless the keyboard is dismissed, and navigation without dismissing or switching keyboards is difficult. Whether text entry is working or not, using standard VoiceOver rotor gestures to read back text is impossible without dismissing FlickType. I am able to find the area where my cursor is located, but using the rotor gesture or flicking down to read by word/character causes FlickType to either change case, insert additional punctuation, or change a word. In this email, text has been inserted in odd places. I went back to add the word "Hello" to the beginning. I thought VoiceOver confirmed that I was at the top of the document. I am not sure where my cursor was because once I deleted Hello, which seemed to be on the same line as my name at the end of the email, my cursor was back at the beginning of the message. I have an iPhone 7 running the latest version of iOS 11.4.
I was not at all thrilled at the prospect of a half-screen keyboard, but I am excited about the potential it could offer so long as VoiceOver navigation is fluid. Otherwise, going back to switching keyboards and editing from there would be easier.
Chanelle

On Jul 5, 2018, at 17:16, Chuck Dean <cadean329@...> wrote:


Hello,
Try restarting your iPhone. It seems to cure those problems on my phone.
Chuck

On Jul 5, 2018, at 5:13 PM, Chanelle Allen <chanellem.allen@...> wrote:


I am also finding that dismissing or switching to the next keyboard is more useful than taking advantage of the half-screen keyboard. Getting text entered into a field happens most of the time when dismissing the keyboard. When attempting to navigate and enter text by placing a finger above the keyboard, text is either not entered or sections get deleted. Maybe I should reinstall FlickType as Chuck did.
Chanelle

On Jul 5, 2018, at 15:20, Chuck Dean <cadean329@...> wrote:

I use the classic app because I am confident it will work perfectly, not so sure with 132.
No matter what I tried, the only way I could get text into a field was either changing or dismissing the keyboard. As I understand it, I should be able to tap above the FlickType keyboard and the text should be entered. Correct?

I'll go back and try again.
Chuck

On Jul 5, 2018, at 3:13 PM, FlickType <@FlickType> wrote:

Thank you Chuck.

I’m not sure what you mean when you say you cannot get text into a field unless you change or dismiss the keyboard. Has anyone else experienced that?

Regarding text replacements, these can actually be used once I implement them, and are unrelated to how FlickType interacts with the text fields. So that’s good news, smile.

Curious, what’s the main reason you used the classic app to type this?

Thanks,
Kosta

On Jul 5, 2018, at 14:26, Chuck Dean <cadean329@...> wrote:

Build 132 half screen keyboard.
Hello Kosta,
First, I like the half screen keyboard because I can interact with all the fields while sending an email.
I understand this is experimental, but I can not get text into a field unless I change or dismiss the keyboard,. The ability to interact with all text fields without having change the keyboard is paramount to its success.
But you already know that.

The size of the keyboard is fine, smaller may be better.
Typing is just as good as the other keyboards, no lag or stutter.

Its unfortunate that FlickType can't enter the text directly into a text field, this would also allow text replacements to be used.

I was wondering if turning off all typing echo and feedback would stop the stuttering, but a quick test with fleksy told me no.

Obviously, the half screen keyboard is much more complicated than any of us expected. But this shows great promise.

BTW this was typed on FlickType Classic... Old reliable! 😎

Chuck







Re: Build 132 - Half-screen test

David Nason
 

Hi Salman,

I completely agree that options may be necessary, and certainly that the full screen keyboard must remain available.

The way it is in this experimental build though is essentially useless to me honestly, I may as well just be using the full screen keyboard.
When I want half screen is for example in a message conversation in WhatsApp. I want to be able to read my friend's messages as they come in, and type my own messages. With the current half screen implementation, I cannot do this, as it doesn't really allow me to put VoiceOver focus on the message conversation part of the screen, or to flick down through and read those messages. I have to switch out of FlickType to do this, and so may as well be using the full screen mode.

While I would love to see this kind of half screen keyboard, there are probably other things I would prioritise ahead of it.

Dave

On 6 Jul 2018, at 14:33, Salman Haider <salmanhaider.purdue@...> wrote:

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








Re: Build 132 - Half-screen test

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







Re: Build 132 - Half-screen test

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


Re: Build 132 - Half-screen test

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



Re: Build 132 - Half-screen test

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>




Re: Build 132 - Half-screen test

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>


Re: Build 132 - Half-screen test

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





Re: Build 132 not working well in messages.

Matthew Janusauskas
 

I also experienced this same behavior on an iPhone X.



On Jul 5, 2018, at 6:35 PM, Chuck Dean <cadean329@...> wrote:


Hello,
I tried it again, and I noticed that the text that includes the previous message, will have a greater than and less than symbol before and after the text. I don’t know if this has anything to do with it, but I am not putting that in.
Chuck

On Jul 5, 2018, at 4:27 PM, Chuck Dean <cadean329@...> wrote:

I just kept sending myself messages, and after about the third message it would repeat the message before.
I tried it again, and it’s doing the same thing.
Chuck

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

Thank you Chuck. 

For the repeating text in messages, do you have some simple steps to reliably reproduce?

Thanks,
Kosta 

On Jul 5, 2018, at 16:08, Chuck Dean <cadean329@...> wrote:


But email is working great! 
Chuck 

On Jul 5, 2018, at 4:07 PM, Chuck Dean <cadean329@...> wrote:


Hello Kosta, 
I tried sending myself some text messages and the previous text message would be included in the text message I was sending. Perhaps this was because I was sending to myself, but I have never seen behavior like this before. 
Chuck 













Re: Build 132 - Half-screen test

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





Re: Build 132 half screen keyboard.

Chanelle Allen
 

Restarting did the trick!😀👍 this is very exciting. Maybe the FlickType keyboard could occupy a little less space, but otherwise everything else is great! I had restarted immediately after updating, so perhaps other people need to know that two restarts might be necessary. My second restart was actually a reset where I held down the power and volume down buttons. I will keep testing.

Chanelle

On Jul 5, 2018, at 17:16, Chuck Dean <cadean329@...> wrote:


Hello,
Try restarting your iPhone. It seems to cure those problems on my phone.
Chuck

On Jul 5, 2018, at 5:13 PM, Chanelle Allen <chanellem.allen@...> wrote:


I am also finding that dismissing or switching to the next keyboard is more useful than taking advantage of the half-screen keyboard. Getting text entered into a field happens most of the time when dismissing the keyboard. When attempting to navigate and enter text by placing a finger above the keyboard, text is either not entered or sections get deleted. Maybe I should reinstall FlickType as Chuck did.
Chanelle

On Jul 5, 2018, at 15:20, Chuck Dean <cadean329@...> wrote:

I use the classic app because I am confident it will work perfectly, not so sure with 132.
No matter what I tried, the only way I could get text into a field was either changing or dismissing the keyboard. As I understand it, I should be able to tap above the FlickType keyboard and the text should be entered. Correct?

I'll go back and try again.
Chuck

On Jul 5, 2018, at 3:13 PM, FlickType <@FlickType> wrote:

Thank you Chuck.

I’m not sure what you mean when you say you cannot get text into a field unless you change or dismiss the keyboard. Has anyone else experienced that?

Regarding text replacements, these can actually be used once I implement them, and are unrelated to how FlickType interacts with the text fields. So that’s good news, smile.

Curious, what’s the main reason you used the classic app to type this?

Thanks,
Kosta

On Jul 5, 2018, at 14:26, Chuck Dean <cadean329@...> wrote:

Build 132 half screen keyboard.
Hello Kosta,
First, I like the half screen keyboard because I can interact with all the fields while sending an email.
I understand this is experimental, but I can not get text into a field unless I change or dismiss the keyboard,. The ability to interact with all text fields without having change the keyboard is paramount to its success.
But you already know that.

The size of the keyboard is fine, smaller may be better.
Typing is just as good as the other keyboards, no lag or stutter.

Its unfortunate that FlickType can't enter the text directly into a text field, this would also allow text replacements to be used.

I was wondering if turning off all typing echo and feedback would stop the stuttering, but a quick test with fleksy told me no.

Obviously, the half screen keyboard is much more complicated than any of us expected. But this shows great promise.

BTW this was typed on FlickType Classic... Old reliable! 😎

Chuck







Re: Build 132 - Half-screen test

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





Re: Build 132 - Half-screen test

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





Re: Build 132 - Half-screen test

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



Re: Build 132 - Half-screen test

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





Re: Build 132 - Half-screen test

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