Kosta,toggle quoted messageShow quoted text
I'll reply to your comment to me in the below message and send another post with my comments on build 1.1-54.
I might get accidental flick lefts with the main app although I'm not hearing words being deleted which I would expect a flick left would cause. What I do experience quite frequently with the main app is typing a word with several letters especially when some of those letters are to the left of the keyboard but getting a response when I flick right of a word with only a letter or two. I seem to hear cap I a lot when I've typed a word of several characters. Go figure.
I'll post more comments with my build 54 message.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of FlickType
Sent: Wednesday, May 02, 2018 6:08 PM
Subject: [FlickType-alpha] Responses
Thank you all for the very useful feedback.
Glad to hear that at least some of you like the cursor control, I think it will come in very handy when writing more than a couple of sentences. I do want to clarify though, that we will currently not be attempting to incorporate such new features into the main app. The codebase of the main app is very, very messy and it has been extremely time-consuming so far to make the smallest of changes, or even fix important bugs. As an example, the previous issue of lost feedback when manually typing took two weeks to fix. So the current focus will remain on the custom keyboard, so that in time you will truly prefer to use that versus the current standalone app, unless we hit some truly fundamental issue that is a total blocker - hopefully we won't hit any such issue but we need to find out sooner than later.
With build 54, I'd love to know if all voice feedback issues that were present in build 53 are now resolved, with the exception of some annoying delay. Also feedback should not depend on any VoiceOver settings now so you shouldn't worry about what your settings are. And if build 54 did in fact solve any such issue for you, please let me know explicitly so I can better understand the impact of the code changes. The delay is a known and challenging issue, partly because even the same code as in the main app just doesn't work the same when running inside a custom keyboard. When making any edits to the underlying textfield, VoiceOver wants to make its own announcements which interfere with the announcements that FlickType wants to make. My current workaround has been to add a slight delay so that FlickType will interrupt any system announcement just as it's about to begin, and ensure that our announcement is what gets to be read out aloud instead. This way we can have full control of the experience and not depend on any VoiceOver kinks. Obviously this is not ideal given the delay, so I will have to investigate and figure out another workaround, but it's critical to know whether beyond the delay you now get the appropriate feedback in all cases.
On the displayed letters being too big, and the keyboard indicator rows being too white / too bright: our focus is on blind users, slowly expanding into low-vision users without ever crossing the line into the sighted market. As such, it's natural that besides blind users, the level of vision that we'd cater to first would be the lowest possible, hence the gigantic font and extreme contrast. That said, I do agree that even for that case we could probably go with slightly less contrast on the white keyboard rows, and perhaps even offer some option to customize those aspects for people that really want to change them. For anyone that feels that the word letters are too large, I'd love to hear if this is an actual problem for you or if you simply feel it's unnecessary for you. Also if you prefer the previous text view that including all the typed text, I'd love to understand the reasoning behind it, assuming you can't read the actual letters.
On the keyboard initially freezing for a few seconds, or getting memory warnings: please let me know how many of you have experienced that, if it seems to happen every time, and if restarting your device seems to make any difference. Also note that operating smoothly under the tight iOS keyboard memory limits on lower-end devices will likely be an ongoing challenge. This should be resolved when we do a full re-write of the word recognition engine, but that is probably many months out. Please make sure you have included the most up-to-date information under your profile in this group with your device model and iOS version, so we can spot any potential patterns on reported issues.
Being able to type your existing dictionary words is coming soon, and before manual typing arrives.
Sometimes being unable to change the suggestion is a known issue and should also be addressed soon. This mostly happens when you go back to edit previously typed sentences.
Sometimes hearing "space" when flicking down: this is a known issue and will be fixed soon. In fact, I will introduce a slightly different type of cursor that will mimic the VoiceOver cursor. In the current main app, the currently active word that will be changed on flick down is the one right before the cursor. But since you can now move the cursor from within the custom keyboard, I believe that when you move it at the beginning of word and you hear that word aloud, flicking up or down should change that word instead of always the previous one. Again, this would be a slight departure from the main app, but I think it will be more intuitive and with it the "space" issue that you are currently experiencing should go away.
You might have noticed that there are often more suggestions available than in the main app. The underlying word recognition engine provides a lot of suggestions, and the main app limits that to something like 7. I just didn't add any limit to the custom keyboard yet, but I might have to for the same reason the main app has it: sometimes it might be worse for you to keep thinking that your word will come up with the next flick down, versus deleting and retyping it.
Alan: unintended "clear taps" might be due to currently using the stock iOS gesture recognizers which can interpret two taps in quick succession as a flick in the direction of the line from the first tap to the second one, if the taps are too close but also far enough to cross the flick distance threshold. I expect this should eventually be addressed with the upcoming new gesture recognition code, which should behave very similarly, if not identical to the main app. Do you ever get accidental flick lefts with the main app? Or any accidental flicks in general?
Ed: understood on some single finger gestures being similar, which may be accidentally triggered by some people. Thanks for the feedback.
Alex & Paul, regarding regressions in the main app: there have been no changes that should affect the main app in any way, but there's always a chance I messed up somewhere. Can you please confirm that the issue you are experiencing doesn't happen with the App Store build? There's also a chance your experience is affected by the 11.3 or 11.3.1 iOS updates, please let me know if you recently updated.
Honoring tap sound & haptic settings: please make sure you run the main app at least once in order for the settings to carry over. Settings carrying over is still a bit finicky but it seems to work for most people.
George, can you please elaborate on your following point? "I ve noticed, with this latest build if you type a word he, then swipe left to delete the word remains, if you swipe again its deleted". Do you mean the word remains on the screen, or that it does not get deleted from the text until you flick left again? Note that when deleting, the visual announcement area will display the deleted word in red instead of the usual white, to indicate a deletion without making the text any smaller as would be the case if it displayed something more elaborate like "deleted tomorrow".
Finally, just a reminder that other than the underlying word recognition engine, this is a brand new keyboard developed entirely from scratch. The manual typing mode is definitely coming, and will likely be a tap and hold, just like with the main app. Similarly for accessing a numbers and symbols layout. Currently, there is literally no keyboard with buttons in the typical sense, hence why it will take a bit of time to do this. It is not a matter of bringing anything back, but rather a matter of re-creating those things. It might feel inefficient to re-create existing things, but given the poor quality of the old codebase I am confident that this extra effort will more than make up for the initial delay in getting things up and running, by making it so much easier to keep enhancing and extending the custom keyboard in the future.
Thank you all,