bscofield

Not really sure why people keep calling this a Wikipedia clone - seems much closer to Squidoo than to Wikipedia, to me. Granted, that's a debate that's already been had and done (back in December, if I recall correctly).

* disclaimer: I have worked with Squidoo in the past, and still have a couple of lenses there. I'm not taking a position on which is better - just pointing out a better comparison.

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.

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.

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.

This just reinforces my impression that Carsonified is more of a marketing shop than a web development shop - they had as many PR people on the project as they did designers and developers combined??

Well, we've got 32 employees right now, but I wouldn't call us "large," really. Large to me is ThoughtWorks, or Sapient.

I'll be there - I'm speaking about REST and Rails on Saturday

Why late? I don't think the SDK will kill iUI (or iPhone web application development more generally) - it's targeted at a different developer audience.

I won the solo division for the Rails Rumble a few months ago. For me, the most valuable part of the competition was how inspirational it turned out to be. Seeing how much was accomplished under severe constraints (48 hours, max 4 people per team) shed new light on all my other development efforts.

I imagine that people who do well at such competitions would be better hires, but that would be due to other factors - passion for coding, good time management skills, etc. I doubt it's a major difference, though.

BA Philosophy & Biology - UNC Chapel Hill MA Philosophy - University of Maryland, College Park

I'll be speaking there, and at least three of my coworkers from Viget Labs will also be attending.

Plenty of benefits; improved support for REST is a major one, but there are tons of little fixes that make life much easier. The link in chaostheory's comment is a good overview, or (if you feel like spending $9 more) you can buy Ryan Daigle's Rails 2 PDF at http://peepcode.com/products/rails2-pdf - Daigle runs a well-respected blog that keeps track of the newest developments in edge, so was able to pick out the most important things to write about.