Re: Build 72
Hello,toggle quoted messageShow quoted text
Thank you, Kosta, for yet another FlickType release. I have been taking some time to get accustomed to the new gestures and just to think before writing the group.
First, the introduction of the "next keyboard" button is much appreciated. While I am capable of performing the gestures and would have little problem in doing so if the buttons are removed, I am more comfortable finding a button—especially one so conveniently located. I have removed dictation from the iOS keyboard, which has minimized my tendency to press the wrong button when switching to the FlickType keyboard.
On a related note, having the option to enable/disable the dismiss and next keyboards is great.👍 Kosta's ability to include buttons that a user may optionally utilize provided an idea for how one of my feature requests could be implemented. Before mentioning the request though, I will say that I never use the "dismiss keyboard" feature because it has been a hindrance to editing text and sending messages. Since I want my electronic communications to look as neat as possible, I take time to edit. Frequently, I may want to check how I spelled a word in the middle of a sentence or remove an extra space inserted by FlickType between a symbol such as a quotation mark and a word. The type of editing I perform requires my FlickType cursor position to sync or be transmitted correctly to the iOS system, an experience that has been most convenient when switching as opposed to dismissing keyboards. Switching keyboards with the correct cursor position retained has been problematic in the Notes app. I thought the problem had something to do with how I performed gestures, and while things improved, navigation and editing were more difficult in Notes than in Drafts, Messages, or Mail. Editing with VoiceOver in general is a clunky experience. Still, in the last two FlickType builds, sometimes, after switching keyboards and setting the rotor to navigate by characters or words, VoiceOver repeatedly says "FlickType" or the letter f with each flick until I touch somewhere on the screen, at which point the cursor could be a few words away from the original location. I am wondering if this behavior occurs in longer blocks of text. It is certainly more noticeable. (It was in the middle of this current message; by the end, normal behavior resumed.) My final thought on keyboard dismissal: Dismissing the keyboard in an app like Mail when moving from one field to another might be useful, but I still prefer the switching method. When dismissing FlickType, finding and tapping the "Send” button is impossible without first double tapping the text edit field in the Messages app.
Since Kosta was able to add optional keyboard buttons to FlickType, would creating a "delete" button toggled on or off in FlickType Settings also be possible? I would use a delete function for removing spaces between words and symbols and at the beginning and end of lines. Could we have the option to turn off the Return key at the bottom right of the keyboard. I have just realized that the keyboard might become very cluttered if someone wants all or most of the buttons enabled, so maybe my suggestion isn't practical.
Just as the ability to delete extra spaces or characters with the FlickType keyboard would be useful, I would like to request that reading by characters be reintroduced. The merging of flick and touch typing modes has simplified the FlickType keyboard experience, but I was disappointed when, due to the nature of typing styles being combined, reading by character was eliminated. Eventually adding phonetic feedback for manually typed words and the feature that spells back typing suggestions will hopefully reduce typos (I discovered a few in my emails and texts). Another option, though if the spell back feature is too difficult to develop for the FlickType keyboard, or if most people do not wish to hear their typing spelled back, is a gesture or mode to move/read by character both when reading previously entered text or reviewing FlickType suggestions. In that way, if we are not sure that FlickType said a particular word or one that sounded like it, we would have the means of clarification. In one of my typos, I meant to write the word "link" (l i n k) and somehow got the word "lick" (l i c k). I don't know how the two sounded so similar. Or, when I clearly meant to type the word "there" as in a place, FlickType substituted it with the other "their." These errors aren't too big of a deal, but I don't want to make a habit of them. The annoyance will also diminish once FlickType has context-sensitive autocorrect or whatever we were talking about a while back, but I would still like the ability to read by character, even if the function is not available until after the next app release.
I could do all of my editing using the iOS keyboard if these are not popular feature requests and since switching keyboards is easy. However, if the goal is to eliminate the need for the iOS keyboard, my requests may be worth considering.
On May 27, 2018, at 17:37, Chuck Dean <firstname.lastname@example.org> wrote: