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?)
Finding an Optimal Keyboard Layout for Swype
11–20 of 44 posts
Re: Finding an Optimal Keyboard Layout for Swype
#12Alternate 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…
The zooming keyboard sounds like Dasher: http://en.wikipedia.org/wiki/Dasher_(software)
That's the one!
Re: Finding an Optimal Keyboard Layout for Swype
#13This 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.
Re: Finding an Optimal Keyboard Layout for Swype
#14Alternate 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…
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…
Sounds interesting, I'll give that one a shot.
Re: Finding an Optimal Keyboard Layout for Swype
#15Hmm.. 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.
Re: Finding an Optimal Keyboard Layout for Swype
#16First, 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.
Re: Finding an Optimal Keyboard Layout for Swype
#17Earlier quoted context omitted.
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.
Re: Finding an Optimal Keyboard Layout for Swype
#18This 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. Coo…
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.
Re: Finding an Optimal Keyboard Layout for Swype
#19Sangaline: Can you add a visualization of the qwerty keyboard so that we can compare it with your proposed best and worst layouts? :)
Re: Finding an Optimal Keyboard Layout for Swype
#20I 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