November 13, 2007
Key UI differences between Android and iPhone
Comparing the iPhone and Android UI environments at this point is a little treacherous: The iPhone has already shipped but Apple has not released an SDK, and Google has released a "preview" SDK but has not shipped any phones.
Hard buttons
However, one key difference appears to be the approach to hard buttons. The iPhone approach is to minimize the number of hard buttons, with only one special function button, the "Home" button that returns the user to the top-level application launcher menu. The Android approach appears to be, provide several commonly used functions as hard buttons.
The Android preview SDK emulator provides at least three hard buttons for commonly-used functions: Options, Back, and Home. The Home button appears to have a nearly identical meaning to the iPod's Home button. Back is a navigation button that takes the user to the previous view/screen. Options provides a context-specific Options menu.
In general I prefer the Android approach. I often switch between a compact Sony-Ericsson JP-6 flip phone that has a hard Back button and Nokia Series60 smartphone that does not. When the Back button is missing, I certainly miss it. The Sony-Ericsson phone does not have a Home function, however, and I miss that too. I use both functions frequently.
With the iPhone, the missing Back button means that nearly every application needs to consume significant screen real estate with an ugly Back touchscreen button. (This button can't be tiny because the user's finger needs to fit it.) My guess is that the Back button will be one of the most frequently used buttons in the Android interface, and its meaning is clear: go Back to the previous screen. This is necessary for the compact, single "window" displays that work well on mobile phones.
The benefit of Options/Menu button is a little less straightforward. Clearly the Nokia Series60 UI relies heavily on a context-sensitive Options softkey menu. It's also a mainstay of traditional J2ME user interface design, where phones were typically limited to two softkeys. The key assumption here is that on any given screen, there are two things the user might want to do: the default action, and "something else". When you're scrolling through a list of phone book entries, for example, the default action might be Call to call the highlighted person in the phone book. The "other" actions might include Edit, Email, and Delete.
With the iPhone, the default action is usually invoked by a single tap on the item. To access the extended actions, you again need a touch button to e.g. Edit. This leads to some harrowing tradeoffs for designers: Should you put both Edit and Email buttons into the phone book list? If, in a second version of the application, you want to add another extended action, do you cram that into the list item as well? With the Android Options menu, you have a bit of flexibility, though, as a designer, you still need to worry about overusing or abusing your Options menu.
One interesting side note on hard buttons is that the Android SDK shows an inactive Cancel button. Google, please don't try to push this button. It's unnecessary.
Touch screen optional or required?
Clearly the iPhone (and iPod Touch) rely on the presence of a touchscreen. Without the touchscreen, you have an older iPod such as the nano. It's a completely different interaction model, with a scroll wheel and the commonly-used audio navigation buttons.
Android, on the other hand, seems to have taken a touchscreen-optional approach. With the built-in web browser, for instance, you can navigate between hyperlinks using either 5-way navigation that jumps from link to link, or by clicking directly on the link you want. The user can browse one-handed with the 5-way navigation or perhaps click directly with a thumb or forefinger.
The Android approach is more flexible in general as it's easy to imagine building both touchscreen and non-touchscreen devices that run Android. The touchscreen capability simply complements what's already possible with the 5-way navigation.
Soft or Hard Keyboard?
The jury's still out on this one. Some people honestly prefer the touchscreen keyboard, and of course this type of keyboard means you can fit more screen in a smaller form factor. However, many people prefer typing on actual keys, with tactile feedback.
For UI designers, the hard or soft keyboard question raises a couple of differences. One is that with a hard keyboard, it's easier to have keyboard shortcuts, and the Android platform is loaded with them. Frankly, this is dangerous. Even among the sample Android applications there appears to be little consistency in the use of keyboard shortcuts, and this can potentially lead to an explosion of shortcuts users need to memorize.
The other difference is that, with a soft keyboard, you lose a significant chunk of your screen real estate as soon as the keyboard is popped up. This is a little disconcerting to users. With a fixed-size hard keyboard, at least you know your screen layout won't jump suddenly as soon as you start typing.
November 12, 2007
Google Android SDK analysis
As you may know, Google recently released the first Android (Open Handset Alliance) SDK today. Here's a brief summary of points that might be interesting to some of you.