A View from John Pavlus

Two Ways to Fix the Typing-on-Touch-Screens Problem

One solution to the typing-on-a-screen problem asks us to change our behavior; the other changes its behavior to fit us.

Considering how much typing on a glass touch screen blows in comparison to using hard keys, it’s easy to imagine how BlackBerry saw the first iPhone back in 2007 and thought, “Bah, this isn’t a threat.” We all know how that turned out. But typing on glass still blows, and voice dictation on mobile devices (while pretty awesome) isn’t a good fit for every situation. So how can we un-blowify touch-screen typing? Two interesting software -design approaches have recently emerged: one rethinks how the keyboard looks, while the other rethinks how the keyboard acts. (Spoiler alert: I think the latter has more potential.) 

KALQ, an experimental system developed by a team of HCI researchers including Per Ola Kristensson (whose distraction-reducing display interface I wrote about here), takes the standard QWERTY keyboard layout and redesigns its layout to reflect mobile-device usage patterns (well, one in particular: gripping a phablet or tablet in landscape view with both hands and typing with one’s thumbs). KALQ takes its name from its redistribution of the QWERTY keys. It splits the keyboard into two mini-keyboards: one on the left, one on the right, each positioned within easy striking distance of the thumb on each hand, with the letters laid out in such a way to maximize efficiency. For example, the researchers discovered that oft-typed words like “on,” “see,” “you,” and “read” must be typed solely with one thumb if the QWERTY keyboard is simply split in half. Typing entire words (even short ones) with one thumb is slow and awkward. So they redistributed the keys across the two “boards” to make a better ergonomic fit for these word-usage frequencies.

The result? A 34 percent boost in typing speed. The catch? It’ll take four to eight hours of training to be able to use it at a level of fluency equivalent to a standard QWERTY keyboard, and more hours to get faster. 

Meanwhile, a startup called Syntellia has created a soft keyboard called Fleksy that is also dedicated to making touch-screen typing less cumbersome. It’s still a QWERTY keyboard, though. Fleksy uses a beefed-up autocorrection/prediction engine under the hood to minimize typing errors. It’s so beefed-up, in fact, that you can use it to type accurately without even seeing the keys. So blaze away as fast and out-of-control on your glass screen as you like—Fleksy’s software will mop up your mistakes. (In theory. I tried it myself on iOS and was encumbered by the weird gesture it makes you use instead of hitting a space-bar button. If they’d kept that in, I’d have been much faster.) 

Both KALQ and Fleksy are flawed but technologically impressive solutions to similar problems. KALQ, though, seems like a design solution wrought in a vacuum. It asks, What if we could redesign keyboards from scratch to better fit how we use mobile devices now? The trouble is that keyboards don’t exist in a vacuum, and they don’t only exist now. The QWERTY layout is an interface that, over the past 135 years, has become culture: it exists across many domains, anywhere that text input goes into a machine, not just touchscreen mobile devices in 2013. It’s what people expect when they have to or want to input text with their hands. Sure, the original technological reasons for that QWERTY layout–to prevent jams in the physical mechanism of late-19th-century metal typewriters—no longer exist. But what does exist, and has for well over a century, is the cultural expectation that keyboards equal QWERTY. 

So, do you take that fact into account when designing a solution to this problem—or ignore it? There’s no “right” answer, but the Fleksy approach seems less likely to fail completely, because it doesn’t seek to shrug off all that cultural weight that QWERTY has. If the real design problem being addressed is “How can we make soft-key typing faster?” then you might wonder, “What slows people down when typing on soft keys?” Is it ergonomics or something mechanical—a feature of the system? Or is it an outcome of those ergonomics? What slows me down when I type on a touch screen isn’t the lack of haptic feedback or suboptimal key arrangement. What slows me down, really, is the outcome of compensating for the limits of the system on glass screens—that is, my own error-correcting behavior: I have to stare at the keys to make sure I’m pressing the right ones, move more slowly, or back up and correct what I mistyped. So if this manual error-correcting behavior is what is slowing me down in this context, perhaps the solution is not to redesign the keyboard into a wholly-unfamiliar-but-somehow-technically-optimized arrangement, and ask me to learn it, even though this new learning will not apply to any other manual text-input task I’ll ever encounter—but simply let me keep doing what I already know how to do, while relieving me of that error-correcting burden. Keep the QWERTY—the cultural artifact I’m already an expert user of—but add software that minimizes my errors so I don’t have to slow down. This is what Fleksy aims to do.  

Granted, KALQ’s alternative layout is a logical reaction to the fact that when you try to solve the ergonomic problem (splitting the keyboard into two pieces that live on either side of a device’s screen, easily accessible by your thumbs), some of QWERTY’s advantages simply break—so there was no choice but to rearrange the keys in order to commit to that ergonomic solution. In light of Fleksy’s approach, though, I just wonder if that tradeoff is really worth it. 

And Fleksy doesn’t work perfectly yet either—not even close. But that design approach somehow seems more human-friendly, in the larger context of keyboard usage. It’s to their credit that both Fleksy and KALQ’s creators have not simply conjectured from armchairs about what would, could, or should work: they’ve put in an impressive amount of research into identifying and implementing their respective solutions. Still, that research—and the solutions it suggests—derives from asking very different questions about what this typing problem really is.