
How To Design For Android Devices - nvk
http://blog.mengto.com/how-to-design-for-android-devices/
======
veeti
> All the resolutions on Android are pretty confusing, i.e. we have xhdpi
> (2x), hdpi (1.5x) and mdpi (1x). They sound extremely technical. When I
> first started almost a year ago, the engineers couldn’t even explain to me
> what the ratio were for each of those. I had to figure it out by asking a
> lot of questions. The resolutions you should design in are 720×1280, 540×960
> and 360×640. Make sure to include hardware buttons and the status bar on
> your design for high-fidelity mockups.

Uh, no. There is no standard resolution on Android. You shouldn't make any
assumptions about it. Build layouts that scale themselves and adapt based on
the screen width & height in density-independent pixels.

> Fonts are unfortunately device-specific so better expect crappiness on some
> devices.

Fortunately, starting with 4.0 you can force the stock Holo theme in your app.
Unfortunately, the manufacturer apps are stuck somewhere in the 2.x era and
have completely alien user interfaces in comparison.

> In 2x, the minimum pixel dimension should be 28px for text, 96px for menus &
> header and 116px for the footer.

It's a bad idea to talk pixels in Android at all. Instead, use density-
independent pixels (and the sp unit for font sizes which also scales with the
global font size) which are calculated based on the screen resolution and
size/density. As two examples, the minimum size for a touch button should be
48x48dp to ensure it's big enough to touch, and a 7 inch tablet is at least
600dp wide.

~~~
radley
Sorry for the downvote, but a lot of design advice coming from Google is like
jedi hand waving. Of course there are standard resolutions and screen sizes,
especially when you use dp instead if dip.

~~~
veeti
> Of course there are standard resolutions

No, there are not. A 720p screen might be a de facto standard on many devices
right now, but if you are designing your app for a couple of resolutions and
not resolution independence, you are in for a world of hurt.

For example, the Nexus 10 has a 2560x1600 resolution. Flagship phones this
year are expected to go 1080p (the same way they went to 720p from 800x480
which was the most common resolution in 2010).

There is no standard resolution. Don't count on it. End of story.

> especially when you use dp instead if dip

dp and dip are the same thing.

~~~
radley
Thnx. I use "dip" as special notation in my layouts and forgot they were
actually dp.

I will concede one big difference: a lot of designers work in Photoshop so
they're dependent on pixel resolution. I do everything in Illustrator, so I
rarely think pixels.

If I think about resolution in old terms of strictly pixels then yeah, I'd be
lost. But since I do everything in vector format, I still do my basic phone
layouts at 320x480 and then scale from there.

------
radley
There's a lot of shortcuts in this article. I appreciate him taking the time
to put it together but a lot of important Android design practices were
overlooked or misquoted.

There's 6 resolutions: ldpi, mdpi, tvdpi, hdpi, xhdpi, & xxhdpi. Of these,
ldpi is often skipped, and tvdpi is optional (the Nexus 7 and Google TV use
it). The new one, xxhdpi is important for new 1080p phones like the Droid DNA
and upcoming Galaxy S4.

Resolutions are multiples. It's easiest to remember them as 48, 64, 72, 96,
144 (these are the sizes of your app icon). xhdpi is 2x mdpi. hdpi is 1.5x
mdpi. tvdpi is 2/3 of xhdpi. xxhdpi is 3x mdpi & 1.5x xhdpi.

It's not pixels, it's usually dp (density-independent pixels) which are based
on mdpi. As such, it's a good idea to design layouts at mdpi scale - it just
makes it easier to match your dp values. I lay out for 320x480 and 1280x720.

I wrote a detailed blog post on 9-scale (<http://radleymarx.com>).

For most Nexus devices, the Action Bar is the only access to the Overflow Menu
(aka the old Options Menu). So although it's only "recommend" to use it,
there's no way to use the menu without it.

Fonts can be specified in the layout XML. You just need a custom TextView
class. Note: widgets won't let you use custom class layouts. Fonts are added
in the assets folder of the project. Some devices are picky about how you name
fonts so it's best to name them as lowercase-name.TTF (uppercase file type).

Most often you'll want to match font sizes that other apps use. The minimum
font size you can clearly get away with is 10sp on phones & 11sp on tablets.
Users can change text scaling in their device so you should use sp instead of
dp for text. If you don't want it to scale (i.e. a decorative layout) you can
use dp instead.

The best way to design for devices is to buy one of each screen type. Some
groups start a pool of devices to share for testing. For widgets I design for
GS3 & GNexus simultaneously, along with a Nexus 7. When the layouts are
complete, I start checking on other devices.

~~~
justjohn
One other thing I would add is to check on different variations of Android
(stock, HTC's Sense, Samsung's TouchWiz, etc..) as well as resolutions, since
they have different default widget styles and colors that can affect your app
in different ways. (Android 4 is much better about this with Holo, but
anything before it can vary a lot.)

~~~
radley
If you stick with native styles for device elements (such as the action bar &
notifications) that should cover 99% of requirements.

Widgets are a different matter. Suffice to say the big difference there is
between Samsung/HTC who displays full-sized widgets and Nexus/Motorola/Asus
who force widgets to use way too much padding.

------
georgemcbay
Speaking as a programmer that has worked on adapting Android designs from
mockups to reality this is probably a very useful article for would-be Android
designers.

The "up button" description is a bit oversimplified but probably sufficient
for an intro to design post.

Also fonts aren't exactly "device specific" as stated in the post. You _can_
embed your own TTF or OTF fonts into your app as a resource and use them.
There are some annoyances to doing this (particularly when viewed from a
designer's standpoint, so I'll let the article slide on this one) like the XML
layouts won't recognize these fonts but you can programmatically assign the
embedded fonts to Android's various text controls very easily.

Of course the hardest part as always when dealing with fonts is the licensing
which is slowly getting better but remains years behind the licensing of other
digital media formats.

Also on the issue of fonts, he mentions that Droid Sans is popular (since it
was previously the default system font) but he should probably have mentioned
Roboto, which is the newer and IMO much nicer default font, which is also
freely downloadable, the entire set of Android fonts are available for use
under the Apache license and can be used freely even in non-Android contexts.

~~~
mengto
Thanks for mentioning Roboto, I agree that it's a much nicer font. It's also
good to know that it isn't too hard to embed custom fonts. I was definitely
looking for that answer.

Also, can you elaborate on the "up button"?

~~~
georgemcbay
My basic issue with the up button is the way you describe it conflates it with
the back button, while the two should be considered different things (even
though in many cases they will do the same thing). I blame Google more than
anyone for this as they themselves conflate the issue mightily by, for
example, styling the "up button" so it looks exactly like a back button.

~~~
mengto
How would you detail the differences between the 2 buttons?

~~~
LCoder
Lets assume for a moment you are using the browser on your phone when a
notification pops up alerting you to a new email. Clicking on the notification
brings up your mail app and displays the email you just recieved.

At this point if you click the back button you will be returned to the browser
session you were previously viewing. If, however, you were to click the up
button instead you would remain inside your mail app and go “up” from your
message to the inbox.

------
lnanek2
He misses a lot of the intricacies of the Android design site (
<http://developer.android.com/design/index.html> ). You are actually
recommended to make your content touchable rather than putting every action in
the top right as an icon. If I made a weather app, for example, I may have
little day or hour graphics that can be tapped for more about that item. Even
for the action bar there is a split mode that puts actions on the bottom as
well.

Similarly, he has the density classes wrong. There's XXHDPI, XHDPI, MDPI, and
LDPI and they don't correspond to set resolutions. It's recommended by the
Android Developer blog to actually change layouts based on a certain DP width
(DP being a density independent pixel that normalizes measurements across
density classes) rather than do x sizes of the same screen for each density.
E.g. so screens with a lot of pixel real estate across get an extra list on
the left, things like that.

~~~
radley
You left out HDPI and TVDPI. While they don't correspond to specific pixel
sizes, it's easiest to think of dp as px that scale for you based on a 320x480
screen.

------
ichinaski
I wish the designer in my company could be interested in these kind of
articles. Is quite frustrating to receive time and again all the wireframes
focused on an iPhone-like look, no matter what.

~~~
mengto
I was one of those designers. I'll try to get more designers to change their
approach. :)

------
napoleoncomplex
The resolutions seem off. The most common xhdpi resolution is correct
(720x1280), however the hdpi one is 480x800 and mdpi is 320x480. Might be my
mistake though, is there a clearer explanation why you chose those
resolutions? Edit: This is in the case of phone sizes (tablets are another
story). And even in the case of phones, you have varying resolutions inside
those buckets. Yeah, explaining this to iPhone designers is always fun :).

Custom fonts are a problem, but there's a nice way to implement them
(backwards compatible and all), and when you do it once, it will always be
very easy. I don't have a code example nearby, shoot me an e-mail (in the
profile) if you are interested, and I'll make sure to get a proper answer to
you.

------
MatthewPhillips
Awesome article! Twitter apps, please take note of this:

> Finally, if you respect their guidelines, all actions should be on the far
> top right. That includes functions like Refresh (because Pull to Refresh is
> extremely uncommon on Android)

Pull to Refresh feels _really_ out of place in an Android app, don't use it!
Most apps do not, but Twitter apps seem to be the exception, for obvious
reasons.

~~~
micampe
I don’t understand this complaint. Pull to refresh didn’t exist on iOS either.
Twitter introduced it, people liked it, it spread to other apps and it
eventually became API. This is how evolution happens, why would you want to
prevent it?

------
readme
Thank you for disseminating this information. It would be a great world if
more designers really understood Android. The one's I've worked with haven't
given much of a care about it, and just stiffed me with wrong size images, and
I ended up having to sample them and make my own 9-patches.

I wish Adobe would make a 9-patch tool that works with their stuff. draw9patch
isn't that good.

------
sabret00the
Very negative leaning.

~~~
lalamin
Why do you say that?

Fonts are a true point of pain in Android dev.

~~~
mcritz
Typography is pretty awful on Android in general. Both Roboto and Droid Sans
are nightmare Frankenfonts.

Font rendering on Android is bulky, blocky, and fails to consider how humans
read letterforms. So, even if a designer can convince the team to license a
better font, it’ll end up a smeared mess on users’ screens.

The API calls to layout type on Android suck. (iOS sucks slightly less
depending on how willing your UI engineer is willing to devote to this most
basic foundation of design.)

“U MAD, BRO?”

Yeah. I get paid to be a picky snob about what the user sees and how they feel
about the product. It pisses me off to look at Android because its not
disappointing, the way Win8 is, but actively anti-design. Why pay to license
good fonts? Why make a system for rendering type nicely? Because this stuff is
basic user experience. It's like going into a hotel and discovering that the
paint is yellowing. That hotel is more likely to have dirty towels, no hot
water, smelly sheets, and bed bugs.

~~~
king_jester
> Typography is pretty awful on Android in general. Both Roboto and Droid Sans
> are nightmare Frankenfonts.

I like Roboto, but what do you find to be bad about those fonts?

> Font rendering on Android is bulky, blocky, and fails to consider how humans
> read letterforms. So, even if a designer can convince the team to license a
> better font, it’ll end up a smeared mess on users’ screens.

This isn't really true when setting custom typefaces on various views. Just
subclass them and set up the typeface in the constructor and you are done. You
just end up using that subclass your in layouts instead of a standard
TextView.

> It pisses me off to look at Android because its not disappointing, the way
> Win8 is, but actively anti-design.

I'm not really sure what you mean w.r.t to text. The text views and code cover
most use cases and offer ways to handle flowing text in some cases, but you
can always fall back to WebView rendering text content (which is easier for
writers or editors to handle when making the text content).

