If Android's options menu key is frustrating you, read three tips from developer William Francis on how you can improve your user experience.
One differentiator between the iPhone and Android user experience (UX) is the dependence on four "hard" keys. Google's Android OS requires hardware vendors to provide home, search, back, and menu keys for proper navigation. As an Android developer and user, I am frequently frustrated by that pesky menu key. While I certainly see the advantage of having the menu key (particularly on some of the lower resolution Android devices where screen real-estate is precious), that doesn't change the way I feel about it.
The issue for the developer is not a technical one; it's not difficult to program the options menu that is presented when the user presses the menu key. And the user has no problem pressing the menu key. The struggle for the developer and the user alike is when and how to use the options menu. I can't begin to tell you how many support emails I've received where a user complained about having no way to do this or that when in truth the functionality already existed, but required the user to press the menu key to be presented with the option.
Creating the perfect Android UX is a bit of a balancing act between conserving limited pixels and not forcing the user to hunt too hard for what he or she is trying to do. Google has a lengthy list of Android User Interface Guidelines available for developers as part of its best practices series. I recommend reading the entire document, but for this post, I'll touch on three of the items most relevant to the options menu paradigm based on my experiences.
1: Before adding an item to the options menu, consider fixing it directly on a screen.
Within your app there may be certain actions you never want the user to have to hunt for; in these instances, using a button, listview, or even a touch-enabled graphic will immediately grab a user's attention and is a more appropriate design choice.
At times things get sticky, and it becomes a bit of a judgment call; however you can see a straight-forward example in any SMS application. The "Send" button is prominently displayed. You wouldn't want your user to have to press the menu key, and then select "Send" while trying to carry on a conversation via text messaging. In the same vein, the options menu is exactly the right place for the "Settings" item. Placing a button for configuring the application's settings permanently on the main messaging UI would be a gross waste of screen real estate, and it would get in the way.
2: Keep names and icons simple
Google's UI framework will truncate option menu names to make them fit into a layout. As a developer you get no control over this truncation, and it's possible the resulting shortened version of your menu item will be incomprehensible.
Similarly, while there is nothing stopping you from using complex full color icons in your options menu, the OS controls the highlight color and a number of other factors concerning the appearance, including the background and the graphical divider. I've seen some resulting combinations that look fine on one phone or version of Android and yet would make a color-blind squirrel cry on another. Remember that unlike iOS, Android developers are trying to support myriad display sizes, resolutions, as well as third-party UI themes and overlays (think HTC Touch). Simple, single color icons with transparent backgrounds will insure your menus look sharp across the widest variety of devices.
3: Avoid slippery menus
Sometimes a menu option is not valid. For example, when using a media player, it makes no sense to allow the user to choose the menu option to "Download Lyrics" if no song is selected. At first glance it may seem the right design choice is to simply to hide this option until the user chooses a song. I like to call menus with items that appear and disappear "slippery menus." While this approach may work well on some platforms, I highly discourage "slippery menus" on Android because the Android UX is not as consistent or as intuitive as it is on some other mobile devices.
Each app presents the user with a bit of a learning curve. We need to help train users inside our apps where to go for functionality as quickly and efficiently as possible. If a user opens a menu one time and sees "Download Lyrics," he or she should see "Download Lyrics" every time that menu is opened. If the menu item cannot be used at the time the menu is presented, make the system call to disable it, and the OS will gray the item out to provide a visual clue to the user that something else must happen before that particular item is a valid selection.