Posts tagged with “John Gruber”
- All (4)
- Entries (1)
- Links (3)
- Photos (0)
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.
John Gruber's Thoughts on the iPad
I especially liked this bit:
Used to be that to drive a car, you, the driver, needed to operate a clutch pedal and gear shifter and manually change gears for the transmission as you accelerated and decelerated. Then came the automatic transmission. With an automatic, the transmission is entirely abstracted away. The clutch is gone. To go faster, you just press harder on the gas pedal.
That’s where Apple is taking computing. A car with an automatic transmission still shifts gears; the driver just doesn’t need to know about it. A computer running iPhone OS still has a hierarchical file system; the user just never sees it.
Untitled Document Syndrome
Great post by John Gruber on how effective applications can be when they don’t require the author to ever “save” anything. For instance, he refers to iMovie, where the user never has to deal with saving a file somewhere–the application just figures it behind the scenes. Also check out Chris Clark’s response “By Proxy, By Proxy, By Proxy”, where he talks about how download windows could be helped by the very same idea.
Communicating with code
Paul Buchheit discusses how Gmail was first built: not by long meetings about strategy, but rather through prototyping. I tend to really enjoy this approach, because it allows you to actually try thing outs, instead of just discussing if a feature might work. It may mean having some truly awful code at first, but it’s a great way to really learn what works and what doesn’t, and I think with the rise of frameworks like Ruby on Rails and Django, this style of development becomes a lot easier.