I’m working on the UX for an application for the new Android Honeycomb User Interface (UI). This is the first time I’ve designed for this operating system and we were fortunate enough to have
If you’ve not yet had the pleasure, you can take a look for yourself here:
There’s a lot to like about the Honeycomb OS in my opinion, especially once you get to know it a little and learn what the many icons that litter the interface actually refer to, however there is one UI convention that really bothers me, and that in this application we are going to largely ignore and that is the action bar.
This is the action bar (screenshot borrowed from
So, the action bar is application specific and context specific within an application. The idea is that you put any actions you may need in that part of the application into the action bar where you can then ‘take action’, the more contextually relevant the action, the further to the left, the less relevant and more global, the further to the right.
Now, it is A Good Thing that there is a convention for this, especially in an open source environment where designers/developers play fast and loose with the interface and the overall experience of using the device running this platform suffers as a result (as, having played with a Xoom for several days now, I can report is definitely the case).
The implementation, however, I’m less thrilled with, particularly as I’m confident it will actually encourage designers to ignore or duplicate the action bar’s functionality within the interface… and here’s why.
Here’s a ‘heatmap’ of the activity zones for a tablet in landscape mode from
Note that the red band labeled ‘reach’ (indicating that you have to reach to access this zone and it is not an easy or comfortable activity) corresponds almost exactly with the Action Bar.
This means that, if you follow Honeycomb’s UI conventions (in the hope of making the ecosystem of applications a good user experience with some potential hope of ever rivalling Apple’s iPad), you have three options: make the actions people need to perform ergonomically awkward (the xoom, for example, is no lightweight and unless you’re resting it on a table or your lap, requires some juggling in order to hit an item on the action bar, this juggling also makes the selection significantly less accurate), duplicate the actions in the bar and in the application UI, or ignore the convention and put the actions that are most contextually relevant in a place that falls with in the ‘easy’ activity zones.
I doubt that the designers of Honeycomb intended the action bar to replace in context calls to action, and neither it should, but it seems to me that it means that the actual use of the action bar is now very ambiguous. The more I design for this environment, the more I’m finding that the action bar actually feels much more suitable to application-wide actions rather than contextual – not the least because it is often visually quite removed from the content it is acting on.
This is a significant iteration on the previous Android software and, as our friends at TechCrunch say: ‘…at least people will actually be able to find these options, which is more than can be said about the options hidden behind the ‘Menu’ button on current versions of Android (which many people never hit).’
At the same time it feels like a rather awkward solution to this problem and certainly one that wasn’t really thinking about the mechanics of using a tablet in the wild.
As someone with an existing interest in design and UX for open source, I’d be really interested to hear what other designers who are encountering this convention are making of it. I’d also like to hear about whether the option of placing the action bar nearer to the ‘easy’ activity zones was considered and how that played out.
I’d really like to see Honeycomb evolve, and for good and clear UX conventions to emerge in this space so that we have a really solid alternative to the closed and ever more controlled world of Apple
(disclaimer: I own Apple gear. I know it’s great).