Daring Fireball on Android hardware buttons;
Looks like they’re trying to fix this starting with the Galaxy Nexus by eliminating the hardware buttons but drawing them on-screen in the OS. Presumably, a future API revision could allow for apps that don’t need these buttons. Anyway, agree with his criticism of these two buttons completely. The Back button taking me somewhere unexpected was perhaps my single-biggest complaint both times I tested an Android phone.
I agree, the designed ambiguity of the ‘back’ button is infuriating, mostly in the android app I created myself! I’m no programmer, I’m much more of a hacker (which doesn’t help either), but I’m never clear as a user when to hit the home button or the back button (or both). Home sometimes doesn’t kill an app — why?
Even better though, it goes on to outline a key difference between the apple and google design models;
The other lesson: the importance of getting things right, from the outset. If you’re designing just an app, you can fix many design errors later; if you’re designing an app platform, though, it’s hard to fix system-wide design errors without breaking existing apps.
This doesn’t mean get it right the first time, every time. It means you should only go to market when you’ve tested your product so thoroughly (iterating over and over again) and can say with complete certainty that not shipping it now is not good enough.
Constantly shipping unfinished, beta software products fools you into thinking you can do the same with hardware. Unfinished software thinking, applied to hardware, will only result in long term grief (especially if you’re relying on OEMs to provide your hardware for you).
I can only point to the iPod/iTunes experience and years of testing that allowed Apple to say, with certainty, that this v1 product was ready to be released. Google, on the other hand, only had google.com and a long running suite of software products to go by. Big difference.