8 ms·
Finding an Optimal Keyboard Layout for Swype
- Zikes 12y agoAlternate 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 12y agoThe zooming keyboard sounds like Dasher: http://en.wikipedia.org/wiki/Dasher_(software) http://en.wikipedia.org/wiki/Dasher_(software)
- Zikes 12y agoThat's the one!
- lucb1e 12y agoThat 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.
- jshholland 12y agoI 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/ http://fivetiles.com/
- kybernetikos 12y agoThe 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 12y agoI would pay a lot to be able to use ATOMIK as primary input again. Everything since has been strictly worse for me.
- mfontani 12y agoHmm.. can one create a custom layout for SwiftKey, then?
- Analog24 12y agoI 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 12y agoPresumably 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 12y agoYes, 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.
- blister 12y agoThis 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 12y agoI 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.
- dnautics 12y agoI use dvorak on all my computers, but in my experience dvorak on the phone is terrible because the vowels are clumped together.
- imathew 12y agoI'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.
- zan2434 12y agoThis 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 12y agoTechnically 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.
- Terretta 12y agoFirst, 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 12y agoI'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
- ffk 12y agoSangaline: Can you add a visualization of the qwerty keyboard so that we can compare it with your proposed best and worst layouts? :)
- deegles 12y agoI 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
- elros 12y ago> 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 12y agoI honestly wrote that entire section just so that I could work that quote in :-)
- akkartik 12y agoFeature 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 12y agoYou can swipe from several punctuation keys to the spacebar...
- Thiz 12y agoHow about putting all the vowels in a middle row and the consonants in natural order? BCDFG HJKLM AEIOU NPQRS TVWXYZ
- Thiz 12y agoOr 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 12y agoThese 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.
- edent 12y agoFascinating - 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 12y agoTHB, 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.
- mwhelm 12y agoInteresting 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.
- anonymous1717 12y agoOf course, the inventors of Swype originally did this as well: http://www.researchgate.net/profile/Shumin_Zhai/publication/228875756_SHARK_2_a_large_vocabulary_shorthand_writing_system_for_pen-based_computers/links/0c96051688d4ace342000000.pdf http://www.researchgate.net/profile/Shumin_Zhai/publication/... They recently won a "lasting impact" award for this paper.
- Analog24 12y agoThat 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 12y agoFair enough - the original inventors of gesture typing on keyboards, of which swipe is a later and derivative example.
- NoGravitas 12y agoThe 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).