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



Join alpha@flicktype.groups.io to automatically receive all group messages.