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


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 <hello@flicktype.com> 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



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




 

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


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




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 <hello@flicktype.com> 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



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




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@gmail.com> 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 <hello@flicktype.com> 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




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




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




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 <hello@flicktype.com> 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



 

Thank you all.

Build 65 just went out to the beta group, smile. Aside from any new urgent issues that come up, the next big item is manual input within FlickType, including entering new lines.

Stay tuned!

Kosta

PS: The main app will always remain available, we will elaborate on that soon.


David Nason
 

So I've noticed over the last day or two that I often need to make two attempts at the long press to switch keyboard. Has anyone else experienced this?

On 11 May 2018, at 19:31, FlickType <hello@flicktype.com> wrote:

Thank you all.

Build 65 just went out to the beta group, smile. Aside from any new urgent issues that come up, the next big item is manual input within FlickType, including entering new lines.

Stay tuned!

Kosta

PS: The main app will always remain available, we will elaborate on that soon.



Salman Haider
 

I have to say that I have gotten quite used to the one finger tap and
hold gesture to switch back to the iOS keyboard from FlickType. Being
able to perform all basic functions with one hand/one finger is
definitely paramount for me while using FlickType.

. Obviously, this gesture is going to be changed as manual text entry
gets added to the custom keyboard (as it should).
My question is, can we still have a one finger gesture to switch back
to the iOS keyboard? One that would not interfere with any other
actions or gestures.
A one finger swipe up and hold, or a one finger swipe down and hold
gesture (which in the main app brings up the menu), or, a one finger
double tap and hold, or a one finger triple tap and hold gesture.
In my opinion, incorporating the hold element in whatever gesture is
decided upon for switching keyboards, would be a good way to go about
it.
For inserting a new line, I had suggested a one finger swipe right and
hold gesture. It is something that I believe was implemented in the
old Fleksy back in the day and it seemed to work quite well back then.
Again, something that would still be performed using one hand, and not
interfere with any of the other gestures/actions.
Just some thoughts/suggestions.

Salman

On 5/11/18, David Nason <dnason@gmail.com> wrote:
So I've noticed over the last day or two that I often need to make two
attempts at the long press to switch keyboard. Has anyone else experienced
this?
On 11 May 2018, at 19:31, FlickType <hello@flicktype.com> wrote:

Thank you all.

Build 65 just went out to the beta group, smile. Aside from any new urgent
issues that come up, the next big item is manual input within FlickType,
including entering new lines.

Stay tuned!

Kosta

PS: The main app will always remain available, we will elaborate on that
soon.




--
Muhammad Salman Haider
(765) 586-6840