iPad Keyboard Fragmentation

As usual, I enjoyed reading John Gruber’s musings on the iPad. I was intrigued most, however, by his thoughts on the iPad’s support for hardware keyboards:

Having used the hardware keyboard yesterday, though, it is clearly a secondary form of input. You cannot even vaguely drive the iPad interface by keyboard alone. […] There are some glaring holes. For example, in iPad Mail, when you start typing in the To: field to address a message, and the iPhone-style autocomplete suggestion list appears under the field, you cannot select from it using the keyboard. You have to touch the screen. […] It just seems like it’s not finished yet.

What struck me as interesting is how similar this is to Android development’s biggest drawback: hardware fragmentation. Due to the vast array of Android devices, app developers have to consciously design their apps to support several different input methods. This may seem fairly trivial, but it is actually a fairly significant problem, especially for games and more complex UIs. In the Android Market, some games and applications just don’t work without a hardware keyboard, likely because the app developer didn’t take the time to consider touchscreen input. Apple seems to now be encountering this problem as well.

Maybe John’s right, and this is a rough edge that will be smoothed over when the device launches. But, there’s more to it than just fixing iPad Mail. What about the 140,000 apps in the App Store? They certainly weren’t built with any considerations of keyboard navigation, so the experience is likely to be sub-par, unless the developer has taken the time to support an input method that he or she might not even have access to (assuming he or she doesn’t own an iPad).

If keyboard support is solely intended for text input, as John suggests, a lot of users will be confused. Standard operations, such as tabbing between fields and navigating via arrow keys, are expected behavior when a user is given a keyboard. It would be frustrating to have that taken away. Certainly, Apple could fix this issue by the time the iPad hits the market, but for a platform that preaches ease-of-development due to the uniformity of its hardware, it’ll be interesting to see how it’s handled.

Posted on January 28, 2010 • 1 Comment
Tagged with: Apple, iPad, keyboard, Fragmentation, Android, John Gruber

Three Weeks with Swype

Roughly three weeks ago, I stumbled across the Swype for Android preview. My first impressions were very positive, and over the last three weeks, I’ve been using Swype exclusively on my Droid. If you’re not familiar with Swype, it’s a new method of typing on a touchscreen device, from the inventor of T9. Instead of tapping out each letter, you just drag your finger across the keyboard, hitting each of the letters in the word in sequence. I recorded a short video showing its basic features:

What I Liked

What really surprised me about Swype was how quickly I was able to get the hang of it. When I watched demo videos, it seemed like it was overly-complicated, but once I used it myself, I couldn’t believe how simple it was. For some of the less intuitive features (such as capitalization, which requires you swipe above the keyboard), I had to run through the built-in tutorial, but after that, I could swipe very easily. One big perk with Swype is that it’s actually pretty easy to use without looking, once you get the hang of it. I found that I could type reasonably well without ever looking at my fingers, something I would have no chance of doing with the standard keyboard.

Drawbacks

My biggest gripe with Swype is it’s just nowhere near as polished as the built-in keyboard. For starters, it’s much more difficult to access symbols, and numbers are laid out pretty strangely. Also, there’s a complete lack on auto-completion for text fields that support it. For instance, if you’re typing the name of a contact in landscape view, the regular Android keyboard will have suggestions below the field that will allow you to select the person without typing their whole name. Swype does not seem to support this at all, which is really pretty annoying. In addition, it’s difficult to type out words normally, if they do not exist in the Swype dictionary. When tapping out letters, Swype tends to interpret your taps as swipes, adding unnecessary spaces between letters. Once you type an unknown word the first time, however, you never have to do it again, because it gets added to the dictionary, which is pretty nice.

In addition, I’ve found that the sensitivity of the keyboard can be a little strange when swiping quickly. Many times, it won’t recognize that you’ve stopped a word and started a new one (which is indicated by lifting your finger up), so it won’t recognize what you’re trying to input at all. In the options panel, there are ways to adjust the sensitivity, but I’d rather these settings were hidden away from users, because it seems like a bit of a cop-out. Swype should instead learn how you type, adjusting its algorithm as necessary.

Conclusions

While there certainly are some issues with the Swype build I used for this review, pretty much all of problems are fixable, and I’m excited to see what the final version turns out to be. They’ve got a really great concept that, with tweaking, could become the best way to input text on a touchscreen mobile device, especially for those who aren’t very adept with traditional on-screen keyboards. I’m not sure what Swype’s strategy is going be with regards to pricing: whether it will be a free app, or if you’ll have to pay for it. Personally, if they’re able to fix my issues above, I would be happy to pay $5-6 for it, and maybe even more, because it really is quite incredible. Even if you can type well with the standard keyboard, definitely give Swype a try.

Posted on January 15, 2010 • Leave a Comment
Tagged with: Swype, keyboard, Input Devices, Motorola Droid, Android, Video, Mobile Phones