A usability cornerstone is making users aware of the current (relevant) settings of an application without disrupting their flow by presenting e.g. confirmation boxes.
For instance, when wanting to enter capital letters on a smartphone keyboard, users need to be assured they are actually in a mode that enables them to do so.
iPhone and (HTC) Android approach this scenario in different ways.
The iPhone way: Highlighting one button only
On iPhone, the keyboard looks this way when Shift is NOT turned on:
…and when Shift IS turned on it looks like this:
The only indication of the change of modes is the highlight of the Shift button.
The (HTC) Android way: Changing all keys
The (HTC) Android with Shift turned OFF looks like this:
…and with Shift turned ON like this:
Bottom line: Indicating the mode in-place is beneficial
As is evident from the screen dumps, two indications of the change of mode is present in the case of (HTC) Android:
- The Shift key is highlighted (though subtly) as on iPhone
- The virtual buttons display the capital instead of the lower case letters
While iPhone takes on an approach resembling the keyboards of desktop and laptop computers, (HTC) Android utilizes the “non-physicality” of the buttons and alters their display values.
This way the indication of the current mode is “spread across” a larger part of the (already limited) screen real estate, potentially reducing the risk of users being in doubt whether they are in their desired mode.
UPDATE: My actual point
A friend reviewing this post noted that my actual point got lost somewhere in translation – and he is absolutely right. I’ll attempt to clarify what I think is the lesson – in all it’s unscientific glory – from the example presented above:
The more direct – yet uobtrusively – a pertinent setting of an application can be conveyed to the user the better. By “direct” I mean in terms of close relation (e.g screen distance) to the “data” object or action which the user is currently working on or engaged in.