Topics

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


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 <@FlickType>
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


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 <@FlickType> 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



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@...)> 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 <@FlickType> 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






Alex Hiironen
 

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 <@FlickType> 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



 

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


Paul Sutton
 

Hi, I have updated to the latest iOS software and the lag I was experiencing with the stand alone app has been resolved. However, in the system wide keyboard, every now and then when I am swiping left to delete a word voiceover will announce "clear tabs " or "clear taps " I can't tell which.
Paul.


Chuck Dean
 

hi Paul, you will hear clear taps when you type letters but do not flick right to enter the word. So if you are typing and make a mistake and flick left to delete the wrong letters you will hear clear taps. I hope this helps.

Chuck

On May 3, 2018, at 1:57 PM, Paul Sutton <sutty_p@...> wrote:

Hi, I have updated to the latest iOS software and the lag I was experiencing with the stand alone app has been resolved. However, in the system wide keyboard, every now and then when I am swiping left to delete a word voiceover will announce "clear tabs " or "clear taps " I can't tell which.
Paul.



Paul Sutton
 

Hi Chuck, thanks for that. Yes, just tried it and you are indeed write. I can't believe that I didn't realise that, lol.

On 3 May 2018, at 22:53, Chuck Dean <cadean329@...> wrote:

hi Paul, you will hear clear taps when you type letters but do not flick right to enter the word. So if you are typing and make a mistake and flick left to delete the wrong letters you will hear clear taps. I hope this helps.

Chuck

On May 3, 2018, at 1:57 PM, Paul Sutton <sutty_p@...> wrote:

Hi, I have updated to the latest iOS software and the lag I was experiencing with the stand alone app has been resolved. However, in the system wide keyboard, every now and then when I am swiping left to delete a word voiceover will announce "clear tabs " or "clear taps " I can't tell which.
Paul.