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

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



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



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



Thank you for testing,

Kosta

On 5 Jul 2018, at 20:49, FlickType <hello@flicktype.com> wrote:

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

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

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

Thank you for testing,
Kosta

On Jul 5, 2018, at 1:49 PM, FlickType <hello@flicktype.com> wrote:

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

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

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

Thank you for testing,
Kosta

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

Hi all,

I tried typing the following text into notes to see if I could reproduce the issue that chuck is having.

The quick brown fox jumped.

No problems. The curser moved to the start of the text.

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: Thursday, July 5, 2018 8:58:45 AM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Weird behavior while typing in notes, and journal app

 

👍 

On Jul 4, 2018, at 3:23 PM, FlickType <hello@...> wrote:

Thank you Chuck. I hope at least you don’t lose any text. As I understand it, after dismissing a keyboard, the cursor will move to either the end or the beginning of the document, somewhat unpredictably. So if you keep dismissing and then typing some more, the text is not going to flow the way you might expect. 

Something that might help here is to change the dismiss function to only make flicktype half screen rather than dismiss it entirely, so that the cursor position is preserved. I’m working on the half screen more right now, so we’ll see how that goes. Stay tuned. 

Kosta

On Jul 4, 2018, at 14:48, Chuck Dean <cadean329@...> wrote:

Hello Kosta, 

 While typing in my journal app and in notes I am having text move around and replacing other text after dismissing FlickType. 

 Here is what I typed. 

 

 First line. 

 Second line, go to iOS keyboard. 

Third line. Dismiss FlickType.

Forth line return to FlickType. Now dismiss FlickType again. 

But this is what I ended up with: 

Dismiss FlickType. 

 Forth line return to FlickType. Now dismiss FlickType again. 

 Second line, go to iOS keyboard. 

Third line. Dismiss FlickType. 

Chuck

PS, this is not a recent problem, I have noticed it before but just did not have the time to duplicate the problem.

Thank you Chuck. I hope at least you don’t lose any text. As I understand it, after dismissing a keyboard, the cursor will move to either the end or the beginning of the document, somewhat unpredictably. So if you keep dismissing and then typing some more, the text is not going to flow the way you might expect. 

Something that might help here is to change the dismiss function to only make flicktype half screen rather than dismiss it entirely, so that the cursor position is preserved. I’m working on the half screen more right now, so we’ll see how that goes. Stay tuned. 

Kosta

On Jul 4, 2018, at 14:48, Chuck Dean <cadean329@...> wrote:

Hello Kosta, 

 While typing in my journal app and in notes I am having text move around and replacing other text after dismissing FlickType. 

 Here is what I typed. 

 

 First line. 

 Second line, go to iOS keyboard. 

Third line. Dismiss FlickType.

Forth line return to FlickType. Now dismiss FlickType again. 

But this is what I ended up with: 

Dismiss FlickType. 

 Forth line return to FlickType. Now dismiss FlickType again. 

 Second line, go to iOS keyboard. 

Third line. Dismiss FlickType. 

Chuck

PS, this is not a recent problem, I have noticed it before but just did not have the time to duplicate the problem.

Hello Kosta, 

 While typing in my journal app and in notes I am having text move around and replacing other text after dismissing FlickType. 

 Here is what I typed. 

 

 First line. 

 Second line, go to iOS keyboard. 

Third line. Dismiss FlickType.

Forth line return to FlickType. Now dismiss FlickType again. 

But this is what I ended up with: 

Dismiss FlickType. 

 Forth line return to FlickType. Now dismiss FlickType again. 

 Second line, go to iOS keyboard. 

Third line. Dismiss FlickType. 

Chuck

PS, this is not a recent problem, I have noticed it before but just did not have the time to duplicate the problem.

Hi kosta, 

 

 I am a ios 12 user on a iPhone x. 

On Jul 4, 2018, at 11:54, FlickType <hello@...> wrote:

Thank you, David and Michael. Michael, are you on iOS 11 or 12?

- Kosta

Thank you, David and Michael. Michael, are you on iOS 11 or 12?

- Kosta

On Jul 4, 2018, at 11:05, DaNo crashing no problems whatsoever.
Hi Kosta,

This build is crashing WhatsApp for me.
Its a strange one though. When I open particular message threads, and double tap on the text field in order to type, the app crashes. Other message threads will be just fine.

Its definitely FlickType causing the issue because when I delete it, the crashes stop, and when I install it again, the crashes occur again.


In fact previous builds seem to be doing it too.
I am running iOS 12 beta, which yesterday updated to beta 3, so perhaps that’s related.

Dave

On 4 Jul 2018, at 07:46, FlickType <hello@flicktype.com> wrote:

- Internal changes

On 4 Jul 2018, at 07:46, FlickType <hello@flicktype.com> wrote:

- Internal changes

On Jul 3, 2018, at 10:32 PM, FlickType <hello@flicktype.com> wrote:

Thank you Benny, it's a relief to know that there was no issue with the Search button. For the locking of the screen and the unresponsive keyboard when launched in Safari, has anyone else noticed that?

And what worries me most are the cases of lost text that both Chuck and Benny have reported in the last few builds. If anyone else experiences any text loss please let us know as soon as possible.

Thank you for testing!

- Kosta