> 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.
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.
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.
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.
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.
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.
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.)
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.
That stuff doesn't matter so much these days. With old 72dpi bad pixels were really obvious. But at 280+ it's really hard to see them. I'd rather spend my time fixing Android XML layout weaknesses...
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.
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.
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.
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.
Just to tack on my simple opinion:
'Up' is in context to the current application.
'Back' is in context the users perspective.
If I'm in the browser and click a mailto link, it opens the email client. The 'up' metaphor should return me to the inbox. The 'back' metaphor would return me to the web browser/webpage. (Did not realize I was using the exact same metaphor as my sibling, sorry)
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.
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.
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.
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.
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.
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?
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.
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.
> 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).
Isn't it only a problem for fonts without subpixel hinting? I've used a fair amount of custom fonts, most render perfectly fine, and looking at well-designed apps I never felt like it's an issue.
I didn't even understand what he meant by device specific, personally. Every app I've ever seen that uses a custom font just includes it in the app and it works on every device. I suppose I've seen OTF fonts not work on very old Android versions, like 1.6 and lower or something, but I've never seen a TTF not work.
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.