4 ms·

I'm going to repost here what I did there, so sorry to anyone who reads both: I’m sorry, but I’ve read his defense – and this analysis – and I still say FAIL .

I'm going to repost here what I did there, so sorry to anyone who reads both: I’m sorry, but I’ve read his defense – and this analysis – and I still say FAIL . If speed’s the primary concern, why would you use the scrolling widget to enter the mileage? That’s going to be measurably slower and less accurate than a simple text field that pulls in the dialing/numeric keyboard. My impression is that they’re operating entirely without user testing – their intentions are correct (make if fast, etc.), but they’re unwilling, unable, or too rushed to verify their decisions by watching people use various alternatives.

dlytle 18y ago
I agree with the criticism of the scrolling odometer widget; that part sounds like it would be better handled with the keyboard. I'm willing to cut them a little slack on the "lack of user testing" angle; it's not like there are many App Store enabled iPhones available for real-world usability testing. That will limit a potential test pool to people the developer knows well... because I doubt he'd be comfortable handing his iPhone to someone less than a trusted friend to provide feedback.
- bscofield 18y ago
  Well, that's true. In this case, however, testing with novice users isn't exactly critical. The target audience here are repeat users, after all, so learnability is probably a lower priority than raw performance for a regular user. That means that the devs themselves could have tested, and I sincerely doubt that they would find the scrolling odometer faster OR more accurate than keyboard entry.
mechanical_fish 18y ago
My impression is that they’re operating entirely without user testing... So are lots of developers, I assume. At this point only certain selected individuals are allowed to transfer their iPhone app to an actual phone, right? (Unless they're using unlocked phones and the open development kits... which might have been a good idea. But let's assume they don't have the time or inclination to build an entirely separate app with a separate toolchain just to get an early start on user testing.) So for all I know that wacky scrolling widget will be quite usable. We should strive to suspend judgement. It was bound to invite ridicule, though, when viewed in a mockup. The odometer widget is such an obvious "duck" (to borrow a Tufte term [1]) that it's hard to avoid the suspicion that it was designed primarily for its looks, with usability as a distant second. It's also huge. It's hard to believe that's an efficient use of screen space. [1] "duck": a huge piece of distracting, nonfunctional decoration that's been applied to your graphics, generally for crass marketing purposes. Named in honor of a photo in Tufte's book depicting a roadside stand in the shape of an enormous bird.
dhbradshaw 18y ago
The odometer widget combines an entry mechanism with a display mechanism. That saves space. If it responds well enough to touch it might be nice to use.
gills 18y ago
Maybe. The scrolling widget has some advantages over a keypad. It has strong association with the physical odometer in the car (not all cars have odometers like this, mine does not, but it is a very strong association). The user doesn't have to find the label 'enter mileage here' -- it's obvious how to enter mileage, and if it spins (I don't know, but I hope so) it would be intuitive. The user doesn't go through a context switch away from the main screen to use a number pad. On the other hand, a power user is going to eventually associate screen locations with actions and never read the labels again. That form of association may be the reason for the brightly-colored buttons.
webwright 18y ago
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.

dlytle 18y ago

I agree with the criticism of the scrolling odometer widget; that part sounds like it would be better handled with the keyboard. I'm willing to cut them a little slack on the "lack of user testing" angle; it's not like there are many App Store enabled iPhones available for real-world usability testing. That will limit a potential test pool to people the developer knows well... because I doubt he'd be comfortable handing his iPhone to someone less than a trusted friend to provide feedback.

bscofield 18y ago
Well, that's true. In this case, however, testing with novice users isn't exactly critical. The target audience here are repeat users, after all, so learnability is probably a lower priority than raw performance for a regular user. That means that the devs themselves could have tested, and I sincerely doubt that they would find the scrolling odometer faster OR more accurate than keyboard entry.

mechanical_fish 18y ago

My impression is that they’re operating entirely without user testing... So are lots of developers, I assume. At this point only certain selected individuals are allowed to transfer their iPhone app to an actual phone, right? (Unless they're using unlocked phones and the open development kits... which might have been a good idea. But let's assume they don't have the time or inclination to build an entirely separate app with a separate toolchain just to get an early start on user testing.) So for all I know that wacky scrolling widget will be quite usable. We should strive to suspend judgement. It was bound to invite ridicule, though, when viewed in a mockup. The odometer widget is such an obvious "duck" (to borrow a Tufte term [1]) that it's hard to avoid the suspicion that it was designed primarily for its looks, with usability as a distant second. It's also huge. It's hard to believe that's an efficient use of screen space. [1] "duck": a huge piece of distracting, nonfunctional decoration that's been applied to your graphics, generally for crass marketing purposes. Named in honor of a photo in Tufte's book depicting a roadside stand in the shape of an enormous bird.

dhbradshaw 18y ago

The odometer widget combines an entry mechanism with a display mechanism. That saves space. If it responds well enough to touch it might be nice to use.

gills 18y ago

Maybe. The scrolling widget has some advantages over a keypad. It has strong association with the physical odometer in the car (not all cars have odometers like this, mine does not, but it is a very strong association). The user doesn't have to find the label 'enter mileage here' -- it's obvious how to enter mileage, and if it spins (I don't know, but I hope so) it would be intuitive. The user doesn't go through a context switch away from the main screen to use a number pad. On the other hand, a power user is going to eventually associate screen locations with actions and never read the labels again. That form of association may be the reason for the brightly-colored buttons.

webwright 18y ago

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.