

Android Design - rtsuk
http://developer.android.com/design/index.html

======
Pewpewarrows
This is a long overdue but very well put-together UI and Usability Guide for
Android Developers. My only qualm from reading it thus far is the very last
section under Navigation [1] regarding System-to-app navigation:

"For the Back key, you should make navigation more predictably [sic] by
inserting into the task's back stack the complete upward navigation path to
the app's topmost screen."

No. This piece of advice is the sole reason why the back button is confusing
to users. Injecting activities artificially onto a user's Back Stack based on
some arbitrary and imaginary path that they might have taken to get there is
horrible. If I'm in the middle of reading a book and get an email
notification, and I touch that notification to quickly read the email, that
Back button better damn well take me BACK to what I was doing. Don't take me
UP to the list of emails in my inbox. This is where the average user will
become lost and not understand why they aren't taken back to reading their
book, and will just end up touching Home out of frustration.

Bad Google!

[1] <http://developer.android.com/design/patterns/navigation.html>

~~~
rryan
This was a huge frustration for me on 2.x. I'm glad they're suggesting that
people insert fake activities to fix it.

Here's an example -- from the homescreen, click a Music widget. The Music app
opens and shows the song I was listening to. I want to go back to the playlist
I was playing from so I hit back. Instead, I'm dumped back to my home screen.
you have to hit the Google Music icon in the top-left to go back within the
Music app. I don't mind having to hit back a couple of times because I've
learned that you can just keep hitting back and you'll eventually get where
you were.

~~~
romey
I disagree. I think the confusion is caused by users not intuitively
understanding the context of the android "back". In a web browser, if you
click a link to a sub-page on a different domain, you don't expect the back
button to take you to the home page of that domain, you expect to go to the
previous site you were browsing. Do any android devices have something akin to
the right click on the back button in web browsers, that shows the back stack?

~~~
nl
This consistently confuses me too (and I much prefer it when application
insert artificial pages).

I've thought about it some, and I think the problem is that the back button
lacks the concept of _context_.

In the music app example, when I first use it I get the front screen, then
choose a song.

Then I press the home button, put my phone away and at some point the song
stops.

Now, some hours later I open up the music player from the home screen and it
is still showing the song, what behaviour should the back button have?

I think it should take me back to the song list (because I am now in the
"Music" context in my head - and this is what it now does). But one could
argue that the back button should take me back to the home screen.

~~~
duckworth
The biggest problem for me is the uncertainty and inconsistency. Do you always
remember the previous screen you were on in any app hours ago? What if you got
to the song from some other screen? I would constantly have to "guess", what
is this app going to do, take me back to where I previously was or to a higher
level in the app. It needs to be consistant, back is back and navigating
within the app needs to be obvious and on the UI itself.

~~~
nl
The back button in browsers is often used as analogy, but how many
tabs/windows do you have open in your browser? What if pressing the back
button in the browser switched you to a word processor because that is what
you were looking at before.

~~~
babebridou
That's what alt+tab and ctrl+tab are for. The confusion comes from the use of
only one back button instead of one per hierarchy.

On android we have only one system-wide consistent timeline to work with, and
that's the timeline of fired intents. It works across the whole system. Back
works on that level by default and is defined by default as "go back in time".

------
jc4p
As an Android developer for many years I was excited when I read the blog post
about the site. When I went to the site, I was very disappointed. I've spent
the better part of 10 minutes on the site so far and haven't seen anything
other than marketing text and screenshots of what my phone looks like.

How do I make these "beautiful designs" work across all Android phones? How do
I use an Actionbar on a non 3.0+ device without external libraries? How can I
supply a consistent look and behavior for my application when some android OEM
keyboards don't even offer the same modules as other ones?

How am I supposed to follow these guidelines when every Google application has
a different implementation of the Actionbar itself?

~~~
Pewpewarrows
The link at the bottom to the core developer site shows you how to implement
most, if not all, of what they discuss here. Though it would be nice if they
had links interspersed throughout the design text to their tutorials and API
guides about the UI features.

<http://developer.android.com/index.html>

~~~
jc4p
That's definitely true, I don't know why they didn't put a "click here for
more technical info!" next to each point.

The things that really bother me are:

1\. If I implement one of the new themes they're discussing on the linked
page, it only works in 3.9% of Android phones on the market, so if I want my
apps to look like Google's on older phones I'm left to implement my own
version of the themes. This is the same thing that happened when they
announced "Homepages with square buttons for activities are the new way you
should do everything!" and didn't release source code for how to do it for
years afterwards with the Google I/O app, so every app that tried it did it a
different way.

2\. How am I supposed to use the action bar if Google's own applications can't
decide on how to use it? Look at the "What's up with the bar" section of this
blogpost: [http://minming.posterous.com/google-currents-yet-another-
con...](http://minming.posterous.com/google-currents-yet-another-contribution-
to-t)

~~~
cuu508
As for 1st point, check out section "Pure Android". It says you shouldn't copy
UI style from other platforms. I think this could be extended to major
versions of single platform too. App with Holo theme on Froyo phone would look
very out of the place, I think.

------
adpowers
Ha! I love that they are using Hipster Ipsum:

[http://developer.android.com/design/static/content/ui_overvi...](http://developer.android.com/design/static/content/ui_overview_app_ui.png)

<http://hipsteripsum.me/>

------
kevinh
The website felt odd to me. It's clearly aimed at developers, given the
subject material, but it felt like it was written as an ad for prospective
buyers.

It listed a bunch of features and user interface methods that apps _should
have_ , but I couldn't find any resource for actually implementing what they
suggested, apart from the link to the android developer page at the end.

~~~
wattjustin
I completely agree. The wording is so basic and kind of insulting as seen here
for instance, "Text fields allow the user to type text into your app. They can
be either single line or multi-line." Very elementary for either a developer
or a designer to read.

~~~
feralchimp
If the goal is to bring devs in from other platforms, who might have all kinds
of crazy notions about what Android dev entails, erring on the side of over-
simplification will give more people the sense that "hey yeah, not so hard."

------
evanw
Regarding the Design Principles page:
[http://developer.android.com/design/get-
started/principles.h...](http://developer.android.com/design/get-
started/principles.html)

I love that they included the ICS home screen's "glass desktop" effect in the
"Delight me in surprising ways" section
([http://developer.android.com/design/static/content/principle...](http://developer.android.com/design/static/content/principles_delight.png)).
It's a completely unimportant feature, but the first time I swiped past the
edge of my rightmost homescreen and saw the effect, I appreciated the
attention to detail.

Where I disagree is with their "Pictures are faster than words" suggestion. I
completely agree that many things are best said with images, but I've had a
hard time identifying the function of several features in the icon-driven UI's
featured in both ICS and in new Google web redesign. In ICS's Gmail app, I'd
understand the words "Mark Unread" much quicker than the "sealed envelope"
icon which I had to experimentally discover.

It's also interesting to note that in ICS Gmail, Mark Unread is an icon and
Report Spam is text, where in web Gmail, Mark Unread is text and Report Spam
is a stop sign.

~~~
radley
Google is heavy on logic but weak on intuition. Why their designs seem to look
good but are hard to follow.

------
swanson
I kind of agree with the sentiment that a few others are having. I've spent
the past 4 months working on an Android project and when I opened this page I
was in shock.

Everything looks so awesome and shiny - but where is the actual
implementation? Is this stuff just a ICS theme (I haven't used it myself as
our app is in 2.2 land)?

Others pointed out to check the "Developer" link - but that is just the
standard Android docs I've been digging through for months already. Searching
for things like "Index Scrolling" (which would be awesome to add to an app) or
"Switches" doesn't return anything useful - so what are the Building Blocks
and how do I get them into my app?

This page should either a) include demos (or links to the demos if they exist
already) or b) be embedded in the code docs (android.widget.GridView should
show the screenshot and UI guidelines).

~~~
myko
I think by Index Scrolling it means to use the SectionIndexer interface:
[http://developer.android.com/reference/android/widget/Sectio...](http://developer.android.com/reference/android/widget/SectionIndexer.html)

It would be amazingly helpful if they would link from the 'Android Design'
page to the docs exactly what they are talking about.

------
wmf
Do they have a schedule for when Google's apps will follow these guidelines?

~~~
deniz
This really appears to be for Android 4.0+. Google's core apps follow these
guidelines but Android 2.3 down seems to be left behind.

I'm not sure as an Android developer I'm ready to leave those users behind
just yet which means a lot of extra work maintaining 2 different sets of UI
code. The action bar is the killer.

------
amirkhella
I think this is the most consistent UI for Android so far. It still feels a
bit more like a "style guide" rather than "human interface guidelines", but
it's a great step forward.

Kudos

------
georgechen
Am I missing something? I'd like to get my hands on the templates, mocks,
wirefames, etc. Let me play with those (as a designer) and I'll be able to
better follow the specs and guidelines.

Note: Microsoft (for once) actually one-up Big G. here. They provide the PSD
and fonts for Windows Phone 7 on MSDN + the UX Guidelines.

Also, for Apple, 3rd party made all the PSD and templates for them...

~~~
mdwrigh2
There's some third party work done for Android as well:
<http://designmodo.com/android-kits-developers/>

~~~
georgechen
Thanks. Nice. But since Big. G. is heavily pushing ICS, they should really put
the ICS files up there.

------
vlokshin
Simply put, and coming from an Apple fan-boy, this is REALLY nicely done. I
honestly think this will significantly improve the usability of the platform
as a whole by attracting the right designer/developer talent.

------
aw3c2
I know it is silly and offtopic but that gorgeous website's navigation does
not work without Javascript for no good reason.

------
alexchamberlain
I like the density-independent pixel concept...

------
kizza
Interesting how they make sure to say that you shouldn't use bottom tabs like
in iOS. For my project I decided to do exactly that instead of using an
Android standard action bar, because:

1:The bottom bar fits 5 items. An action bar needs to have the app name as
well, which means it can't have 5 items anymore. Having a "More" option is
just dumb.

2:The iOS bottom bar has text underneath its icons and the action bar doesn't.
I'm afraid the icons I have aren't obvious enough without text.

3:This is a conversion from iOS so the images are already made

4:Getting an Android action bar to work on older versions is very difficult.
The Android compatibility library doesn't help here, and the third party
libraries I looked at were not mature enough. I'm doing this work as part of a
fixed price contract so I can't waste days getting it to work reliably.

Bottom line: Android apps would look a lot better if doing things the right
way was also the easiest way.

~~~
thetrendycyborg
you can break out tabs into a separate action bar or use scrollable tabs.
You're using elements from another platform your users don't use. You're just
going to confuse or annoy them.

~~~
kizza
For sure, but like I said, I don't have days to spend making half-baked action
bar code work.

------
krosaen
I like this bit on using multipane layouts to be flexible on both tablets and
mobile:

[http://developer.android.com/design/patterns/multi-pane-
layo...](http://developer.android.com/design/patterns/multi-pane-layouts.html)

Good advice for rich web apps too.

------
nodata
I wish they'd make this searchable. This is from Google after all.

Does a button marked "on" indicate it is already on, or that pushing the
button will make it "on"? I'd like to see that standardised.

------
emehrkay
I like the date picker

[http://developer.android.com/design/building-
blocks/pickers....](http://developer.android.com/design/building-
blocks/pickers.html)

~~~
Samuel_Michon
Looks a lot less intuitive than the UIDatePicker in iOS, which is styled like
a slot machine [1].

Does anyone know whether you can manipulate the controls by dragging, or do
you really have to use those little up and down buttons?

[1] [http://blog.blackwhale.at/wp-
content/uploads/2011/05/UIDateP...](http://blog.blackwhale.at/wp-
content/uploads/2011/05/UIDatePicker-Template.png)

~~~
jc4p
You can drag them.

See my other comment here: <http://news.ycombinator.com/item?id=3458159>

------
njs12345
This is great! If apps start following this it should significantly improve
the Android user experience, as well as making it much easier to design good
Android apps.

------
problemspace
I tried browsing this on my old Android phone... I couldn't get past the first
page. I hope "people should be able to read your content" is one of the
guidelines...

------
fdb
I find the "app structure" schematic
([http://developer.android.com/design/patterns/app-
structure.h...](http://developer.android.com/design/patterns/app-
structure.html)) a very useful visualization to see the screens of an app in
one glance.

Any ideas how they made this schematic?

------
JacobIrwin
For Android/Google on web, it's possibly the most apple.com-like designed page
I've seen yet.

------
pax
Why did choose to put 2 phones on the homepage? Because one phone has 3, the
other 4 buttons? Isn't that still a bit redundant. (If it where not for a
design-centric page it wouldn't have troubled me)

~~~
there
because part of that site talks about compatibility with different devices.

the phone on the left is a nexus s, which has the (now) older style of
dedicated hardware buttons. the nexus prime on the right is apparently what
newer devices are supposed to have, which are software buttons that are
actually just part of the main lcd and the operating system reserves a section
of the screen to draw them in software.

the big benefits of the newer style are that they can be hidden while playing
movies or in other situations where they are not needed, they can be rotated
when the device is rotated, and, maybe most importantly, the operating system
now gets to control which buttons are there and in what order they're in. an
annoying thing about the hundreds of different android phones prior to this
was that every manufacturer seemed to put the 3 or 4 hardware buttons in a
random order that made them inconsistent.

------
ge0rg
Utterly worthless. This looks like a web designer on crack had too much time
to promote the beauty of the new Android.

However, from a developer's point of view this is almost unusable. By not
providing the according XML/Java code, we are forced to reimplement everything
from scratch, making smaller and larger errors, introducing inconsistency and
making the look and feel not quite the same between apps.

Then again, it fits well with the current way Google is doing UX design
([http://minming.posterous.com/google-currents-yet-another-
con...](http://minming.posterous.com/google-currents-yet-another-contribution-
to-t)).

~~~
drivebyacct2
All of the UI elements are available in source provided by Google. Koush (on
Twitter) tweeted with Tim Bray about them being split out into a more-easily-
consumed library.

~~~
ge0rg
Yes, they are hiding somewhere in the multi-gigabyte Android source code. At
least the basic default elements. And their style formatting.

And then there are the closed-source Google apps which at least slightly
resemble the UX guidelines given on that site.

And then there are the more complicated UI elements which provoked the
creation of fork projects to allow for the reusability and compatibility not
provided by the Google devs, like <http://actionbarsherlock.com/> and
<http://viewpagerindicator.com/>

------
feralchimp
I'm going to assume the internet has already somehow collectively dealt with
the fact that the Android name for a drop-down list control is a "Spinner."

~~~
thetrendycyborg
it doesn't always drop down. Sometimes it "drops" up, like if the element is
at the bottom of the phone. You can "spin" through options. Makes sense.

------
funkyboy
Finally!. Isn't too late? Are OEM and carriers going to follow the same
principles? Or they can build whatever skin/mess they want as they did so far?

------
funkyboy
Google, good work on the Android design guidelines, but is that enough to tame
the wild west in the marketplace and the current "anarchy"?

------
helpbygrace
Does anyone know how to see Roboto font as anti-aliased in Windows7? In my
windows 7, Roboto font looks really jagged and weird.

~~~
AliCollins
Likewise on my XP Laptop in Chrome...and I have Roboto TrueType font
installed. Then un-installed the font, and it looks far better!!

------
buro9
All we need now is an accessibility document for Android.

Accessibility is notably absent from the design doc.

------
astrodust
"Android Design"

    
    
        .../index.html
    

It's the little things that matter. This is shameful for a company so big.

~~~
ranebo
I'm confused, why does this matter?

~~~
astrodust
From a technical perspective, littering your URLs with implementation debris
is not a good idea. What if you want to revamp the site, put it in a shiny
CMS, and now it's in PHP or JSP or does it even matter? You have all these
references to `index.html` you have to maintain or you'll be wrecking your
linkage.

Bury those. If you're doing a plain HTML site, use MultiViews to hide the
extensions. They're not important to the content.

When I see `index.html` in a URL, it's never a good sign. It's done by a
sloppy "web designer" that knows how to use DreamWeaver and FTP things to the
server. They make a tremendous mess for the next team that has to come along
and somehow upgrade the site without breaking everything.

It's not 1998 any more. You can afford to script your pages, have clean URLs,
and still get great performance.

------
saket123
This site is really useless. As an android developer I was hoping for more
steps rather then another marketing docs. Its funny how little android
provides out of the box and I have to just keep searching source to find how
things are implemented and best way to implementing such designs. Sad state of
affairs as I have to waste most of my time trying to understand these designs
and corresponding code designs in source.

Another thing I hated about the website is how sparse it is in technical
details. If Google really hopes us to make use to these pattern why not
release some of these as widgets or templates.

------
fufulabs
Isn't ICS like just around 0.5%(or was it 5%) of Android handsets as of
December 2011? This design guide is ALL about ICS and nothing about the 99% of
the Android handsets used by people.

~~~
thetrendycyborg
in 2 years everyone will have ics or better. carrier contracts.

~~~
nailer
That's kinda sad, compared to Apple, Microsoft, and RIM. ICS fixes bugs too.
People shouldn't have to deal with them until they buy a new phone.

------
rwc
I know some will criticize this is ticky-tacky, but it's one small thing that,
when added with a lot of other little details, make Android feel like it's
still designed by engineers.

They've "touched nearly every pixel" and "App icons are works of art in their
own right" but the contact name on their contacts icon is "Lorem Ipsum". Not
exactly a warm, human feel.

[http://developer.android.com/design/static/content/design_el...](http://developer.android.com/design/static/content/design_elements_landing.png)

~~~
alex_c
"Lorem Ipsum" is more of a designer thing.

