4 ms·

Hrm-- it'd be interesting to time the two options. With a text field you have a tap to edit, a tap to switch to the numerical keyboard (unless you can start th

Hrm-- it'd be interesting to time the two options. With a text field you have a tap to edit, a tap to switch to the numerical keyboard (unless you can start there with the SDK), a tap for each # (say 3 on average), and a tap to save the record and send the keyboard away. That's 5-6 taps with a fair bit of distance between them on the screen, assuming that you don't have to drag the largely keyboard-obscured screen around to see other data ("I know I it's a few miles further than the post office... What did I enter in for that?"). OTOH, I just tried to simulate the odometer with the alarm clock setting controls on the iPhone (which is similar) and the flick-tap that it allows is pretty damn fast with zero major screen changes. I find the iPhone keyboard to be a PITA and typos abound, even after practice. Editing a text fiend would bring up the keyboard, obscuring a LOT of info. I'm not disagreeing, per se-- just saying that it's not so cut and dry that I wouldn't test the two side by side for speed/learning curve.

bscofield 18y ago
At least with iPhone web apps, you can bring up the numeric keyboard by default - and with two fingers, it's much faster and more accurate for entering digits than the scroller (I use alarm clock quite often, and can't stand it - overshooting numbers all the time, for instance). You're correct that the keyboard would obscure the rest of the interface, but you shouldn't often need to see the rest of the screen when entering mileage. If it's a frequent trip, for instance, you'd just use the frequent trip shortcut.