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