Re: Update and responses

Chuck Dean

Hi Kosta,
One of the things I like about the app when writing longer pieces, is the ability to leave the app to search for information, then come back and be able to read back what I already wrote. Also, after writing what looks like a screen full of text, I export it to notes to save what I have typed.
And, of course, at this time the app has all the numbers and symbols, plus the ability to enter new lines; which will eventually be working in the custom keyboard soon.
The delay in the spelling I mention is in the app version. Perhaps it was always this long, but it feels longer so, as long as I type at my normal speed I do not hear any interruption.

I'm very impressed with the custom app; the predictive engine is working great and I can type up to speed with this version.
Thanks for the good work!


On May 7, 2018, at 10:17 PM, FlickType <> wrote:

Thank you all for the useful feedback, as always. I really appreciate how quickly it's pouring in after each build, smile.

Back in build 57 I mentioned that your VoiceOver typing feedback settings no longer mattered, but that it came at a cost. I think Alex mentioned something about the keyboard using a buffer and once it's dismissed it drops the text in the field. This is exactly right, and this is how I was able to workaround the issue of VoiceOver interrupting FlickType announcement's. Since no text is actually entered in the field as you type, VoiceOver just stays quiet, patiently waiting for the text to change. Once you either dismiss the keyboard or long tap to the iOS keyboard, FlickType inserts all the typed text in one go. The problem with that is that it leaves some room for cases where text loss might happen, as some of you have experienced. This would happen if you switched to another app while typing, but that should be fixed with build 61. It will still happen if FlickType crashes. On the iPhone X, if you use the dedicated button for the next keyboard instead of a long tap or the gesture to dismiss it, you will also lose the typed text.

The second, separate issue that arises with this delayed updating method is that you often cannot move across sentences. The reason is that iOS will not let FlickType know what exists past the boundaries of the current sentence, unless the actual text field cursor is moved to the beginning or the end of the sentence. Again, this is because no interactions with the text field take place until you are done typing, to avoid triggering VoiceOver due to the underlying cursor moving.

The third issue with the delayed updating only kicks in when the keyboard becomes half screen. Then it will feel really inconsistent since you'll be able to notice that the text is missing from the actual field, at the same time as FlickType below telling you that it exists. And if you happen to be making edits to existing text, you will notice different text existing in the field, and different one within FlickType.

The aforementioned issues will be challenging to overcome, and there's even a chance that some will not be solvable. But I am optimistic. I remind you that at least one alternative I can provide is not delaying the text edits at all, as would be the natural thing to do, at the cost of delayed or stuttering announcements unless you disable VoiceOver's typing feedback. There's a lot more work involved in this area and it's what's currently taking up most of my time, unfortunately.

On the issue of sometimes being unable to change suggestions, this is due to iOS unexpectedly deciding to re-initialize the keyboard. This is solvable in the near future.

On the initial delay reported. Does that only happen once after updating your build, or once for every new app in which you use it, or once every now and then? I have some ideas on improving load time in the near future.

Chuck, a couple of days ago you mentioned: "The stand alone App is also much better suited to handle very long writings such as short stories and book entries. Even when the custom keyboard is fully operational, I intend to continue to use the App version." I would love to hear more about what part of the main app is better, and if your thinking is evolving over time with the custom keyboard slowly improving. Also you mentioned a change in the delay before spelling a word. I have not implemented that in the custom keyboard yet. Were you talking about the main app, or is there a typing feedback option for that which I missed?

Benny, you mention your desire for a raise to read feature. I understand this is important and I am working towards it. I will need to first solve the aforementioned issue of sometimes not being able to move past sentences before I can know the entirety of the document's text. And perhaps a three finger flick and hold could be an appropriate gesture. Also I wonder if being able to navigate all the sentences would make the raise to read feature feel less needed.

Chanelle, you mentioned some pretty weird behavior there. To clarify, are you talking about the main app? And is the custom keyboard working for you? I should inform you here that build 61 is the exact same the previous one, with only an engine accuracy adjustment that should not have any such effect. What device are you using?

On sounds not working or being too loud: all tap sound settings from the main app should work the same way with the custom keyboard. But you might need to restart the device after changing the settings. Alternatively, you can only restart the keyboard by toggling Full Access off and on again.

Michael, you mentioned you are running twelve one beta. Is that correct? I believe iOS 12 beta is not expected until sometime next month.

Final note: the main app will always be available, so that everyone can try out FlickType without the complexities of installing a custom keyboard. So don't worry about it going away, smile.

- Kosta

Join to automatically receive all group messages.