

Finding an Optimal Keyboard Layout for Swype - ollyoxalls
http://sangaline.com/blog/optimizing_for_swype/

======
Zikes
Alternate keyboards have fascinated me ever since I first got a smartphone
capable of using them. My most memorable experimental trials were 8pen[1] and
one where the user would "slalom" from key to key as columns of letters would
move from the right side of the screen to the left, expanding the target area
in a fisheye type zoom as you neared your desired letter.

Unfortunately the name of the second keyboard evades me, but as a single-
finger input it was fairly efficient, and I believe targeted at disabled
people with limited mobility.

[1] [http://www.8pen.com/](http://www.8pen.com/)

~~~
ankurdave
The zooming keyboard sounds like Dasher:
[http://en.wikipedia.org/wiki/Dasher_(software)](http://en.wikipedia.org/wiki/Dasher_\(software\))

~~~
lucb1e
That is not too far from what I tried a while back:

[http://lucb1e.com/rp/js/testkb.htm](http://lucb1e.com/rp/js/testkb.htm)

It's a bit buggy and it could be hugely optimized, e.g. by placing the options
to the right in the center instead of aligning them on top, and you could
probably do something like make the keys a certain shape so you are less
likely to accidentally select another letter as you move to the right, but the
basic idea is there.

------
Terretta
First, loved the technical writing here.

Second, if we're willing to make people learn a different keycap arrangement,
why aren't we willing to make them learn a different physical layout? I
suspect a completely different physical layout would likely reduce the error
rate from confusion between keycap arrangements (e.g., you'll still have to
use QWERTY).

Anyone remember "Fitaly"? It was a big timesaver on my Compaq iPaq. From
Wikipedia:

 _FITALY is a keyboard layout specifically optimized for stylus or touch-based
input. The design places the most common letters closest to the centre to
minimize distance travelled while entering a word. The name, FITALY, is
derived from the letters occupying the second row in the layout (as QWERTY
comes from the first row of standard keyboards)..._

 _The aim of the design is to optimise text entry by organising keys to
minimise key-to-key finger movement, allowing faster input through one-finger
entry (compared to 10 fingers required to type efficiently on QWERTY layout).
As compared to the 3-row QWERTY keyboard, FITALY has 5 rows with at most 6
letters in a row (as against 10 on QWERTY)._

 _Keys are arranged based on individual frequencies of letters in the English
language, and the probability of transitions._

[http://en.wikipedia.org/wiki/FITALY](http://en.wikipedia.org/wiki/FITALY)

~~~
foob
I'm perfectly willing to make people learn all sorts of new things :-). We
focused on optimizing over the permutations of the key labels in this analysis
but we designed dodona [1] to be much more flexible. To demonstrate this, I
just threw together a quick little notebook [2] evaluating the average
distance traveled for FITALY. As you'd expect, it's much shorter than what we
find using a random configuration. We'd love it if people used dodona to
explore things more creative than permuting keys.

[1]
[https://github.com/sangaline/dodona/](https://github.com/sangaline/dodona/)

[2]
[http://sangaline.com/blog/optimizing_for_swype/FITALY.html](http://sangaline.com/blog/optimizing_for_swype/FITALY.html)

------
blister
This was a fascinating article. The first thing that jumped out at me when I
reached the end was "there's no way this would ever work."

I am a Swype user and love the product, but I'm reasonably fast at typing on
it because I know the QWERTY layout like the back of my hand. Switching to a
new layout would bring me back to a crawl. I'd probably be better off typing
on a 9-digit pre-smartphone keypad at that point.

Cool things to consider though. I love the idea of an alternate and more
efficient keyboard, but at around 140wpm, the idea of mentally and physically
training myself to learn a new one at this stage in the game is sub-optimal.

~~~
bluehawk
I actually don't think it would be that bad. Learning T9 wasn't so hard. And I
believe that the muscle memory for typing and swyping is totally different, at
least based on my anecdotal evidence:

I've used Dvorak on all my computers for about 10 years, but my phones are
still QWERTY. I've tried switching my phone to Dvorak, but found that the
typos were much worse (because dvorak clusters all the most used letters on
home row, which is close to the "worst" swype layout in the article).

For the times I tried Dvorak on the phone, retraining myself was indeed
cumbersome, but I don't think it was too bad. I thought that it would be
easier, since I had Dvorak in my brain, but the muscle memory for hitting a
key with a certain finger moving a certain direction is totally different from
swiping or taping a certain location on the screen.

~~~
imathew
I'm the same - I have been using Dvorak for twelve years, but that's all about
muscle memory with both hands, I struggle to type with it without two hands in
place. When I jump onto a colleague's computer I can use QWERTY OK because my
brain reverts to the old four-finger typing I used to do. I'm much faster at
Swyping on a QWERTY keyboard, though, because it's a different paradigm
entirely - it's more about movement than keypress.

------
kybernetikos
The first swype-like input system I used was the IBM Shark.

[https://gigaom.com/2004/11/03/text_entry_epip/](https://gigaom.com/2004/11/03/text_entry_epip/)

That had hexagonal keys and used the ATOMIK layout. It also focussed much more
on shape, with the intention being that once you were expert, you could write
words without looking at the keyboard, as the layout was just for guidance.
You didn't actually have to start on the letter as long as the shape was
right.

~~~
avani
I would pay a lot to be able to use ATOMIK as primary input again. Everything
since has been strictly worse for me.

------
elros

        > Back in the Day...
        > “Turn your pagers to 1993.” -Christopher Wallace
    

Love the Biggie references :-)

[https://en.wikipedia.org/wiki/The_Notorious_B.I.G](https://en.wikipedia.org/wiki/The_Notorious_B.I.G).

~~~
foob
I honestly wrote that entire section just so that I could work that quote in
:-)

------
NoGravitas
The article and the paper are a nice find that I plan to share on the Colemak
forum.

One thing I've found is that a layout that is highly optimized for touch
typing is terrible for swiping. I touch-type Colemak on hardware keyboards;
for those who don't know, it's a layout optimized for fast and ergonomic
typing in English (there are variants for some other languages), without being
as different from QWERTY as Dvorak is. SwiftKey supports Colemak out of the
box for English, so I tried it. I normally use SwiftKey Flow for writing long
bits of text on my tablet.

My experience with Flow and Colemak was that the rate of errors was much
higher -- there were far more ambiguities, mainly because many of the most
common letters are on the home row (arst neio), and so you're often just
swiping back and forth across the home row, which could mean anything. You
also end up having to swipe farther, because of more lateral movement from one
end of the keyboard to the other, and less top-to-bottom movement.

I'd be interested in hearing the experiences of anyone who's tried swiping on
a Dvorak layout.

One final note, if anyone hasn't seen MessageEase, they should check it out.
It's a compelely different model for typing that involves a very compact and
optimized layout to minimize finger movement, as well as a mixture of tapping
and swiping. If it had the benefit of SwiftKey's language model, I'd use it
for everything, but as it stands, I use it mainly where completion is not
available (e.g. in terminal sessions).

------
deegles
I actually taught myself an "optimized" keyboard layout called QGMLWY[1] and
got up to my normal typing speed. I had to go back to qwerty though because it
was too much overhead to get the layout on every device I use. I definitely
noticed an improvement in ergonomics.

My current project is building an Atreus keyboard[2] which will have the
QGMLWY layout in hardware, hopefully bypassing all the compatibility issues.

[1]
[http://mkweb.bcgsc.ca/carpalx/?full_optimization](http://mkweb.bcgsc.ca/carpalx/?full_optimization)
[2]
[https://github.com/technomancy/atreus](https://github.com/technomancy/atreus)

------
zan2434
This was really cool! I realize there are many DoF in this so pure
optimization likely wouldn't solve it, but I'd like to see an optimization on
the form of the keyboard itself in addition to just the ordering of the keys
(like minuum?)

~~~
Analog24
Technically it could be done and the framework we wrote allows you to create
keyboards of any geometry but, as you already pointed out, the number of
possible keyboards blows up with every extra parameter you add. Plus this
would be even worse for geometric parameters that have a continuous spectrum
of possible values. Given our modest computational resources we had to limit
our search. It already took about ten days to run the final optimizations on a
cluster with 256 cores.

------
anonymous1717
Of course, the inventors of Swype originally did this as well:

[http://www.researchgate.net/profile/Shumin_Zhai/publication/...](http://www.researchgate.net/profile/Shumin_Zhai/publication/228875756_SHARK_2_a_large_vocabulary_shorthand_writing_system_for_pen-
based_computers/links/0c96051688d4ace342000000.pdf)

They recently won a "lasting impact" award for this paper.

~~~
Analog24
That is an interesting article but it's not the same thing. The ATOMIK
keyboard, presented in the paper you reference, was designed to minimize the
movement necessary to spell words in English. We optimized the layout to
minimize the number of swipe patterns that create ambiguous input, i.e.
potential swipe errors.

Also, Cliff Kushler and Randall Marsden are the inventors of Swype, not the
authors of the paper you cited.

~~~
anonymous1717
Fair enough - the original inventors of gesture typing on keyboards, of which
swipe is a later and derivative example.

------
mwhelm
Interesting posting date.

My hunch, upon starting to read this article & looking at the patterns, is
that as soon as you arrive at an optimized keyboard layout, you have created a
new kind of cursive & you can dispense with the keyboard. You might need one
more optimization step to do it, but you can unfold the strokes patterns &
there you have a kind of shorthand.

------
edent
Fascinating - although I wonder if you're missing a trick by not looking at
misspellings?

I often don't know how to correctly spell a word. On T9 it can be difficult to
get a prediction if you don't know how many Cs & Ss there are in "necessary".

I find that SwiftKey (through which this comment is typed) is very good at
correcting my showing as I swipe.

~~~
hobarrera
THB, no keyboard can really overcame a user who can't spell. Much like a pen
can't overcome users who can't write, and dictation engines can't overcome
users who can't talk.

------
ffk
Sangaline: Can you add a visualization of the qwerty keyboard so that we can
compare it with your proposed best and worst layouts? :)

~~~
foob
Sure, here you go:
[http://sangaline.com/blog/optimizing_for_swype/img/qwerty.ke...](http://sangaline.com/blog/optimizing_for_swype/img/qwerty.keyboard.svg)

~~~
ffk
thanks

------
akkartik
Feature request for any swype hackers reading this: please allow me to type
punctuation using graffiti. Faster to draw a semi-colon with my finger than to
tap the modifier key, peck the semi-colon and then modifier again.

~~~
alphapapa
You can swipe from several punctuation keys to the spacebar...

------
mfontani
Hmm.. can one create a custom layout for SwiftKey, then?

~~~
Analog24
I think it's a bit more complicated than just rearranging the layout since the
autocorrect and the swipe interpretation algorithm are likely to depend on the
specific layout. This way you could optimize the calculations to speed it up.

~~~
alwaysdoit
Presumably they have to do a similar process when they add support for a
language. This would just happen to be a language which was Caesar cipher of
your existing language.

~~~
Analog24
Yes, I believe you're right. However, I don't think they're likely to do it
for a random user who wants to try a new layout given that each one of these
is not a negligible calculation.

------
Thiz
How about putting all the vowels in a middle row and the consonants in natural
order?

    
    
        BCDFG
        HJKLM
        AEIOU
        NPQRS
        TVWXYZ

~~~
Thiz
Or this three liner?

    
    
         B C D F G H J K L M
         ^ #  A E I O U  . ,
        N P Q R S T V W X Y Z

~~~
anigbrowl
These proposals at least have the virtue of being easily understanadable.
Getting familiar enough with either of them to use efficiently would take
time, but at least you'd know where to look for the letters. That's the major
downside to QWERTY (it's very arbitrary for most people) and the reason so few
people are willing to switch to some other apparently-equally-arbitrary
layout.

I can see how the approach here might not be that optimal in technical terms
but I think there's huge value in its conceptual simplicity. I find it easy to
imagine switching to it and getting up to decent speeds in a reasonably short
timeframe, which is more than I can say for other layouts I've looked at over
the years. Well done, both of you.

