Date   

Re: Build 64

Chuck Dean
 

 Hi George, I get the same thing, too. The email is always one build behind. 




Chuck

On May 10, 2018, at 8:16 PM, George Cham <George.cham@...> wrote:

When I got the TestFlight notification, it said build 63, but I got64.  So far, working ok. l

Kind Regards,

George Cham



From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@...>
Sent: Friday, May 11, 2018 1:04:42 PM
To: Alpha
Subject: [FlickType-alpha] Build 64
 

So far, so good. I have only been using this build for a few minutes but all is working very well.


Chuck



Re: Build 64

George Cham
 

When I got the TestFlight notification, it said build 63, but I got64.  So far, working ok. l

Kind Regards,

George Cham



From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@...>
Sent: Friday, May 11, 2018 1:04:42 PM
To: Alpha
Subject: [FlickType-alpha] Build 64
 

So far, so good. I have only been using this build for a few minutes but all is working very well.


Chuck



Build 64

Chuck Dean
 

So far, so good. I have only been using this build for a few minutes but all is working very well.


Chuck


Re: Potential beta release, and other responses

Benny Barber
 

Manual input of non dictionary words, numbers and symbols would be at the top of my list. Next would be the ability to enter a new line. Thanks.

On May 10, 2018, at 4:34 PM, FlickType <@FlickType> wrote:

Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta



Re: Build 63 tap volume in main app very low.

Michael Maslo
 

Hi Sharon, what phone are you using this on? I have the iPhone ten and have not had that issue in a very long time.

On May 10, 2018, at 19:32, Sharon Kim <sharon.mi.kim22@...> wrote:

Hello all,
Okay so the flicking issue has returned in all it's former glory.
What I mean by this is, I can tap out a word, flick right, and get...
nothing!!! Sometimes I have to flick right really hard to get
anywhere. What I usually end up doing is, flicking left, to delete all
taps, then tapping out the word again, and flicking right. I'm not
sure what's causing this issue, but it is no good.
This issue persists on the custom keyboard, I am unsure about the main app.
Let me know if there is anything else you need from me.
Thank you all, and have a lovely day.

On 5/10/18, Chanelle Allen <chanellem.allen@...> wrote:

Hello,
I have been using the custom keyboard much more because the volume has been
lower although I attributed this behavior to turning on stereo effect again,
which diminishes the volume. Sound settings seen just like low vision
settings; everyone has different needs or preferences. Is it possible to
create a version of FlickType that gives users further customization of
volume? If not, one thing I have done is raise the VoiceOver volume (I have
added volume to my rotor) while pressing on the volume down button on the
side of my iPhone. Anyone who wishes to hear FlickType at a louder volume
would do the reverse (set the rotor to volume, flick down to quiet VoiceOver
if desired and increase the loudness of the phone).
Just a thought.
Chanelle

On May 10, 2018, at 10:46, Chuck Dean <cadean329@...> wrote:


I set the Effects Playback Mode, to Customizable.
I set the Effects Playback Mode, to Customizable.
It is better, but still seems a little quiet for one hundred percent.


Chuck

On May 10, 2018, at 8:33 AM, Chuck Dean <cadean329@...> wrote:


Actually, the tap sounds are also low in the custom keyboard, too. I have
tried every setting and I restarted my iPhone.


Chuck

On May 10, 2018, at 7:43 AM, Chuck Dean <cadean329@...> wrote:

Build 63 tap volume in main app very low.
Hi Kosta,
The tap sound volume is very low while using the main app. I have set it
at 100% and I can hardly hear the taps.
Outside the app click sounds are normal.



Chuck





Re: Build 63 tap volume in main app very low.

Sharon Kim
 

Hello all,
Okay so the flicking issue has returned in all it's former glory.
What I mean by this is, I can tap out a word, flick right, and get...
nothing!!! Sometimes I have to flick right really hard to get
anywhere. What I usually end up doing is, flicking left, to delete all
taps, then tapping out the word again, and flicking right. I'm not
sure what's causing this issue, but it is no good.
This issue persists on the custom keyboard, I am unsure about the main app.
Let me know if there is anything else you need from me.
Thank you all, and have a lovely day.

On 5/10/18, Chanelle Allen <chanellem.allen@...> wrote:

Hello,
I have been using the custom keyboard much more because the volume has been
lower although I attributed this behavior to turning on stereo effect again,
which diminishes the volume. Sound settings seen just like low vision
settings; everyone has different needs or preferences. Is it possible to
create a version of FlickType that gives users further customization of
volume? If not, one thing I have done is raise the VoiceOver volume (I have
added volume to my rotor) while pressing on the volume down button on the
side of my iPhone. Anyone who wishes to hear FlickType at a louder volume
would do the reverse (set the rotor to volume, flick down to quiet VoiceOver
if desired and increase the loudness of the phone).
Just a thought.
Chanelle

On May 10, 2018, at 10:46, Chuck Dean <cadean329@...> wrote:


I set the Effects Playback Mode, to Customizable.
I set the Effects Playback Mode, to Customizable.
It is better, but still seems a little quiet for one hundred percent.


Chuck

On May 10, 2018, at 8:33 AM, Chuck Dean <cadean329@...> wrote:


Actually, the tap sounds are also low in the custom keyboard, too. I have
tried every setting and I restarted my iPhone.


Chuck

On May 10, 2018, at 7:43 AM, Chuck Dean <cadean329@...> wrote:

Build 63 tap volume in main app very low.
Hi Kosta,
The tap sound volume is very low while using the main app. I have set it
at 100% and I can hardly hear the taps.
Outside the app click sounds are normal.



Chuck




Re: Custom keyboard versus main app #poll

Chuck Dean
 

Hi Michael,
Once the custom keyboard is fully featured, the standalone app will still be necessary to make adjustments. Such as volumes of the taps, tap sounds, and exporting the dictionary.
Also, costa promised us that he would never get rid of the standalone app. Some of us who grew up on fleksy VO, really love that app, and I want to make sure that it’s back there in my toolbox, with all my weird wrenches, in case I need it. 😎 


Chuck

On May 10, 2018, at 5:07 PM, Michael Maslo <michaelmaslo04@...> wrote:

Chuck, that is why we both are different. I did not understand though your comparison between wrench and a keyboard. I agree that multiple tools may do the same thing but when it is directly the same application I do not see the purpose. As said, right now it is not ready for it to be a stand alone now, when the rest of the featured are implemented, meaning it has the ability to do manual input, number input, new lines, etc., I do not see the purpose of two keyboards from the same developer doing the exact same thing. Again chuck, I respect what you are saying and your opinions and like my mom said, people sometimes agree to disagree. This is one of those situations. Take care.

Sincerely,, mike 


On May 10, 2018 at 18:59, <Chuck Dean> wrote:

I respectfully disagree. I restore antique micro cars; and I have many different types of wrenches that will do the same job. However you can never have too many tools, and you never know when you might need that weird one. 



Chuck

On May 10, 2018, at 4:52 PM, Michael Maslo <michaelmaslo04@...> wrote:

I just responded to the poll. My hope is when the custom keyboard is released that the application is removed. I see no use of having both around. The custom keyboard once complete will dominate use and I see no purpose of it. I use the custom keyboard ninety nine percent of the time and the other one percent I use the apple keyboard. I do not and have never have used the main application since the custom keyboard was released. In my opinion also it is harder to maintain two applications when only one is needed. This is my personal opinion bind you.

Sincerely,, mike 


On May 10, 2018 at 16:04, <FlickType> wrote:

A new poll has been created:

We know there are still severe limitations with the custom keyboard, but we'd like to better understand exactly how useful it is for you in its current state.

So the burning question is: which do you use more, the custom keyboard or the main app?

1. The custom keyboard
2. The main app
3. About the same

Vote Now


Re: Custom keyboard versus main app #poll

Michael Maslo
 

Chuck, that is why we both are different. I did not understand though your comparison between wrench and a keyboard. I agree that multiple tools may do the same thing but when it is directly the same application I do not see the purpose. As said, right now it is not ready for it to be a stand alone now, when the rest of the featured are implemented, meaning it has the ability to do manual input, number input, new lines, etc., I do not see the purpose of two keyboards from the same developer doing the exact same thing. Again chuck, I respect what you are saying and your opinions and like my mom said, people sometimes agree to disagree. This is one of those situations. Take care.

Sincerely,, mike 


On May 10, 2018 at 18:59, <Chuck Dean> wrote:

I respectfully disagree. I restore antique micro cars; and I have many different types of wrenches that will do the same job. However you can never have too many tools, and you never know when you might need that weird one. 



Chuck

On May 10, 2018, at 4:52 PM, Michael Maslo <michaelmaslo04@...> wrote:

I just responded to the poll. My hope is when the custom keyboard is released that the application is removed. I see no use of having both around. The custom keyboard once complete will dominate use and I see no purpose of it. I use the custom keyboard ninety nine percent of the time and the other one percent I use the apple keyboard. I do not and have never have used the main application since the custom keyboard was released. In my opinion also it is harder to maintain two applications when only one is needed. This is my personal opinion bind you.

Sincerely,, mike 


On May 10, 2018 at 16:04, <FlickType> wrote:

A new poll has been created:

We know there are still severe limitations with the custom keyboard, but we'd like to better understand exactly how useful it is for you in its current state.

So the burning question is: which do you use more, the custom keyboard or the main app?

1. The custom keyboard
2. The main app
3. About the same

Vote Now


Re: Potential beta release, and other responses

Chuck Dean
 

 Out of curiosity I wanted to my dictionary on the FlickType app, which by the way you can’t do with the custom keyboard, and checked out my dictionary entries. I have 184 words that I have entered, and of those 184 words 105 of them are capitalized. Over half the words that I entered into my dictionary are proper names. If we have manual input, with no capital letter, less than half of the words that I put in my dictionary word would be able to be put in. For me, a capital letter is probably the most important feature at this time.


Chuck

On May 10, 2018, at 4:58 PM, Michael Maslo <michaelmaslo04@...> wrote:

To me the most important thing is manual input. With manual input I can add to the dictionary, add numbers and symbols etc. There is no contest for me with manual input. After that and very long in comparison would be the ability to add a line. Again my opinion only.

Sincerely,, mike 


On May 10, 2018 at 16:34, <FlickType> wrote:

Hi all, and thank you for the insightful comments.


Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta




Re: Custom keyboard versus main app #poll

Chuck Dean
 

I respectfully disagree. I restore antique micro cars; and I have many different types of wrenches that will do the same job. However you can never have too many tools, and you never know when you might need that weird one. 



Chuck

On May 10, 2018, at 4:52 PM, Michael Maslo <michaelmaslo04@...> wrote:

I just responded to the poll. My hope is when the custom keyboard is released that the application is removed. I see no use of having both around. The custom keyboard once complete will dominate use and I see no purpose of it. I use the custom keyboard ninety nine percent of the time and the other one percent I use the apple keyboard. I do not and have never have used the main application since the custom keyboard was released. In my opinion also it is harder to maintain two applications when only one is needed. This is my personal opinion bind you.

Sincerely,, mike 


On May 10, 2018 at 16:04, <FlickType> wrote:

A new poll has been created:

We know there are still severe limitations with the custom keyboard, but we'd like to better understand exactly how useful it is for you in its current state.

So the burning question is: which do you use more, the custom keyboard or the main app?

1. The custom keyboard
2. The main app
3. About the same

Vote Now


Re: Potential beta release, and other responses

Michael Maslo
 

To me the most important thing is manual input. With manual input I can add to the dictionary, add numbers and symbols etc. There is no contest for me with manual input. After that and very long in comparison would be the ability to add a line. Again my opinion only.

Sincerely,, mike 


On May 10, 2018 at 16:34, <FlickType> wrote:

Hi all, and thank you for the insightful comments.


Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta




Re: Custom keyboard versus main app #poll

Michael Maslo
 

I just responded to the poll. My hope is when the custom keyboard is released that the application is removed. I see no use of having both around. The custom keyboard once complete will dominate use and I see no purpose of it. I use the custom keyboard ninety nine percent of the time and the other one percent I use the apple keyboard. I do not and have never have used the main application since the custom keyboard was released. In my opinion also it is harder to maintain two applications when only one is needed. This is my personal opinion bind you.

Sincerely,, mike 


On May 10, 2018 at 16:04, <FlickType> wrote:

A new poll has been created:

We know there are still severe limitations with the custom keyboard, but we'd like to better understand exactly how useful it is for you in its current state.

So the burning question is: which do you use more, the custom keyboard or the main app?

1. The custom keyboard
2. The main app
3. About the same

Vote Now


Re: Potential beta release, and other responses

Chanelle Allen
 

Actually, I agree with chuck. The ability to enter a new line on the FlickType keyboard is a top priority for me. I guess that I was not fully considering everything about the FlickType app in my last message. ☺️

On May 10, 2018, at 17:27, Chuck Dean <cadean329@...> wrote:



The two things I miss when using the custom keyboard are the ability to capitalize a word and the insert a new line gesture or key. I can always go back to the app to enter a word in the dictionary, but I have to edit, after the fact, with new lines and caps using the iOS keyboard.


Chuck

On May 10, 2018, at 2:34 PM, FlickType <@FlickType> wrote:

Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta




Re: Potential beta release, and other responses

Chanelle Allen
 


Hi Kosta,
I have no idea how direct touch remained disabled on my phone even after several reinstalls of FlickType. I use touch typing and not direct touch typing, but maybe as you say, it conflicts with FlickType in some way.
As for manual entry priorities, I would like to be able to enter numbers and symbols. My next choice would be word entry with or without the ability to add to the custom dictionary.
The introduction on the FlickType keyboard wiki page is well written.
Chanelle

On May 10, 2018, at 17:17, David Nason <dnason@...> wrote:


Hi Kosta,

I haven't seen any crashes lately, it's been very stable.

In terms of your priority question, it's a close call between wanting to enter numbers and non dictionary words.
Emoji is very important to me too, but the above two are of higher priority I would say.

Dave


On 10 May 2018, at 23:07, George Cham <George.cham@...> wrote:

hi Coster, in regards to build 62, I referred to the    two white bars at the top and bottom Rose were no   longer there and there was only one bar in the top part which is completely black. In regards to the other issue what I was referring to being the default keyboard was instead of having the iOS keyboard on every app that you bring up is it possible for Flick Type to replace the iOS keyboard instead of having to switch through to the Flick Type keyboar

Kind Regards,

George Cham



From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@...>
Sent: Friday, May 11, 2018 7:34:17 AM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Potential beta release, and other responses
 
Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta




Re: Potential beta release, and other responses

Chuck Dean
 

The two things I miss when using the custom keyboard are the ability to capitalize a word and the insert a new line gesture or key. I can always go back to the app to enter a word in the dictionary, but I have to edit, after the fact, with new lines and caps using the iOS keyboard.


Chuck

On May 10, 2018, at 2:34 PM, FlickType <@FlickType> wrote:

Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta



Re: Potential beta release, and other responses

David Nason
 


Hi Kosta,

I haven't seen any crashes lately, it's been very stable.

In terms of your priority question, it's a close call between wanting to enter numbers and non dictionary words.
Emoji is very important to me too, but the above two are of higher priority I would say.

Dave


On 10 May 2018, at 23:07, George Cham <George.cham@...> wrote:

hi Coster, in regards to build 62, I referred to the    two white bars at the top and bottom Rose were no   longer there and there was only one bar in the top part which is completely black. In regards to the other issue what I was referring to being the default keyboard was instead of having the iOS keyboard on every app that you bring up is it possible for Flick Type to replace the iOS keyboard instead of having to switch through to the Flick Type keyboar

Kind Regards,

George Cham



From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@...>
Sent: Friday, May 11, 2018 7:34:17 AM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Potential beta release, and other responses
 
Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta




Re: Custom keyboard versus main app #poll

Chuck Dean
 

Depends on what I’m using for. If I’m writing something short and quick, I use the custom keyboard. If I need to write something long, that’s going to half words that are not in the dictionary, numbers etc. I use the app. Right now, I’m using dictation. Go figure!


Chuck

On May 10, 2018, at 2:04 PM, FlickType <hello@...> wrote:

A new poll has been created:

We know there are still severe limitations with the custom keyboard, but we'd like to better understand exactly how useful it is for you in its current state.

So the burning question is: which do you use more, the custom keyboard or the main app?

1. The custom keyboard
2. The main app
3. About the same

Vote Now


Re: Potential beta release, and other responses

 

Chanelle, thank you for that. I am very aware of Direct Touch, and in fact FlickType uses that. What I am not aware of is a system-wide way to disable the feature. Hope that makes sense. I am also aware of Direct Touch typing, but I assume this only applies to the iOS keyboard. But perhaps Direct touch typing somehow interferes with FlickType under some rare circumstances.

George, what do you think of the new colors? As for setting FlickType to be the only keyboard, that is definitely possible. You can remove the default English US keyboard from the keyboards list under Settings, General, Keyboard, Keyboards. But you probably need to wait for manual input mode in FlickType before you can do that.

Kosta


Re: Potential beta release, and other responses

George Cham
 

hi Coster, in regards to build 62, I referred to the    two white bars at the top and bottom Rose were no   longer there and there was only one bar in the top part which is completely black. In regards to the other issue what I was referring to being the default keyboard was instead of having the iOS keyboard on every app that you bring up is it possible for Flick Type to replace the iOS keyboard instead of having to switch through to the Flick Type keyboar

Kind Regards,

George Cham



From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@...>
Sent: Friday, May 11, 2018 7:34:17 AM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Potential beta release, and other responses
 
Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta




Re: Potential beta release, and other responses

Chanelle Allen
 

Hi Kosta,
Direct touch typing is actually different from direct touch (sorry for the confusion; it wasn't my idea ☺️). Direct touch is used in apps where VoiceOver's normal gestures are suspended. For example, manys self-voicing games have direct touch on by default. I am not sure if direct touch puts VoiceOver in a mode where regular iOS gestures or gestures used in a particular app are allowed to pass through. The feature may be more extensive than what I am describing. If I find anything on Apple or AppleVis, I will let you know.
Chanelle

On May 10, 2018, at 16:34, FlickType <@FlickType> wrote:

Hi all, and thank you for the insightful comments.

Regarding a potential release to beta, there is no right and wrong answer here since software quality is hard to objectively measure, let alone for shipping something to beta rather than an actual release. But I believe setting the right expectations and using the right wording in our announcement can bring all of the benefits of an extended pool of testers with almost none of the drawbacks. In particular, the biggest benefit will be ensuring that we are always working on the most impactful work item, rather than get sidetracked with a potentially lower priority item that might just have happened in a smaller group by chance. To that end, I have further updated the wiki page to include the appropriate introduction, as well as order the known issues according to a rough estimate of importance to users. I'd love to hear your thoughts on this, in particular on what should be at the very top of the list. It's currently manual input mode, and if that does become the next main thing to work on, I'd also love to better understand what the most common use case is so I can better design it around that. For example, is it a non-dictionary word? Is it numbers? Symbols? Emoji? Text replacement shortcuts? Link to the wiki page: https://flicktype.groups.io/g/alpha/wiki/FlickType-custom-keyboard

Michael, Shinji, and Matthew, thank you for offering to help. I have now added you as moderators to the beta group.

I'd also like to hear if anyone has been experiencing any crashes with build 63. I do get some crash reports back from TestFlight, but it's hard to tell what is due to iOS issues or bugs and what is due to my own code, as well as how much of a user impact these crashes have. For example, if the keyboard crashed and restarted while you were not using it, you probably won't even notice. So, is stability an issue right now, or not?

Below are some responses to your earlier points and questions:

- FlickType not correcting spelling errors: definitely a known issue, I have some ideas on how to tackle it but it would need a full rewrite of the internal correction engine which is months away. Ultimately, FlickType will probably always expect the input to be spelled better than other keyboards, on average, but I do think there are ways to improve the current situation significantly.
- Direct touch issue reported by Chanelle and a couple of others in the past: I am not aware of an option to toggle "Direct touch" in general, but I'm assuming this refers to the "Direct touch typing" option which in general does not seem to not affect FlickType. If anyone has a reliable way to actually reproduce the problem, rather than how to get out of it, I'd love to know the steps so I can investigate.
- Lack of read back function: hopefully sentence navigation using the cursor can help as a workaround for now. Flick left or right with 3 fingers. Sometimes you might not be able to move past sentence boundaries though, particularly after switching to the iOS keyboard. Once manual entry is supported right from within FlickType, this should almost never happen.
- Matthew reporting an issue with the Zoom number field: it's strange that the tap & hold didn't work, I will try to reproduce it, thanks. FlickType does lack a number keypad which should be the one to automatically popup in that case, and this should be addressed soon. It's also actually a requirement by Apple, before we release to the App Store.
- Having multiple keyboards such as FlickType, the standard iOS keyboard, as well as the emoji keyboard, can make the keyboard switching erratic due to iOS issues. It should not be long before emojis are built right into FlickType, as well as manual entry mode, so eventually this should not be a problem.
- George, you mentioned: "Was just listening to eyes on success and FlickType. I then started thinking, is it possible to make FlickType the The Default keyboard?" What did you mean by that exactly?
- Also George, on build 62, you said: "Wow! That's a big change." Were you referring to the new keyboard colors, or was it something else?
- Chuck, on gestures to alternate between keyboards: FlickType can only control the gesture that you use to advance to the next keyboard, whichever keyboard that may be in the list of installed keyboards. Once you are out of FlickType, there is nothing we can do to affect the behavior of other keyboards, including how to switch to the next keyboard again. Also note that there is no API for switching to the previous, rather than next keyboard. However, once symbols, numbers and emoji are added right into FlickType, we can control the entire experience, including doing something similar to what you are suggesting.
- Tap volume issues: this definitely sounds solvable (pun intended). But I think there's a few other items we need to tackle before that. Thank you for the feedback, and hopefully the discovered workarounds can be shared with others if needed.
- On having to add a space when switching back to the iOS keyboard: that might sometimes not be desired, and in fact we've had requests asking that we do not leave a trailing space at the end of your typing sessions. Hopefully this won't matter soon when you no longer need to switch to the iOS keyboard apart from when you are completely done with composing your text.
- I updated the wiki page to include some missing known issues, such as lack of capitalization control and the inability to enter a new line.

Thank you,
Kosta