Date   

Re: Build 132 - Half-screen test

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




Re: Build 132 - Half-screen test

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



Re: Build 132 - Half-screen test

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





Re: Build 132 - Half-screen test

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



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: Weird behavior while typing in notes, and journal app

Ed Worrell
 

Hello Kosta,


A half screen mode sounds great!!! I am having many issues with FlickType locking up the applications I am trying to type in. I am however running the iOS 12 beta 3, that was released on the 3rd of July. This might be the issue as they only started to present themselves after the beta was installed from Apple.

Ed

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.


Re: Weird behavior while typing in notes, and journal app

George Cham
 

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.


Re: Weird behavior while typing in notes, and journal app

Chuck Dean
 

👍 

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.


Re: Weird behavior while typing in notes, and journal app

 

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.


Weird behavior while typing in notes, and journal app

Chuck Dean
 

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.


Re: Build 131

 

Thank you David, I received the WhatsApp crash you sent, but I can't do much with it since it does not include any information about FlickType. The way iOS is structured, keyboards should not be able to crash or interfere with any other app, beyond text editing operations. That said, there could be some iOS bug that in combination with some aspect of FlickType results in this behavior - it wouldn't be the first time iOS misbehaved, smile.

Is there anything you can do on that thread, like clear messages older than a month, for example?

Michael, would be great to know what beta of iOS 12 you are running.

Thanks,
Kosta




Re: Build 131

David Nason
 

Same as me so, assuming you are also on beta 3. I’m also iPhone X.
The thing is it’s one particular message thread, not all of them. Unfortunately it’s one of my best friends who I text quite a lot.
I can’t accurately say when it started because I spent a week or so on iOS 11 on an iPhone 7 after smashing the screen of the iPhone X. I just got it back yesterday, and so think I missed beta 2 altogether.
I had no problem when on iOS 11.

I sent you the file from analytics, at least I think I sent the right one.

Dave



On 4 Jul 2018, at 18:18, Michael Maslo <michaelmaslo04@...> wrote:


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


Re: Build 131

Michael Maslo
 


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


Re: Build 131

 

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


Re: Build 131

Michael Maslo
 

Hello, I just typed several messages in what's app, no problems. No crashing no problems whatsoever.

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 <@FlickType> wrote:

- Internal changes




Re: Build 131

David Nason
 

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 <@FlickType> wrote:

- Internal changes



Build 131

 

- Internal changes


Re: Build 128

Chuck Dean
 

Hi Kosta,
Other than a few red screens, the last few builds have worked well with no text loss.👍
Chuck

On Jul 3, 2018, at 10:32 PM, FlickType <@FlickType> 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



Re: Build 130

 

Thank you George, good catch. The app checks if it's been downloaded from TestFlight or from the App Store, and will point to the beta or the hello address respectively.
- Kosta




On Tue, Jul 3, 2018 at 10:35 PM George Cham <George.cham@...> wrote:
Hi costa,
The email support button in build 130 points to beta@ FlickType. Groups. Io

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 FlickType <hello@...>
Sent: Wednesday, July 4, 2018 3:28:39 PM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Build 130
 
- Added "Email Support" and website buttons at top of Welcome screen.
- Internal changes




Re: Build 130

George Cham
 

Hi costa,
The email support button in build 130 points to beta@ FlickType. Groups. Io

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 FlickType <hello@...>
Sent: Wednesday, July 4, 2018 3:28:39 PM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Build 130
 
- Added "Email Support" and website buttons at top of Welcome screen.
- Internal changes