Date   

Kosta and Ashley Re: [FlickType-alpha] Build 53

Benny Barber
 

Kosta and Ashley,

I have not seen you respond to an issue that Michael Maslo and I have reported. We are not getting any verbal feedback on the finger flick right and left to move by sentence. I hope you can address this issue. I am on a 5s running 11.3.1. Thanks so much for your help.

Benny

On May 1, 2018, at 9:52 PM, FlickType <hello@flicktype.com> wrote:

This took longer than expected. Changes since the previous build:

- This is a major rewrite. Among other differences, the previous build would only change the underlying textfield when you exited the FlickType keyboard, not while you typed. FlickType will now immediately perform all edits in the current field, such as inserting, deleting or changing words. This paves the way for an optional half-screen mode in the near future.
- Reduced memory consumption to address crashing. Unfortunately iOS only allows very little active memory for keyboards compared to regular apps, and aggressively terminates any keyboard that crosses the threshold.
- You now also need to enable "Full Access" in the FlickType settings under the iOS settings app. This is for FlickType to be able to play any sound effects such as taps. The previous method of playing taps was using a private API and was likely to be rejected if submitted to the App Store. Currently, if you don't enable "Full Access" the keyboard will crash. This is a good opportunity to share our very short privacy policy: http://www.flicktype.com/privacy
- If you have some pending taps and flick left to delete, FlickType will now announce "Cleared taps" instead of deleting the previous word.
- You can now move the cursor and navigate the entire current document, not just the current sentence. This should make it more usable for writing longer pieces of text.
- Added a visual keyboard indicator for low-vision folks, in the form of 2 horizontal white bars representing the top and bottom rows.
- Introducing the FlickType "visual announcements", designed to better help low-vision and hearing-impaired folks use the product. All VoiceOver typing announcements for inserting, deleting and changing words will now also be displayed as high-contrast text using the largest possible font size that fits the entire screen above the keyboard area. This replaces the text view that was previously used for debugging.
- The gesture to dismiss the keyboard has been changed to a 3 finger flick down.

We are both really looking forward to hearing what you all think, smile!

Warmly,
Kosta & Ashley



Re: Build 54

 

First, I'm running build 1.1.-54 on an iPhone 7 running iOS 11.3.1.

The issue I reported under version 53 with the first word spoken when
flicking right after entry sounding muddy or at a lower volume has been
resolved. I have to agree with Chuck that the custom keyboard seems sluggish
and less forgiving. The predictive engine seems more accurate and faster in
the original FlickType app or either my typing accuracy has declined with
the system wide keyboard. I'm not really paying any attention to the size of
the displayed characters but they are large enough that I can make them out
if need be. I just won't be using the visual aspects very often. My biggest
issue is that I'm still not getting all available punctuation when flicking
down after a period is entered. I get a comma but nothing else. And the
worse of it is that what I've typed also disappears after I get the nothing
punctuation. When I do a 2 or 3 finger swipe left, I hear beginning of
document. This punctuation snafu seems to be causing the lloss of what I've
previously typed. I've not heard of this from anyone else so maybe I'm an
unfortunate party of one.

Alan Lemly

-----Original Message-----
From: alpha@flicktype.groups.io [mailto:alpha@flicktype.groups.io] On Behalf
Of Chuck Dean
Sent: Wednesday, May 02, 2018 11:40 AM
To: Alpha
Subject: [FlickType-alpha] Build 54

Build 54
Hello, the period is now announced. Thank you.
The custom keyboard seems sluggish to me and much less forgiving. I need to
be much more accurate with my taps, especially with letters on periphery;
for example, the w, p, l, and a. Perhaps this is my particular way of
typing, but I am slower on the custom keyboard than the app.

Even though I have some vision I find that I do not look at the words
appearing on the screen at all. My focus is on the key position, and since
the letters are announced there is no need for eye balling. Personally, I'd
rather be able to see the app I am typing in, so I look forward to the
option of a half screen keyboard.
Keep up the good work!


Chuck


Re: Responses

 

Kosta,

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.

Alan Lemly

-----Original Message-----
From: alpha@flicktype.groups.io [mailto:alpha@flicktype.groups.io] On Behalf Of FlickType
Sent: Wednesday, May 02, 2018 6:08 PM
To: alpha@flicktype.groups.io
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.

Full access will not be necessary when we launch to the App Store, but will be required for sound effects as per the Apple guidelines. However, most builds that go to the alpha and beta groups will likely require full access and not work unless it's turned on, so that we can better understand how people use the keyboard using our analytics service. Adding some analytics features in the custom keyboard is planned for sometime this week. Please check our very short privacy policy here for more information: http://www.flicktype.com/privacy

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,
Kosta


Re: Responses

Alex Hiironen <l000b2a@...>
 

Hey Kosta,

I'm running iOS 11.3, but have been for a week or so already with no issues in the main app regarding the keyboard being on one half of the screen bug. Either way, this is an issue with build 54 also.
The app store build is not exhibiting this issue. Everything works fine there.



Regarding the global/ other apps keyboard, I am also getting no feedback with three finger flick left/right. However it does move the cursor to the ends of sentences as expected.


Thanks,
Alex

On May 2, 2018, at 7:07 PM, FlickType <hello@flicktype.com> wrote:

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.

Full access will not be necessary when we launch to the App Store, but will be required for sound effects as per the Apple guidelines. However, most builds that go to the alpha and beta groups will likely require full access and not work unless it's turned on, so that we can better understand how people use the keyboard using our analytics service. Adding some analytics features in the custom keyboard is planned for sometime this week. Please check our very short privacy policy here for more information: http://www.flicktype.com/privacy

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,
Kosta



Re: General observation

Ed Worrell <ed.worrell@...>
 

as soon as we get manual typing and the full ability to insert new lines this will be a great option. I also can't wait to get the option for the half screen keyboard.

On May 2, 2018, at 9:45 PM, Chuck Dean <cadean329@gmail.com> wrote:

yes, it took me a while but now I can see this keyboard's best operation. Now I understand how the full screen keyboard can be used with almost all text fields. As it gets more refined and faster, it will be a great tool!

Chuck

On May 2, 2018, at 8:39 PM, Michael Maslo <michaelmaslo04@gmail.com> wrote:




Hi chuck, that is exactly what I do also. It is extremely effective and makes me love this keyboard even more.








On May 2, 2018 at 19:05, <Chuck Dean (mailto:cadean329@gmail.com)> wrote:



hello everyone, I now understand how to use a combination of the apple keyboard and the custom keyboard to send an email. Using the apple keyboard to input the recipient end the subject; then locating the cursor in the body of the text; then switch to the custom keyboard to type a lengthy message... Like this one.

Chuck






Re: General observation

Chuck Dean
 

yes, it took me a while but now I can see this keyboard's best operation. Now I understand how the full screen keyboard can be used with almost all text fields. As it gets more refined and faster, it will be a great tool!

Chuck

On May 2, 2018, at 8:39 PM, Michael Maslo <michaelmaslo04@gmail.com> wrote:




Hi chuck, that is exactly what I do also. It is extremely effective and makes me love this keyboard even more.








On May 2, 2018 at 19:05, <Chuck Dean (mailto:cadean329@gmail.com)> wrote:



hello everyone, I now understand how to use a combination of the apple keyboard and the custom keyboard to send an email. Using the apple keyboard to input the recipient end the subject; then locating the cursor in the body of the text; then switch to the custom keyboard to type a lengthy message... Like this one.

Chuck





Re: General observation

Michael Maslo
 

Hi chuck, that is exactly what I do also. It is extremely effective and makes me love this keyboard even more.


On May 2, 2018 at 19:05, <Chuck Dean (mailto:cadean329@gmail.com)> wrote:



hello everyone, I now understand how to use a combination of the apple keyboard and the custom keyboard to send an email. Using the apple keyboard to input the recipient end the subject; then locating the cursor in the body of the text; then switch to the custom keyboard to type a lengthy message... Like this one.

Chuck




Re: Memory warning!

Chuck Dean
 

actually, I found myself using those big words when I was writing an email and needed to learn whether I typed wife or wide.

Chuck

On May 2, 2018, at 7:31 PM, George Cham <George.cham@hotmail.com> wrote:

Don’t hate them. Just wondering whether it’s draining the memory in iOS and therefore the bigger the display the more memory it uses.

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’
Numbers 6:24-26
Get Outlook<https://aka.ms/qtex0l> for iOS
________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 12:25:42 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Memory warning!

Lol that’s funny George, you really hate these letters don’t you?

Chuck

On May 2, 2018, at 6:57 PM, George Cham <George.cham@hotmail.com> wrote:

I'm wondering if the large text in this new build, is draining the memory in ios? In build50 this problem did not happen. If that's the case, then I would recommend going back to the previous layout.

Kind Regards,

George Cham


________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 10:22:44 AM
To: Alpha
Subject: [FlickType-alpha] Memory warning!

Memory warning!
Hi Kosta, I tried typing an email from scratch, you can see the email titled an observation. After typing that amount of text, I had to reboot my iPhone because the Memory Warning! Would pop up about every third word.
I have done 5 reboot's today!


Chuck










Re: Memory warning!

George Cham
 

Don’t hate them. Just wondering whether it’s draining the memory in iOS and therefore the bigger the display the more memory it uses.

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’
Numbers 6:24-26
Get Outlook<https://aka.ms/qtex0l> for iOS
________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 12:25:42 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Memory warning!

Lol that’s funny George, you really hate these letters don’t you?

Chuck

On May 2, 2018, at 6:57 PM, George Cham <George.cham@hotmail.com> wrote:

I'm wondering if the large text in this new build, is draining the memory in ios? In build50 this problem did not happen. If that's the case, then I would recommend going back to the previous layout.

Kind Regards,

George Cham


________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 10:22:44 AM
To: Alpha
Subject: [FlickType-alpha] Memory warning!

Memory warning!
Hi Kosta, I tried typing an email from scratch, you can see the email titled an observation. After typing that amount of text, I had to reboot my iPhone because the Memory Warning! Would pop up about every third word.
I have done 5 reboot's today!


Chuck






Re: Memory warning!

Chuck Dean
 

Lol that’s funny George, you really hate these letters don’t you?

Chuck

On May 2, 2018, at 6:57 PM, George Cham <George.cham@hotmail.com> wrote:

I'm wondering if the large text in this new build, is draining the memory in ios? In build50 this problem did not happen. If that's the case, then I would recommend going back to the previous layout.

Kind Regards,

George Cham


________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 10:22:44 AM
To: Alpha
Subject: [FlickType-alpha] Memory warning!

Memory warning!
Hi Kosta, I tried typing an email from scratch, you can see the email titled an observation. After typing that amount of text, I had to reboot my iPhone because the Memory Warning! Would pop up about every third word.
I have done 5 reboot's today!


Chuck






Re: Memory warning!

George Cham
 

I'm wondering if the large text in this new build, is draining the memory in ios? In build50 this problem did not happen. If that's the case, then I would recommend going back to the previous layout.

Kind Regards,

George Cham


________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 10:22:44 AM
To: Alpha
Subject: [FlickType-alpha] Memory warning!

Memory warning!
Hi Kosta, I tried typing an email from scratch, you can see the email titled an observation. After typing that amount of text, I had to reboot my iPhone because the Memory Warning! Would pop up about every third word.
I have done 5 reboot's today!


Chuck


Re: Responses

Michael Maslo
 

Hello, I also do not get any feedback when I use the three finger swipe.


On May 2, 2018 at 18:48, <Benny Barber (mailto:rebelben@bellsouth.net)> wrote:



Kosta,

I am not getting verbal feedback on advancing the cursor by sentence. Thanks.

Benny

On May 2, 2018, at 6:07 PM, FlickType <hello@flicktype.com> wrote:

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.

Full access will not be necessary when we launch to the App Store, but will be required for sound effects as per the Apple guidelines. However, most builds that go to the alpha and beta groups will likely require full access and not work unless it's turned on, so that we can better understand how people use the keyboard using our analytics service. Adding some analytics features in the custom keyboard is planned for sometime this week. Please check our very short privacy policy here for more information: http://www.flicktype.com/privacy

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,
Kosta






Re: Build 54

George Cham
 

Hi Coster, I’m also getting the memory warning on the iPad running the latest version of iOS.

Kind Regards,

George Cham


________________________________
From: George Cham <george.cham@hotmail.com>
Sent: Thursday, May 3, 2018 10:11:13 AM
To: alpha@flicktype.groups.io; Alpha
Subject: Re: [FlickType-alpha] Build 54

Hi costa, I'm not seeing the memory warning, I'm running the latest version, of ios. I've also seen the letters change colours when typing or deleting. I'm typing this using the latest build. And I'm getting the hang of the two white bars between the. Top and bottom Rose. But as I type this, I’m using dictation now I have just received the memory warning, will send you a screenshot off list. Using iOS 11. Three with iPhone 8

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’
Numbers 6:24-26
Get Outlook<https://aka.ms/qtex0l> for iOS
________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 9:42:51 AM
To: Alpha
Subject: [FlickType-alpha] Build 54

Build 54
Hi Kosta,
I am using an iPhone 8 running iOS 11.3.1.
I find the memory warning!
Appears after typing on the custom keyboard for long periods of time, but I have never seen it in the stand alone App, which I have used for hours at a time.
Re-booting the iPhone seems to clear the problem until I type for another long period of time.
When the warning comes up, I can flick up and see the word I tried to type, until I keep typing, then the memory warning will appear and not go away.
I hope this makes sense,


Chuck


Memory warning!

Chuck Dean
 

Memory warning!
Hi Kosta, I tried typing an email from scratch, you can see the email titled an observation. After typing that amount of text, I had to reboot my iPhone because the Memory Warning! Would pop up about every third word.
I have done 5 reboot's today!


Chuck


Re: Build 54

George Cham
 

Hi costa, I'm not seeing the memory warning, I'm running the latest version, of ios. I've also seen the letters change colours when typing or deleting. I'm typing this using the latest build. And I'm getting the hang of the two white bars between the. Top and bottom Rose. But as I type this, I’m using dictation now I have just received the memory warning, will send you a screenshot off list. Using iOS 11. Three with iPhone 8

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’
Numbers 6:24-26
Get Outlook<https://aka.ms/qtex0l> for iOS
________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@gmail.com>
Sent: Thursday, May 3, 2018 9:42:51 AM
To: Alpha
Subject: [FlickType-alpha] Build 54

Build 54
Hi Kosta,
I am using an iPhone 8 running iOS 11.3.1.
I find the memory warning!
Appears after typing on the custom keyboard for long periods of time, but I have never seen it in the stand alone App, which I have used for hours at a time.
Re-booting the iPhone seems to clear the problem until I type for another long period of time.
When the warning comes up, I can flick up and see the word I tried to type, until I keep typing, then the memory warning will appear and not go away.
I hope this makes sense,


Chuck


General observation

Chuck Dean
 

hello everyone, I now understand how to use a combination of the apple keyboard and the custom keyboard to send an email. Using the apple keyboard to input the recipient end the subject; then locating the cursor in the body of the text; then switch to the custom keyboard to type a lengthy message... Like this one.

Chuck


Re: Responses

Benny Barber
 

Kosta,

I am not getting verbal feedback on advancing the cursor by sentence. Thanks.

Benny

On May 2, 2018, at 6:07 PM, FlickType <hello@flicktype.com> wrote:

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.

Full access will not be necessary when we launch to the App Store, but will be required for sound effects as per the Apple guidelines. However, most builds that go to the alpha and beta groups will likely require full access and not work unless it's turned on, so that we can better understand how people use the keyboard using our analytics service. Adding some analytics features in the custom keyboard is planned for sometime this week. Please check our very short privacy policy here for more information: http://www.flicktype.com/privacy

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,
Kosta



Build 54

Chuck Dean
 

Build 54
Hi Kosta,
I am using an iPhone 8 running iOS 11.3.1.
I find the memory warning!
Appears after typing on the custom keyboard for long periods of time, but I have never seen it in the stand alone App, which I have used for hours at a time.
Re-booting the iPhone seems to clear the problem until I type for another long period of time.
When the warning comes up, I can flick up and see the word I tried to type, until I keep typing, then the memory warning will appear and not go away.
I hope this makes sense,


Chuck


Re: Responses

George Cham
 

Hi Coster, if I type the word he, then flick right then I flick back to the left Voiceover says delete he. But the word still remains on the screen until I flick left again. I also feel that the large letters on The screen, is too messy. I would prefer the previous version with the black background and sure I can’t see the words but it looks a lot neater when typing.

Kind regards,

George Cham

‘May the Lord bless you and protect you. May the Lord smile on you and be gracious to you. May the Lord show you his favor and give you his peace.’
Numbers 6:24-26
Get Outlook<https://aka.ms/qtex0l> for iOS
________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@flicktype.com>
Sent: Thursday, May 3, 2018 9:07:40 AM
To: alpha@flicktype.groups.io
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.

Full access will not be necessary when we launch to the App Store, but will be required for sound effects as per the Apple guidelines. However, most builds that go to the alpha and beta groups will likely require full access and not work unless it's turned on, so that we can better understand how people use the keyboard using our analytics service. Adding some analytics features in the custom keyboard is planned for sometime this week. Please check our very short privacy policy here for more information: http://www.flicktype.com/privacy

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,
Kosta


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.

Full access will not be necessary when we launch to the App Store, but will be required for sound effects as per the Apple guidelines. However, most builds that go to the alpha and beta groups will likely require full access and not work unless it's turned on, so that we can better understand how people use the keyboard using our analytics service. Adding some analytics features in the custom keyboard is planned for sometime this week. Please check our very short privacy policy here for more information: http://www.flicktype.com/privacy

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,
Kosta

1781 - 1800 of 2168