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 Nick Butcher of Google UK take us for a walk through the new environment and introduce us to some of the UI conventions.
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 TechCrunch who discuss the UI in some detail here)
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 a very useful post by Dan Saffer of Kicker Studios.
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.
Although the TechCrunch article suggests that you instinctively look to the action bar (which, given that it is visually quite pushed back, seems to me to be an easily learned behaviour rather than a natural one), it qualifies this immediately by saying that you do this only if you can’t locate the action in the applications main UI.
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).
10 thoughts on “Ignoring the Android Honeycomb Action Bar Convention”
I would quibble with the conclusion on the Menu button on current Android devices; a persistent hardware Menu button is one of my favourite features of Android devices, and I use it frequently. Whether I’m in a minority or not, I don’t know, as I can’t see any data to back up the claim that “many people never hit [the Menu button]”.
you’re more than welcome to quibble on that point, it’s not really mine ;) but you totally reminded me about the *other* place that contextual actions go which is into the legacy menu ‘button’ in the system bar…. if it’s technically possible, I’m betting *this* would become the preferred ‘action’ location because it falls in the ‘easy’ zone. (Also, insert grumble about it being not very obvious that you’re using a legacy rather than native Honeycomb app).
Sounds almost like the action bar is some sort of weird right click substitute.
Placement: I’m not sure i’d agree with the heat map. It implies that you would hold device in the bottom corners. I’ve just tried doing this & it felt completely off. I tend to use mine either one handed (so reach is less of an issue) or holding it along the center of the sides which feels well balanced. This provides pretty ready thumb access to the outer thirds of the screen – (see http://flic.kr/p/9qANb8). This area includes both the navigation area on the left and the action area on the right of the action bar.
Content: The action bar should show common actions for the current screen. You can use the Contextual Action Bar for context specific actions – usually triggered by selection. Design guidelines are coming soon but in the mean time you can see some usage patterns here: http://j.mp/androidhcpatterns
Android is the best ever. People that are using Iphone or Ipad will sooner or later acknowledge Android is better. The future for Android is very bright compared to other OS. Thanks for this great post, Leisa.
Lisa, your Diagram shows a 4:3 iPad, yet the Xoom and other Honeycomb devices are 16:9.
The ActionBar actually works quite well in the widescreen format and is not a reach at all. I own a Xoom, and I’m not sure I would hold it the way in which you imply that one holds an iPad.
But more importantly, monitors, movies, and websites have moved to a Widescreen format. This fits that design paradigm so for the existing web and for apps that leverage their existing web design patterns.
I’m going disagree at even a higher level and state categorically that the Honeycomb OS is an over-complicated mess. It feels like a ‘Franken-OS’ designed by feature happy engineers for other feature happy engineers.
Anything that requires users to spend more than 10-15mins to figure out is unlikely to gain mass adoption. For some reason Google just isnt very good at UX. Search aside, Gmail & Maps are probably the most widely used Google apps with the latter still lacking in good design and overall UX.
Back to Honeycomb, my guess is that the next iteration will need simplify and cut back on the bells and whistles. There is simply no need to enable access to ‘Settings’ in 3 different areas nor display a carousel if it’s not going to behave like one.
Comments are closed.