Finding an Optimal Keyboard Layout for Swype | Hacker News Reader

Finding an Optimal Keyboard Layout for Swype

sangaline.com

103 pointsollyoxalls43 comments

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/

The zooming keyboard sounds like Dasher: http://en.wikipedia.org/wiki/Dasher_(software)

That's the one!

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

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.

I also used that keyboard for a short while. Currently, I use 5 Tiles [0]. I can get to 20-30 wpm with it, which is acceptable, though not as fast as a regular keyboard. The killer feature is that it takes up less than 10% of the screen, rather than the ~40% a conventional one would.

Gripes: it's not great for symbol input (you have to remember all sorts of crazy zigzaggy patterns, or pull up a list which defeats the whole point of not taking up half the screen) and auto-capitalisation doesn't really work. But I use it as my regular keyboard and it does the job.

[0]: http://fivetiles.com/

Sounds interesting, I'll give that one a shot.

KiiKeyboard had an option to scale down the size of the keyboard, but has since been removed from the play store due to licensing issues related to "emoji plugin" packs downloaded separately

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

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/

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

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.

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.

I use dvorak on all my computers, but in my experience dvorak on the phone is terrible because the vowels are clumped together.

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.

There was a submission on here a while about stenography and stenotype keyboards (actually it was about an open-source library for them called Plover [1]). These are the machines used by court reporters to achieve the fastest typing speeds (which in some ways makes them superior input devices that we could learn from). One thing that struck me was that over time each stenographer develops their own "dictionary" by essentially defining macros in the embedded software.

This got me thinking - what if we made a product like this that was given to children, that gradually mutated over time, learning from the usage? Ideally by the time they get to high school they would have these input devices that more organically map to their brains and they would be able to effortlessly type at extreme speeds. We might even be able to solve the sharing problem if the configuration is pure software, like the keyboard with OLED displays in each button. But that also might not be necessary if they were portable/virtual/wearable such that it would be natural to carry at all times.

[1] https://news.ycombinator.com/item?id=8510409

The thing is, while I used to know QWERTY fluently, since I switched to Colemak a few years back, I have to hunt and peck a bit on QWERTY keyboards. But it's not a problem when using Swype.

I think this is because you're looking at the keyboard anyway. My guess is that whatever layout you use, it won't be hard to memorize when it's right in front of your face as you use it.

I'm a SwiftKey user but I rarely use the integrated Swype because the prediction engine is ridiculous. It usually predicts what I'm going to say in two letters per word. It can be logged into your Twitter, Facebook and Email (iirc) to learn your sentence patterns. It feels slightly creepy but it's unnerving in its accuracy. Maybe I just say the same stuff a lot?

Being used to qwerty you (and I) would probably take months, maybe even a few years to get used to change.

But people who are only now getting into tech (and kids) can learn this layout as a first layout. Within a generation, it's possible to have people using entirely this ultra-efficient keyboard.

IMHO, the only downside, is that it does not take into consideration non-english. I use the same keyboard for English/Spanish, but I suspect that the new layout will not perform equally well on all latin-derived languages that currently use the same qwerty layout.

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

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.

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

    > 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.

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

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).

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 [2] https://github.com/technomancy/atreus

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?)

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.

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

http://www.researchgate.net/profile/Shumin_Zhai/publication/...

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

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.

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

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.

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.

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.

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

Sure, here you go: http://sangaline.com/blog/optimizing_for_swype/img/qwerty.ke...

thanks

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.

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

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

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.

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.

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.

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

    BCDFG
    HJKLM
    AEIOU
    NPQRS
    TVWXYZ

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

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.

Reply on news.ycombinator.com