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



Join alpha@flicktype.groups.io to automatically receive all group messages.