Date   
Re: Build 164

Chuck Dean
 

Hello Kosta,
I notice FlickType is still repeating the last word of a sentence instead of saying " period "
I am already used to it, but I'm sure others will complain.

I am using an iPhone 8, running iOS 11.4.1

Chuck

On Sep 1, 2018, at 7:51 PM, FlickType <@FlickType> wrote:

What's new:
- Fix for shift / casing issue. Thanks Benny!

Previously:
- Fix for VoiceOver announcing "End of document" when deleting or changing the last word of the document. The issue might still occur, but it should be much less common.


Build 164

 

What's new:
- Fix for shift / casing issue. Thanks Benny!

Previously:
- Fix for VoiceOver announcing "End of document" when deleting or changing the last word of the document. The issue might still occur, but it should be much less common.

Re: Build 159

Benny Barber
 

Kosta,
In the full screen keyboard and using the two finger tap to capitalize I can't get it to work. If the word is capitalized, the spellback is reading a lower case letter. Thanks.
Benny

On Sep 1, 2018, at 6:54 PM, FlickType <@FlickType> wrote:

Build 163 is out. What's new:
- Fix for VoiceOver announcing "End of document" when deleting or changing the last word of the document. The issue might still occur, but should be much more rare. Please let us know if this is the case.


Re: Build 159

 

Build 163 is out. What's new:
- Fix for VoiceOver announcing "End of document" when deleting or changing the last word of the document. The issue might still occur, but should be much more rare. Please let us know if this is the case.

Re: Build 159

 

Correct, tap-typing is unaffected. You might have missed my email to George and Salman about an hour ago.
- Kosta

On Sat, Sep 1, 2018 at 3:36 PM David Nason <dnason@...> wrote:
Oh apologies, I think I was getting confused. I was actually just thinking of tap typing, not manual.
But I guess that is actually unaffected by the new gesture?

sorry for the confusion.
H


On 1 Sep 2018, at 23:32, FlickType <hello@...> wrote:

Thank you Dave. I reproduced the deletion announcement issue. This should be fixed soon, together with the same incorrect announcement when flicking down to change the last word of the document.

On the accuracy issues, I'd love to get a reproducible example. Any time something like that happens, please make note of the two words before the word you were trying to type, delete the failed word and try to reproduce it. If you can reliably reproduce it, sharing the two words before and the word you're trying to type would be enough for me to reproduce it as well.

Regarding the forgiving area on the top row, the pattern of a manually typed word has never been taken into account. There is no change to the forgiving area when tap-typing. Are you saying that manual typing is so common that the reduced height of that row would significantly affect use? And if so, is there not some height beyond which there is no benefit at all?

Thanks,
Kosta

On Sat, Sep 1, 2018 at 3:09 PM David Nason <dnason@...> wrote:
Hi Kosta,

Just a follow up on the issue I mentioned when deleting words in WhatsApp using the minimal and half screen keyboards.
It turns out I'm seeing the exact same behaviour in the demo tab of the container app too.

I've mentioned some accuracy issues too. For example, I tried to type the word "we're".
It offered me "were" as the first suggestion, and "Were" as the second suggestion, but "we're" didn't appear in the list at all. This seems mad to me.
I had similar experience with "does", being offered only "dies" and "dues".
I do know that typing accuracy is down to my effort too sometimes though☺️

I quite like the new one finger tap and hold for read back. But I do see that, in particular people with no usable sight, some people want and need a very forgiving typing area, depending more on the pattern than the correct starting row height, if that makes sense.

Dave
> On 1 Sep 2018, at 22:32, FlickType <hello@...> wrote:
>
> Thank you George, we will fix this bug on the iPad.
>
> Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.
>
> I also want to add a couple of points regarding the new 1-finger read back gesture:
> - Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
> - If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.
>
> I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.
>
> Warmly,
> Kosta
>
>
>



Re: Build 159

David Nason
 

Oh apologies, I think I was getting confused. I was actually just thinking of tap typing, not manual.
But I guess that is actually unaffected by the new gesture?

sorry for the confusion.
H


On 1 Sep 2018, at 23:32, FlickType <hello@...> wrote:

Thank you Dave. I reproduced the deletion announcement issue. This should be fixed soon, together with the same incorrect announcement when flicking down to change the last word of the document.

On the accuracy issues, I'd love to get a reproducible example. Any time something like that happens, please make note of the two words before the word you were trying to type, delete the failed word and try to reproduce it. If you can reliably reproduce it, sharing the two words before and the word you're trying to type would be enough for me to reproduce it as well.

Regarding the forgiving area on the top row, the pattern of a manually typed word has never been taken into account. There is no change to the forgiving area when tap-typing. Are you saying that manual typing is so common that the reduced height of that row would significantly affect use? And if so, is there not some height beyond which there is no benefit at all?

Thanks,
Kosta

On Sat, Sep 1, 2018 at 3:09 PM David Nason <dnason@...> wrote:
Hi Kosta,

Just a follow up on the issue I mentioned when deleting words in WhatsApp using the minimal and half screen keyboards.
It turns out I'm seeing the exact same behaviour in the demo tab of the container app too.

I've mentioned some accuracy issues too. For example, I tried to type the word "we're".
It offered me "were" as the first suggestion, and "Were" as the second suggestion, but "we're" didn't appear in the list at all. This seems mad to me.
I had similar experience with "does", being offered only "dies" and "dues".
I do know that typing accuracy is down to my effort too sometimes though☺️

I quite like the new one finger tap and hold for read back. But I do see that, in particular people with no usable sight, some people want and need a very forgiving typing area, depending more on the pattern than the correct starting row height, if that makes sense.

Dave
> On 1 Sep 2018, at 22:32, FlickType <hello@...> wrote:
>
> Thank you George, we will fix this bug on the iPad.
>
> Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.
>
> I also want to add a couple of points regarding the new 1-finger read back gesture:
> - Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
> - If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.
>
> I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.
>
> Warmly,
> Kosta
>
>
>



Re: Build 159

 

Thank you Dave. I reproduced the deletion announcement issue. This should be fixed soon, together with the same incorrect announcement when flicking down to change the last word of the document.

On the accuracy issues, I'd love to get a reproducible example. Any time something like that happens, please make note of the two words before the word you were trying to type, delete the failed word and try to reproduce it. If you can reliably reproduce it, sharing the two words before and the word you're trying to type would be enough for me to reproduce it as well.

Regarding the forgiving area on the top row, the pattern of a manually typed word has never been taken into account. There is no change to the forgiving area when tap-typing. Are you saying that manual typing is so common that the reduced height of that row would significantly affect use? And if so, is there not some height beyond which there is no benefit at all?

Thanks,
Kosta

On Sat, Sep 1, 2018 at 3:09 PM David Nason <dnason@...> wrote:
Hi Kosta,

Just a follow up on the issue I mentioned when deleting words in WhatsApp using the minimal and half screen keyboards.
It turns out I'm seeing the exact same behaviour in the demo tab of the container app too.

I've mentioned some accuracy issues too. For example, I tried to type the word "we're".
It offered me "were" as the first suggestion, and "Were" as the second suggestion, but "we're" didn't appear in the list at all. This seems mad to me.
I had similar experience with "does", being offered only "dies" and "dues".
I do know that typing accuracy is down to my effort too sometimes though☺️

I quite like the new one finger tap and hold for read back. But I do see that, in particular people with no usable sight, some people want and need a very forgiving typing area, depending more on the pattern than the correct starting row height, if that makes sense.

Dave
> On 1 Sep 2018, at 22:32, FlickType <hello@...> wrote:
>
> Thank you George, we will fix this bug on the iPad.
>
> Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.
>
> I also want to add a couple of points regarding the new 1-finger read back gesture:
> - Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
> - If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.
>
> I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.
>
> Warmly,
> Kosta
>
>
>



Re: Build 159

Chuck Dean
 

Hi kosta,
I would like to see a row above which would have selection options like Fleksy had, such as the Colin of dot com, dot net, etc and a Colin of commonly used symbols, and a Colin of numbers one through twelve.

I used these back when I used Fleksy, when I remembered they were there.
Chuck

On Sep 1, 2018, at 2:32 PM, FlickType <@FlickType> wrote:

Thank you George, we will fix this bug on the iPad.

Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.

I also want to add a couple of points regarding the new 1-finger read back gesture:
- Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
- If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.

I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.

Warmly,
Kosta


Re: Build 159

David Nason
 

Hi Kosta,

Just a follow up on the issue I mentioned when deleting words in WhatsApp using the minimal and half screen keyboards.
It turns out I'm seeing the exact same behaviour in the demo tab of the container app too.

I've mentioned some accuracy issues too. For example, I tried to type the word "we're".
It offered me "were" as the first suggestion, and "Were" as the second suggestion, but "we're" didn't appear in the list at all. This seems mad to me.
I had similar experience with "does", being offered only "dies" and "dues".
I do know that typing accuracy is down to my effort too sometimes though☺️

I quite like the new one finger tap and hold for read back. But I do see that, in particular people with no usable sight, some people want and need a very forgiving typing area, depending more on the pattern than the correct starting row height, if that makes sense.

Dave

On 1 Sep 2018, at 22:32, FlickType <@FlickType> wrote:

Thank you George, we will fix this bug on the iPad.

Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.

I also want to add a couple of points regarding the new 1-finger read back gesture:
- Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
- If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.

I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.

Warmly,
Kosta


Re: Build 159

 

Thank you George, we will fix this bug on the iPad.

Thank you Salman, I fully agree on giving people options. I also always try to find a way that would ideally not require an option, in order to have a simpler system that's easier for me to maintain, test, and further extend, given all the different permutations of settings that users might have at any point in time. If implementing something seems impossible or impractical to do without an option, then I usually add the option for users to choose - although even then I still need to come up with the default setting for it, which can be a tough challenge and is what the vast majority of users will end up using. Most of the time there's no easy way to know which default setting is best, other than feedback from a lot of users.

I also want to add a couple of points regarding the new 1-finger read back gesture:
- Besides having no effect on the performance of any other gesture, it's important to explicitly note that is also has no effect on tap-typing positioning, placement, accuracy, or any other aspect of how you tap-type with the keyboard.
- If the reduction of the top row height when touch-typing is still a meaningful issue, a happy medium would be reducing it by a smaller amount. For example, the top row could be reduced to still be twice the height of a regular row, and above that you'd hear your text. I do believe that during touch-typing, there's a certain height beyond which there's no additional benefit of extending the top row.

I would love to hear people's thoughts on not just this new gesture, but also the general idea of putting some additional functions sitting above the keyboard when touch-typing only.

Warmly,
Kosta

Re: Build 159

Salman Haider
 

Kosta,

I understand your rationale behind why you implemented this option;
you want to make better use of the space above the keyboard, and
provide other features/options in the upcoming weeks and months as
development continues.
However, in a way it kind of takes away the point of having a "full
screen" keyboard, at least for the typing part.
Basically, what it may turn into is, keyboard in the bottom half and
other options available through the upper half.
So essentially it'd become a "half screen" keyboard for typing
purposes, with other actions and options available through the upper
half.
I am making this assumption based on what you said in another email (a
response to Benny I believe).

While I understand your rationale and reasoning, I do think that it
may work for some, while others may not want to compromise or adjust
to typing strictly in the bottom half of the screen. The way I see it,
a full screen keyboard allows users to have access to the full screen
(or at least a significantly large area) for typing purposes, and not
simply the bottom half, with actions available through the upper half.

Still, I think a happy medium, and the best thing to do would be, to
allow for all of those features to be made an option. And users can
customize the typing experience and the keyboard at their will.
Just like It is the case currently, where we have the choice of
enabling or disabling the bottom row of keys, or having the Dismiss
button available, or the Next Keyboard button available, visual
announcements being on or off, I think it would be best to add the
option for each of those new features/options that you implement, so
that the user can disable or enable something to suit their needs.

You also mentioned potentially adding a row above the current top row,
for numbers and symbols. Again, this would be nice to have for many,
but others may not want the top row to become less forgiving in that
sense, and may prefer to keep that feature turned off.
It may suit low vision users, but invididuals who have no usable
vision, may find it even more of a challenge with their typing area
being restricted even more.

While I understand that most in this group may like all of those
options in the upper half, there are obviously users outside of this
group as well, with varying levels of ability and skill, who may find
too much functionality and features overwhelming and difficult to
adapt to.
Therefore, I really think the option to enable and disable features,
functionality, gestures etc should be provided to allow for maximum
customization.

Just my opinion.

Salman

On 8/31/18, FlickType <@FlickType> wrote:
Thank you Salman.

I agree that the new way to read back makes manual typing on the top row a
little less forgiving, in that the top row is now only as forgiving as the
other two rows. Before, the top row was more forgiving on the Y axis since
you could be touching as high up as possible and still get a top row letter.
In effect, the top row extended all the way to the top of the screen, in
contrast to the two bottom rows. But I still think such a change might be
beneficial overall, if we consider the benefits. Consider a related example,
where we might add an option for a number row or commonly used symbols row
above the QWERTY row. If and when we do that, the top row would need to be
limited in height and reduced to be just as forgiving as all other rows,
like it is right now in this new build.

Also note that this is technically not a new gesture in the entire system,
but rather an extension of the existing long press gesture. The way I
thought about it, is that all that space at the top is wasted when you are
typing manually, and could be used for something more useful. It's now as if
a new button was added on top of the QWERTY row than spans the entire
keyboard width, and its label is always set to be your current text. And not
being a new gesture also means that you shouldn't need to be any more
careful or otherwise change how or where you performed the dismiss or next
keyboard gestures - it should all be identical as before unless I botched
something.

It's also important to note that the overall explore gesture we've always
had is in a way already interfering with the dismiss or next keyboard
gestures, in that you might sometimes get a manual letter entered instead of
exiting the keyboard, or vice-versa. The difference now is that you might
get your text read back to you instead of the manual letter, which also
seems to be a more forgiving mistake, since at least you don't end up with a
dangling extra letter somewhere. So if you had performed the exact same
finger movements that you did just now, but on a previous build, you'd still
have the same success when trying to switch to the iOS keyboard as well as
delete the unwanted single character.

I'm open to hearing more about everyone's experience and thoughts about
this, after giving it a few tries to adjust to the change.

Thank you,
Kosta



Re: Build 159

George Cham
 

Hi Chuc, the iPad is already in portrait  mode.

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 for iOS


From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of Chuck Dean <cadean329@...>
Sent: Saturday, September 1, 2018 5:02:50 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 159
 
Hi George, is your iPad in landscape mode.? If so, turn it into portrait mode.
Chuck

On Aug 31, 2018, at 11:56 PM, George Cham <George.cham@...> wrote:

Hi Coster,
I mentioned in this thread the half screen is  showing the text above the keyboard, on my iPhone  8. and this is allowing me to tap and hold  to hear the   text,
However when I go half screen on the iPad there is no display above the keyboard showing the text as 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 for iOS

From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@...>
Sent: Saturday, September 1, 2018 3:43:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 159
 
Build 162 is out with manual typing bug fixes.

Please let me know if you find anything else broken.

Thank you for testing,
Kosta



Re: Build 159

Chuck Dean
 

Hi George, is your iPad in landscape mode.? If so, turn it into portrait mode.
Chuck

On Aug 31, 2018, at 11:56 PM, George Cham <George.cham@...> wrote:

Hi Coster,
I mentioned in this thread the half screen is  showing the text above the keyboard, on my iPhone  8. and this is allowing me to tap and hold  to hear the   text,
However when I go half screen on the iPad there is no display above the keyboard showing the text as 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 for iOS

From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@...>
Sent: Saturday, September 1, 2018 3:43:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 159
 
Build 162 is out with manual typing bug fixes.

Please let me know if you find anything else broken.

Thank you for testing,
Kosta



Re: Build 159

George Cham
 

Hi Coster,
I mentioned in this thread the half screen is  showing the text above the keyboard, on my iPhone  8. and this is allowing me to tap and hold  to hear the   text,
However when I go half screen on the iPad there is no display above the keyboard showing the text as 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 for iOS


From: alpha@flicktype.groups.io <alpha@flicktype.groups.io> on behalf of FlickType <hello@...>
Sent: Saturday, September 1, 2018 3:43:31 PM
To: alpha@flicktype.groups.io
Subject: Re: [FlickType-alpha] Build 159
 
Build 162 is out with manual typing bug fixes.

Please let me know if you find anything else broken.

Thank you for testing,
Kosta



Re: Build 159

David Nason
 

Ok great, that does appear to be fixed.

Thanks,
Dave

On 1 Sep 2018, at 06:43, FlickType <@FlickType> wrote:

Build 162 is out with manual typing bug fixes.

Please let me know if you find anything else broken.

Thank you for testing,
Kosta


Re: Build 159

 

Build 162 is out with manual typing bug fixes.

Please let me know if you find anything else broken.

Thank you for testing,
Kosta

Re: Build 159

Salman Haider
 

Kosta,
Not only is a period Being reported after manually typing a word and swiping right, it is actually being inserted. What I’ve also noticed is that the last word that I manually typed, actually joins up with the word that I typed prior to it. So it all becomes a bit of a mess. I’ll give you two examples. I was trying to type the words “other randomness” earlier. The word randomness is not in the dictionary so I manually typed it out. When I swiped right, VoiceOver announced period. On checking, a period was indeed inserted, and in addition to that, the text came out as “otherrandomness.”
Then, in the second instance, I was trying to type the words “a bit iffy”. Iffy is not in the dictionary so when I manually typed it out and swiped right, VoiceOver announced period. Upon checking, the text hat come out as “a bitiffy.”
Hope this makes sense and helps you identify what's gone wrong in the recent update. This issue was certainly not there before.
Salman

On Aug 31, 2018, at 8:53 PM, Salman Haider <salmanhaider.purdue@...> wrote:

Kosta and Dave,

I would like to confirm that I am experiencing this bug as well. After
manually typing a word, when I swipe right, Voiceover announces
"period", rather than the word that was typed.
I would like to add that I have encountered this not just in the Mail
app like Dave, but also in another app. Namely, Facebook Messenger.
So far...I'll let you know if I encounter it in more apps. It is
consistent across all keyboard heights. I personally use the almost
full screen mode.

I also want to give feedback on the newly introduced one finger tap
and hold gesture (above the top row of keys) to read back typed text.
While I like the idea of a one handed gesture, I am finding this one
to be highly inconvenient and intrusive. Often, this gesture becomes a
problem when attempting to manually type a word, especially one that
involves typing letters that are in the top row. Secondly, I am
noticing that this is also interfering with the one finger swipe up
and hold gesture to switch to the iOS keyboard. One has to be very
precise when performing that gesture, and that too, in the bottom half
of the screen rather than anywhere on the screen, as was the case
previously.
I have had my text read out to me multiple times already when
attempting to switch to the iOS keyboard, or have had a letter
manually typed when attempting to perform the gesture.
Being a full screen mode user, I do have a need to switch to the iOS
keyboard and so definitely do not like this new gesture interfering
with the one finger swipe up and hold.

Needless to say, I'm not a fan and prefer the two finger or three
finger tap and hold gestures for text read back, as those gestures
don't interfere with any of the other one handed and existing
gestures.

Salman



On 8/31/18, David Nason <dnason@...> wrote:
Ah ok, that makes more sense, thanks.
The manual typing bug only seems to be inMail. its not happening in
Messages,Notes, or WhatsApp. It happens with all four keyboard height
options.

Dave
On 1 Sep 2018, at 00:13, FlickType <@FlickType> wrote:

Ed, thank you for the kind words ☺️

Still trying to reproduce the manual word period issue.

- Kosta




Re: Build 159

Salman Haider
 

I second this completely. I'm already a bit iffy on the one finger read back gesture... Its proving to be a bit of a nuisance for me so far...

On Aug 31, 2018, at 9:39 PM, Benny Barber <benny.barber55@...> wrote:

Kosta,
Please do not change the way the full screen keyboard works. Currently it works great. I believe I will always be a full screen user. Thanks for your hard work.
Benny

On Aug 30, 2018, at 1:19 PM, FlickType <@FlickType> wrote:

Thank you all for the helpful feedback, please keep it coming. When posting an issue, please include additional information such as full screen or half screen, iOS 11 or 12, and any iOS typing feedback settings when applicable. Below are my responses to all your points:

- The first word of the sentence being repeated once you start typing the next word. Chuck, is this with the half screen mode? And what are your iOS typing feedback settings and iOS version? Anyone else experiencing that?

- Cannot interact properly with the top half of the screen, for example move the cursor using the rotor. David, what exactly happens when you try that? Note that with half screen mode, any iOS system gesture such as the rotor needs to be performed entirely outside of the FlickType area, in other words it has to be done inside the application area. If one finger is in the application area and another finger is inside FlickType, the rotor gesture will not register.

- Hearing "space" when inserting a period is a known issue and should be fixed soon.

- The voice being too high pitched when reading the typed word: David, what are your iOS typing feedback settings and iOS version? Anyone else experiencing that?

- The new multi-finger setting only affects the two finger single tap to toggle shift. When disabled, that gesture will not trigger a shift change. I will rename the setting to something better. This is more of a bandaid fix for now.

- When double tapping in the text field to move the cursor to the beginning or end of the text, VoiceOver will say the first or last word instead of "beginning of document" or "end of document". This should be fixed soon.

- I can not flick line by line, only word by word. Do you mean using the 3-finger gesture on FlickType? There is a known issue where the cursor will actually move over entire sentences as expected, but only the punctuation marks will be announced.

- When flicking through the text word by word with the iOS gestures, the last word in a sentence is not always announced. This should be fixed soon.

- While trying to reply to a email, I could not access the send button, I lost the email. Chuck, can you please elaborate on not being able to access the send button? And was the email saved as a draft? With the half screen mode, you should not ever experience text loss since all text changes are instantly reflected in the application's text field.

- I tried turning off multi finger gestures which did turn them off, but I tried typing words with a hard press to capitalize the word with no results. The first letter is announced but not typed. Chuck, I was not able to reproduce this.

- FlickType is no longer spelling back words to me, even though I have the setting turned on. David, is this with the half screen mode? Does restarting your device seem to fix it?

Thanks,
Kosta


Re: Build 159

 

Thank you Benny.

As iOS evolves, I am hoping that we will eventually be able to trigger the "Send" button and all other action buttons from within the full screen mode, including moving to the next or previous input fields of the current app. And the full screen mode gives us all that space above the keyboard which we can fully customize over time and dramatically improve the entire writing experience for low-vision users in ways that no other keyboard has ever done before. The future of the full screen mode is how FlickType goes from simply being a keyboard to becoming an amazing, integrated low-vision writing experience, including typing, editing, proof-reading and whatever else you need to write on your mobile device quickly and conveniently, without frustrations, and regardless of visual ability.

The full screen mode is definitely my personal favorite ☺️

- Kosta

Re: Build 159

 

Thank you Salman.

I agree that the new way to read back makes manual typing on the top row a little less forgiving, in that the top row is now only as forgiving as the other two rows. Before, the top row was more forgiving on the Y axis since you could be touching as high up as possible and still get a top row letter. In effect, the top row extended all the way to the top of the screen, in contrast to the two bottom rows. But I still think such a change might be beneficial overall, if we consider the benefits. Consider a related example, where we might add an option for a number row or commonly used symbols row above the QWERTY row. If and when we do that, the top row would need to be limited in height and reduced to be just as forgiving as all other rows, like it is right now in this new build.

Also note that this is technically not a new gesture in the entire system, but rather an extension of the existing long press gesture. The way I thought about it, is that all that space at the top is wasted when you are typing manually, and could be used for something more useful. It's now as if a new button was added on top of the QWERTY row than spans the entire keyboard width, and its label is always set to be your current text. And not being a new gesture also means that you shouldn't need to be any more careful or otherwise change how or where you performed the dismiss or next keyboard gestures - it should all be identical as before unless I botched something.

It's also important to note that the overall explore gesture we've always had is in a way already interfering with the dismiss or next keyboard gestures, in that you might sometimes get a manual letter entered instead of exiting the keyboard, or vice-versa. The difference now is that you might get your text read back to you instead of the manual letter, which also seems to be a more forgiving mistake, since at least you don't end up with a dangling extra letter somewhere. So if you had performed the exact same finger movements that you did just now, but on a previous build, you'd still have the same success when trying to switch to the iOS keyboard as well as delete the unwanted single character.

I'm open to hearing more about everyone's experience and thoughts about this, after giving it a few tries to adjust to the change.

Thank you,
Kosta