I posted earlier about Google’s new Android Design Guidelines. This is a great guide to help developers understand the platform and all its own peculiarities, especially when an app is developed for multiple platforms. I disagree with a number of these conventions, but that’s another topic entirely. The guide itself is well-written, though I have some thoughts and comments for some of the points.
The Themes page:
Android provides three system themes that you can choose from when building apps for Ice Cream Sandwich:
- Holo Light
- Holo Dark
- Holo Light with dark action bars
Pick the system theme that best matches the needs and design aesthetics for your app.
Like Apple’s infamous brushed metal look, the Holo Light with dark action bars theme is an ill-defined third choice. There seem to be no guidelines on its use. The Light and Dark themes are easy enough to interpret, as the former is for text-based apps — the Gmail app is shown as an example. The Dark theme is clearly geared towards multimedia and utility applications. Google uses Settings as their example, but Photos also uses this theme. They’ve chosen Google Talk, however, to represent the dark action bars variant of Holo Light, and I don’t understand the context of its use.
From the Metrics and Grids section:
Touchable UI components are generally laid out along 48 [display pixel] units.
This is much clearer than iOS’ layout.
The section on icon design is decidedly less clear, especially in the Launcher icon style. There’s an ill-considered mix of photorealistic icons, ones that look like clipart, and others that are effectively flat. Nothing lines up. The colours are inconsistent. This makes any view with those icons look cluttered and messy.
The App Structure page reinforces this system-wide inconsistency:
Google Books’ detail view is all about replicating the experience of reading an actual book. The page-flip animation reinforces that notion.
This counters what Matias Duarte said when interviewed by Josh Topolsky:
“Right now if you look at all of these applications that are designed in this real-objecty, faux wood paneling, faux brushed metal, faux jelly button kind of thing… if you step back and you really look at them, they look kind of juvenile. They’re not photorealistic, they’re illustrations.”
He’s on a roll now. Clearly Matias has spent a lot of time thinking about what he doesn’t like. “If you look back at the web, people did the same thing. All these cartoony things hanging off a page. If you tried that today, people would be laughing, unless you were doing it in a kitsch, poking-fun-at-yourself, retro art way.”
He then goes on to say that taking the Microsoft approach of stark minimalism is too constraining, but in the opposite direction. The threshold for Android is clearly somewhere along those lines, but what Google is recommending is clearly more cartoonish than the actual UI that Apple ships, and which Duarte called “cartoony”.
From the Writing Style page:
Be friendly. [This d]ialog that appears when an application crashes [is] confusing and annoying — “Sorry” just rubs salt in the wound.
I don’t know when it became trendy to make error messages cuddly, but it’s irritating. Good on Google for clarifying this. On the other hand, I’m surprised Android apps display any crash dialogue at all. It isn’t 1998 any more; applications have the ability automatically send crash reports.
Speaking of crash messages, Google seems to be unclear on what they intend. On the Writing Style page, they would like developers to be clear, concise and friendly. However, on the Dialogs page, one of the examples notes that “the process com.android.phone has stopped”. How is that friendly?
The Pure Android page cracked me up. It’s clearly an attempt to caution developers that Android is not iOS, and designing for it requires different elements with different conventions. For the most part, it avoids ragging on iOS, but there’s a cute dig on one of the items:
A common pattern on other platforms is the display of right-pointing carets on line items that allow the user to drill deeper into additional content.
Android does not use such indicators on drill-down line items. Avoid them to stay consistent with the platform and in order to not have the user guess as to what the meaning of those carets may be.
But barely-readable sliders and unclear WiFi connection status are not confusing. Got it. Unclear, convoluted difference between back and up? Not a problem. An up arrow that causes a descending action? Perfectly fine.
By the way, what about the reverse, where an application is developed for Android and then ported to iOS? Shouldn’t a Google-developed app adopt the conventions of the platform too? As Alan Zeino points out, this doesn’t seem to be a priority.
I recommend flipping through the entire guide, if only for the use of Hipster Ipsum on many of the pages. It’s too bad these guidelines won’t be enforced. It’s an incredibly well-written and clearly annotated site, but it bears little relevance if these principles don’t gain widespread adoption.