I have to agree with Kosta here. About the keyboard size, the smaller
toggle quoted messageShow quoted text
it gets, the more the possibility of accidently tapping above the top
row. It must be noted that many people have no usable vision at all to
help them in visually seeing the boundry (where the keyboard/typing
area ends and the app screen begins). Considering how Flicktype works
(which is, simply tapping in the general vicinity of the letter you
want, rather than touch typing or exploring the keyboard), having a
smaller keyboard size will be less forgiving for such users, rather
than users who have some degree of usable vision to assist them in
determining the boundary of the keyboard area.
For many with no usable vision, the only way to determine where the
iOS keyboard ends for instance, is by exploring the keyboard and since
that is not how Flicktype is supposed to be used (apart from when
manually entering a word), I do think there needs to be a difference
in the sizes of the iOS keyboard and the Flicktype keyboard. Just to
provide some leeway and that slightly extra bit of room for error.
Therefore, I do not agree at all that the keyboard size should be
exactly, or extremely close to the iOS keyboard size, as that
increases the possibility of accidental taps above the keyboard area.
Also keeping in mind that the way it's set up, accidentally tapping
outside the keyboard area will end up entering the text immediately
into the text field, which can cause even more confusion as to where
one is in terms of typing.
I also want to say that a full screen keyboard option as it exists in
its current state should also always continue to be provided for those
who don't find the half-screen keyboard very benefitial, or too
Coming back to the keyboard size, maybe a happy medium would be to
provide different options for adjusting the size to suit the users
needs. Like, 60%, 55%, 50% and so on. Without compromizing on any of
the other functionality of the keyboard of course.
Just my thoughts.
On 7/5/18, FlickType <email@example.com> wrote:
Thank you Ed.
Regarding the size of the keyboard, we have to balance being able to
interact with the rest of the current app you are in, as well as preventing
accidental taps while you’re typing that happen to be above the keyboard.
That said, a little smaller than the current size might be best.
When you say there is no benefit as it currently is, do you not find it more
convenient that you can access things like the send button in messages
without having to first dismiss the keyboard?
On Jul 5, 2018, at 13:00, Ed Worrell via Groups.Io
This is a great first step. I would love to see the size of the keyboard
foot print decreased dramatically. As it sits this would not be functional
for me at all. There would be no benefit to me to have the top of the
screen showing. If it were even slightly bigger than the default iOS
keyboard that would be great. A half scree mode would even be a little
better than the current size. For me the closer you can get to the default
size of the iOS keyboard the better.
Great job as always,
On Jul 5, 2018, at 1:49 PM, FlickType <firstname.lastname@example.org> wrote:
You will probably need to revert back to build 131 after this, but we
really wanted to get a very first round of feedback and ideas on the
half-screen mode that has been in the works for some time now. In this
highly experimental build, the keyboard will only take up 60% of the
screen height in portrait mode, and will always take up the entire screen
in landscape mode as before. We are looking for feedback on what the
biggest issues may be that prevent you from utilizing the keyboard as
you'd expect. Assuming we eventually get this to work properly, we are
considering having an option and/or a gesture to toggle between full
screen and half screen modes, as well as eliminating the dismiss function
For those who'd like to know the details, here's what's going on behind
the scenes: As before, FlickType does not immediately send keyboard
events to the textfield, in order to prevent problematic VoiceOver
feedback which includes delay, stutter, and perhaps most importantly a
lot of erroneous feedback such as "End of document" which would happen
with almost every word typed or changed. Instead, FlickType will hold on
to all the new text you have typed, and only commit the changes upon
dismissal or switching to the next keyboard. But with the half-screen
mode, FlickType will also commit all changes as soon as the VoiceOver
cursor moves away from FlickType. This means that as soon as you touch
above the keyboard, you will hear the text being entered in the
textfield. In principle, most users shouldn't even realize what's going
on since the text will appear to be in the field as expected. I should
note, however, that I've experienced instances where the cursor will move
outside of the keyboard, but iOS will not notify FlickType about it, and
the only solution in that case is to make the keyboard active again
either by touching it directly or by moving to the next screen element,
and then touch above the keyboard once more. I have no sense of how
common this may be under normal use.
Eager to hear back any and all feedback you may have.
Thank you for testing,