I’ve been giving some thought to the loss of the menu button (replaced – in a way – by the action bar) in Honeycomb lately and I have to say it’s a damned peculiar choice. The argument is that by unifying the UI on Honeycomb fragmentation will be reduced, but for full-screen apps, taking away the menu button on API 11+ builds, from the region of the screen that cannot be hidden, fosters UI fragmentation.

Consider apps that are meant to be full-screen, and may be deeply interactive (such as a game). Having the action bar onscreen is not tenable, so one hides it. Whereas before you could use the menu button in the gutter (where “home” and “back” reside and indeed where “menu” appears – only for legacy apps), now you must either code your own button or invent a unique (but intuitive!) gesture to accomplish the end result of opening a custom menu or showing the action bar. If that’s not UI fragmentation I don’t know what is!

Though I find the action bar awkwardly placed and non-intuitive for in-app interactions, I understand the merit of having a unified UI. What I find fault with is the shortsighted decision to effectively remove an important hard button from Android (does anyone miss the “search” button?)

Now we have only two guaranteed (not hideable) buttons left, for the purpose of app navigation: “back” and “home” – along with a third new button for fast task switching (which is a little redundant… long-press on the home button could easily have the same effect without adding buttons). In addition (and likely for the foreseeable future) we have a “menu” button that only appears for legacy apps (thus that space in the toolbar is already “reserved” and will remain so for quite some time).

It’s too bad… there’s a strong argument for always having a “menu” button handy in an always-visible place. Maybe it unhides your action bar, or maybe it opens a custom menu, but removing it doesn’t help matters: it simply encourages a new kind of fragmentation for apps that don’t need an action bar onscreen normally. Now, instead of having a consistent way to perform that “open menu” action everyone gets to do it their own way (or leave the action bar open full-time, which significantly detracts from some apps).

One of many things that I like about Android is that the basic controls (home, menu, back) are intuitive and reasonable, balancing function with minimalism. Contrast this with the one overloaded hard button in another popular OS: much like a one-button mouse, oversimplification leads to confusion, reduced functionality and a fragmented UI as everyone works around the limitation differently according to their app’s design.

The rationale for taking away the menu button – one of the three main “always-visible” navigation and control buttons for Android up to now – defies logic: it fails at reducing fragmentation and funnels developers (and thus users) into an awkward, one-size-fits-all paradigm that is the antithesis of Android. This loss of a “hard” menu button is an unwelcome reduction in basic functionality in an apparent nod to the oversimplification of other OSes. I don’t find fault with the existence of the action bar, but removing the dedicated menu button from the always-visible area of the screen was IMHO extremely shortsighted. Now, instead of having a convenient way to reveal a hidden action bar, one must figure out how to do this for each app that normally hides its action bar. All this for the sake of removing a button that appears anyway for legacy apps.