Topics

Update and responses


 

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta


Chuck Dean
 

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

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

Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta



George Cham
 

Hi costa, I'm getting the hang of the large letters as I type. Its helping a lot. But I would like to see the letters smaller, but keep the full screen keyboard. I know you can not please everyone, but maybe this can be introduced in a later version, when the full screen keyboard is out in the App store.

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@...>
Sent: Tuesday, May 8, 2018 3:41:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

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

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

Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta



 

Thanks Chuck, I'll keep that in mind. I might consider adding some kind of
visual indicator that will lack the clarity of actual text but perhaps
provide the same reassurance that you're talking about.

- Kosta

On Mon, May 7, 2018 at 11:09 PM, Chuck Dean <cadean329@...> wrote:




Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta





 

Thank you George, glad you like the letters. Could you please elaborate on
why you'd like them to be smaller? Is that because you want to see more
than one word at the same time, or some other reason?
- Kosta

- To join our beta, please send an email here
<beta+subscribe@flicktype.groups.io?subject=Subscribe&body=empty>
- Browse all our forum topics <https://flicktype.groups.io/g/hello/topics>
- Post to our forum <hello@flicktype.groups.io>
- Join our forum <hello+subscribe@flicktype.groups.io>
- Help & support <http://www.flicktype.com/help>
- Follow us on Twitter <https://twitter.com/FlickType>

http://flicktype.com



On Mon, May 7, 2018 at 11:17 PM, George Cham <George.cham@...>
wrote:

Hi costa, I'm getting the hang of the large letters as I type. Its helping
a lot. But I would like to see the letters smaller, but keep the full
screen keyboard. I know you can not please everyone, but maybe this can be
introduced in a later version, when the full screen keyboard is out in the
App store.

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@...>
Sent: Tuesday, May 8, 2018 3:41:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

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

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

Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta








George Cham
 

Hi costa, that's correct, I'd like to see more than one word after I type.

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: Tuesday, May 8, 2018 4:24:55 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

Thank you George, glad you like the letters. Could you please elaborate on
why you'd like them to be smaller? Is that because you want to see more
than one word at the same time, or some other reason?
- Kosta

- To join our beta, please send an email here
<beta+subscribe@flicktype.groups.io?subject=Subscribe&body=empty>
- Browse all our forum topics <https://flicktype.groups.io/g/hello/topics>
- Post to our forum <hello@flicktype.groups.io>
- Join our forum <hello+subscribe@flicktype.groups.io>
- Help & support <http://www.flicktype.com/help>
- Follow us on Twitter <https://twitter.com/FlickType>

http://flicktype.com



On Mon, May 7, 2018 at 11:17 PM, George Cham <George.cham@...>
wrote:

Hi costa, I'm getting the hang of the large letters as I type. Its helping
a lot. But I would like to see the letters smaller, but keep the full
screen keyboard. I know you can not please everyone, but maybe this can be
introduced in a later version, when the full screen keyboard is out in the
App store.

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@...>
Sent: Tuesday, May 8, 2018 3:41:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

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

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

Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta








George Cham
 

While composing a text message, I found myself checking what I'd wrote. When I went back to FlickType, I'd forgotten what I'd said. Is there a way of keeping the text on the screen when returning to the FlickType keyboard? so the user can review and edit the document?

Kind Regards,

George Cham


________________________________
From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of George Cham <George.cham@...>
Sent: Tuesday, May 8, 2018 4:42:53 PM
To: alpha@flicktype.groups.io; alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

Hi costa, that's correct, I'd like to see more than one word after I type.

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: Tuesday, May 8, 2018 4:24:55 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

Thank you George, glad you like the letters. Could you please elaborate on
why you'd like them to be smaller? Is that because you want to see more
than one word at the same time, or some other reason?
- Kosta

- To join our beta, please send an email here
<beta+subscribe@flicktype.groups.io?subject=Subscribe&body=empty>
- Browse all our forum topics <https://flicktype.groups.io/g/hello/topics>
- Post to our forum <hello@flicktype.groups.io>
- Join our forum <hello+subscribe@flicktype.groups.io>
- Help & support <http://www.flicktype.com/help>
- Follow us on Twitter <https://twitter.com/FlickType>

http://flicktype.com



On Mon, May 7, 2018 at 11:17 PM, George Cham <George.cham@...>
wrote:

Hi costa, I'm getting the hang of the large letters as I type. Its helping
a lot. But I would like to see the letters smaller, but keep the full
screen keyboard. I know you can not please everyone, but maybe this can be
introduced in a later version, when the full screen keyboard is out in the
App store.

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@...>
Sent: Tuesday, May 8, 2018 3:41:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Update and responses

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

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

Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta








Chanelle Allen
 

Hi Kosta,
My weird FlickType behavior of last night persists into the morning. Hopefully later on, I will discover something I'm doing wrong or the fluke will resolve itself. The FlickType app only works with VoiceOver turned off, and I do not get any response when using the keyboard. Of course, I leave VoiceOver on to use the keyboard. I had already disabled and re-enabled keyboard access. I am using an iPhone 7 running iOS 11.3.1. If things don't work after another restart, I will erase my phone later today and restore from backup. I'm not thrilled about setting up my device as a new iPhone but will consider it if a simple backup, erase, and restore doesn't solve the problem.
Chanelle

On May 8, 2018, at 00:41, Chuck Dean <cadean329@...> wrote:

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

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

Chuck

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta




Benny Barber
 

Kosta,

In regards to the raise to read feature, I guess I am getting greedy. Being
able to hear the entire typed document read back to you, gives you an idea
of the flow of what you have typed. It helps in deciding whether to change
something that you have typed. Being able to move by sentence is a good
tool to move to an area where you might want to edit. I hope I'm not asking
for too much. Thanks for the great work.

Benny

-----Original Message-----
From: alpha@flicktype.groups.io [mailto:alpha@flicktype.groups.io] On Behalf
Of FlickType
Sent: Tuesday, May 08, 2018 12:18 AM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Update and responses

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta


Chanelle Allen
 

Hi Kosta,
I can now confirm that FlickType Custom Keyboard and the FlickType app respond only when VoiceOver is off. In the case of the keyboard, I do not know what I am typing. My phone has been restarted twice since writing to the list earlier this morning. I am not sure if this makes a difference, but for one of the restarts, I pressed and held the volume down and power/lock buttons together for about 15 seconds. I have also tried setting VoiceOver typing feedback to nothing.
Chanelle

On May 8, 2018, at 06:40, Benny Barber <rebelben@...> wrote:

Kosta,

In regards to the raise to read feature, I guess I am getting greedy. Being
able to hear the entire typed document read back to you, gives you an idea
of the flow of what you have typed. It helps in deciding whether to change
something that you have typed. Being able to move by sentence is a good
tool to move to an area where you might want to edit. I hope I'm not asking
for too much. Thanks for the great work.

Benny
-----Original Message-----
From: alpha@flicktype.groups.io [mailto:alpha@flicktype.groups.io] On Behalf
Of FlickType
Sent: Tuesday, May 08, 2018 12:18 AM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Update and responses

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta






 

Chanelle,

I do not recommend restoring your entire phone, I doubt this will help.

When was the last time flicktype worked properly for you?

Kosta

On May 8, 2018, at 07:05, Chanelle Allen <chanellem.allen@...> wrote:

Hi Kosta,
I can now confirm that FlickType Custom Keyboard and the FlickType app respond only when VoiceOver is off. In the case of the keyboard, I do not know what I am typing. My phone has been restarted twice since writing to the list earlier this morning. I am not sure if this makes a difference, but for one of the restarts, I pressed and held the volume down and power/lock buttons together for about 15 seconds. I have also tried setting VoiceOver typing feedback to nothing.
Chanelle


On May 8, 2018, at 06:40, Benny Barber <rebelben@...> wrote:

Kosta,

In regards to the raise to read feature, I guess I am getting greedy. Being
able to hear the entire typed document read back to you, gives you an idea
of the flow of what you have typed. It helps in deciding whether to change
something that you have typed. Being able to move by sentence is a good
tool to move to an area where you might want to edit. I hope I'm not asking
for too much. Thanks for the great work.

Benny
-----Original Message-----
From: alpha@flicktype.groups.io [mailto:alpha@flicktype.groups.io] On Behalf
Of FlickType
Sent: Tuesday, May 08, 2018 12:18 AM
To: alpha@flicktype.groups.io
Subject: [FlickType-alpha] Update and responses

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta







Benny Barber
 

Kosta,

I made FlickType my only active keyboard to see how it worked. It worked fine in the nail app, but there was no sent button in the messages app when I dismissed the FlickType keyboard. Maybe I'm getting ahead of the game.
Regarding typing feedback, I really hope we can keep that option. Maybe I could do without if we get to a point where I can soley depend on the FlickType keyboard.
Also, having the key taps occur when lifting the finger rather than when touching the screen gives the perception of latency. It kind of slows my typing down. Thanks
Benny

On May 8, 2018, at 12:17 AM, FlickType <@FlickType> wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta



Chanelle Allen
 

Hi Kosta,
FlickType 1.57 worked consistently for me. FlickType 1.60 was working while I wrote a note last night. When I dismissed the keyboard to review the text and then returned to Notes, I started having problems. I did restore my phone before reading your email, and my apps are downloading. As you stated, restoring the phone did not fix the problems I am experiencing. Rather than let FlickType restore, I deleted the app and installed a fresh copy from TestFlight. I will revert back to build 57.

Chanelle

On May 8, 2018, at 09:53, Benny Barber <rebelben@...> wrote:


Kosta,

I made FlickType my only active keyboard to see how it worked. It worked fine in the nail app, but there was no sent button in the messages app when I dismissed the FlickType keyboard. Maybe I'm getting ahead of the game.
Regarding typing feedback, I really hope we can keep that option. Maybe I could do without if we get to a point where I can soley depend on the FlickType keyboard.
Also, having the key taps occur when lifting the finger rather than when touching the screen gives the perception of latency. It kind of slows my typing down. Thanks
Benny




On May 8, 2018, at 12:17 AM, FlickType <@FlickType> wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta





 

Thank you Chanelle, I’d be interested to know if reverting to build 57 fixed the issue for you.

Kosta

On May 8, 2018, at 08:26, Chanelle Allen <chanellem.allen@...> wrote:

Hi Kosta,
FlickType 1.57 worked consistently for me. FlickType 1.60 was working while I wrote a note last night. When I dismissed the keyboard to review the text and then returned to Notes, I started having problems. I did restore my phone before reading your email, and my apps are downloading. As you stated, restoring the phone did not fix the problems I am experiencing. Rather than let FlickType restore, I deleted the app and installed a fresh copy from TestFlight. I will revert back to build 57.

Chanelle
On May 8, 2018, at 09:53, Benny Barber <rebelben@...> wrote:


Kosta,

I made FlickType my only active keyboard to see how it worked. It worked fine in the nail app, but there was no sent button in the messages app when I dismissed the FlickType keyboard. Maybe I'm getting ahead of the game.
Regarding typing feedback, I really hope we can keep that option. Maybe I could do without if we get to a point where I can soley depend on the FlickType keyboard.
Also, having the key taps occur when lifting the finger rather than when touching the screen gives the perception of latency. It kind of slows my typing down. Thanks
Benny




On May 8, 2018, at 12:17 AM, FlickType <@FlickType> wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kosta