While Google’s Android Developer Guidelines do help developers create better apps, there are a number of places where usability and common sense should win out over standards. Of course, before you set about breaking the rules, you’ll need to learn them, so by all means: Don’t proceed until you’ve familiarized yourself with Google’s standards. They are important and useful. Now here are four scenarios where you can totally disregard them.
If your app looks like lots of other generic apps, then putting your logo on the far left of the main Action bar (as per the Google standard) will give users much-needed context. However, most major Android apps do not do this. Why? They have a visual brand that’s strong enough–and a user interface that’s unique enough–to already provide the visual clues users need to know to make the connection.
Removing the logo has huge advantages on a screen as small as a smartphone’s–that screen real estate is better used providing contextual information or navigation controls for users. Below, Google follows their own guidelines and puts the Gmail logo on the top left, but Facebook uses the action bar to provide context and navigation.
In their guidelines, Google shows a Gmail example for use of icons in the action bar. But their example is inadequate because it shows unlabeled controls–which are really only the privilege of highly recognizable apps. For lesser-known app developers (which is to say, literally everyone but the Gmail maker) putting unlabeled controls in your app just confuses users. People don’t know what your little “filing cabinet” icon is supposed to do in the context of your app. A simple word under each of these buttons greatly improves usability and especially the first-time user experience.
Icon ambiguity, even in a technology as familiar as a mail program (which tends to use very standard icons), reminds us that creating good icons can be hard. Don’t beat yourself up trying to come up with icons for complex or specialized actions which don’t already have a well-known icon. Instead, either put text under your icon, or just use a text button. Icons are great tools for usability when they’re exactly that–iconic–but otherwise, they’re just confusing.
The drawer is a handy navigation solution for apps that have many categories or top-level actions. I would caution developers not to use this as an excuse for having too much in the navigation. Great apps are focused. In fact, some of the most powerful and useful apps in the app store get by with just two to five navigation items and no slide-out drawer. Before you run off and implement it, honestly ask yourself if you can get away without it.
Just because something is available in the OS doesn’t make it a good idea to use it. Case in point: Don’t rely on long touches, the hardware menu button, or nested menus. Instead, always have some sort of link on screen for users to get to the data they want. Also, stay away from using multi-pane layouts since they are often unattractive, visually confusing, and clunky to use.
An app with more panes than can fit on screen creates what’s known in the biz as “mystery meat navigation.” This sort of layout lacks the visual clues needed by users to know they must perform an action to see more information. If you have more categories or tabs than you can fit on the screen, consider getting rid of some or using a slide-out drawer instead. Here’s an example of what not to do:
Text buttons should be visually separated from other icons with a line. While this is a subtle touch, it is effective from a UI point of view. Tumblr (top) has a short vertical line separating their text from the rest of their action bar which is visually clearer and more grounded than the Yahoo Mail App (at bottom).
In many applications, pull to refresh is just a better (and more elegant) way to refresh than a refresh button, and users just get it. You should consider using it instead of, or in addition to, a refresh button–but only if you don’t need the real estate above your table cells for something else. In some apps, this may be the most logical place for a search field, filter options, or metadata. Obviously, some apps require more frequent refreshes than others–if the app doesn’t need to pull in data at least once per session, then consider using the space for something more heavily used.
If you’re developing an app for an Android device without a hardware back button (such as a Kindle) you absolutely need to have a back button on screen or your app could become unusable. In fact, unless your audience is comprised of only highly technical users, consider having this button on screen at all times. Many less experienced users are confused by Android’s default “back” behavior. So, the more options you give them to go back the better.
It should also become a best practice to make your on-screen “back” button take your users back only one screen, instead of all the way back to your main menu as the Google guidelines suggest. Why dump people out of your app when they’re just trying to complete a different task in your app?
When I speak at a conference, or am consulting with a client, I’m often asked, “Should app icons have rounded corners or square corners for Android?” My answer? Let it go. It doesn’t matter. Maybe in a year or two then we’ll see a clear winner start to dictate Android app design conventions for the rest of us, but right now, 95% of your users really don’t expect one over the other. Make the rest of these choices yourself–but on this one, I suggest using it as an opportunity to defer to the HIPPO (Highest Paid Person’s Opinion).
Screenshot images from Google’s design guidelines.
[Image: Flickr user Eric]