This article was originally published on Emir Hasanbegovic‘s blog.

I have seen many design mockups for Android applications that were beautiful but did not translate appropriately to devices. The mock up/design process tends to happen separately or before the development process and reconciling the two can become a time-consuming process. Designs also set expectations and imply user flows that do not always translate to the development paradigms Android enforces. Here are a few concrete steps that will help you minimize some of the churn.

Splitting Design Up Into “Form Factors”

There are 4 form factors that you should be designing for:

• Regular sized phones (phones)
• Over sized phones (5” phones)
• Mid sized tablets (7” tablets)
• Regular sized tablets (10” tablets)

If you are looking to cut down on the number of form factors, simply group 5” and 7” devices into their own group or group them with their closest neighbour. This doesn’t always give ideal results, but it will not ruin the user experience. We’ll get into how to best target these form factors later.

Naming Conventions

Before we can start talking about more advanced topics, it is important to know how Android wants you to organise your assets. Every device type you target has a specifically named assets folder. You’ll see more details below, but here are a couple examples:

• drawable-hdpi/
• drawable-xhdpi/

When you are making an asset, make sure you put an appropriately sized copy in each folder, we’ll discuss determining the correct sizes later. For example, if you made an icon at 72×72 pixels and one at 96×96 pixels, put the 72×72 icon in the hdpi folder and the 96×96 icon in the xhdpi folder. These two assets must have the same name or Android will not be able to choose the appropriate asset at runtime.

Example:

• drawable-hdpi/icon.png (72×72)
• drawable-xhdpi/icon.png (96×96)

There are two rules you should follow: drawable folders should only ever contain files (no sub-folders), and file names inside drawable folders should be made up of only lowercase letters, numbers, underscores and nothing else.

Good Example:

my_icon_12.png

Bad Example:

My-Icon 12.png

For your own sanity, stick to a naming convention, I recommend naming every asset as follows:

<screen name>_<asset type>_<name>.png

i.e.

loginscreen_actionbaricon_search.png

Screen sizes

Designing For Form Factors

With the large fragmentation of screen sizes across Android devices, it practically becomes impossible to design with all screens in mind. Google gives you a lot of information about different screen resolutions and pixel densities that you should understand. On the other hand, I find that keeping all of these details in mind when designing is difficult. So here are the tricks:

Pick the form factors you want to support. As a rule of thumb, always start with phones as they cover the majority of the market and their designs can easily be ported to bigger devices. Pick any of the phones on this page and use its resolution. Design for that particular phone and resolution. Then repeat the process with the other form factors. Make sure you note the differences in height and width when including the status bar, nav bar and title bar.

Navigation (Nav) bars

Action/Title Bar

Status Bar

Important notes for those pixel pushers out there:

• The nav bar does not always change position when rotating the device. Sometimes – as is the case for the Galaxy Nexus – it always appears at the side of the display closest to the base of the phone regardless of orientation. This is depicted on the phones index page by stating that the nav bar has a width as opposed to a height.
• Title bars, nav bars and status bars don’t always appear on all devices.
• Title bars, nav bars and status bars can differ in size depending on whether the device is in landscape or portrait orientation.
• Title bars and status bars can be removed so that your application can gain extra space as needed.
• The nav bar can be hidden temporarily on certain devices. As a rule of thumb expect this bar to always be there.

Now that you have a design for each form factor, do not try to be pixel perfect yet. It will not translate well later. At this point all you want to do is create general guidelines for how the application will lay out for each form factor.

DPI “Buckets”

Android has dpi “buckets” for each device based on their resolutions and pixel densities:

nodpi ldpi mdpi tvdpi hdpi xhdpi xxhdpi

The goal of these buckets is to ensure that an asset in the mdpi folder is the same physical size across all devices. This means that if an asset in the mdpi folder appears 3×3 cm large on device A, it will appear (approximately) 3×3 cm large on device B regardless of the device specifications.

The reason behind the different buckets is to ensure that when certain assets shrink or grow to fit into the right physical size, that they do not appear pixelated or lose fidelity, respectively. To ensure that your assets look good on all devices and are the same physical size, you should cut an asset for each dpi bucket using the following ratios:

Here is a good tool to help you out with these calculations.

To recap, this will ensure that the originally designed asset appears the same physical size on all devices and is the right fidelity for each pixel density.

From an engineering point of view, having correctly sized assets for the appropriate dpi bucket will directly improve the performance of the application on devices. This is because each device is optimized in terms of processing power and memory availability with respect to its screen size. So having assets with the appropriate dpi will optimize both the fidelity and responsiveness of the application.

Form Factors And Their DPI “Buckets”

Now that we have designed for each form factor and we know how to cut our assets, notice that we have the same named asset for an xhdpi phone as an xhdpi tablet, but they are of different sizes.

There are several ways to target just the right form factor and dpi bucket. I recommend using the folder names below associated with their respective form factors. There are a lot of folders, do not worry about filling all of them up.
We will discuss which ones you need to fill out in the next section.

Recap Of Designing For “Form Factors” And DPI “Buckets”

Recall we first designed all of our form factors, we then learned how to get the best fidelity for each asset using dpi buckets and now we have folders that tie in form factors to dpi buckets. For best results at runtime in terms of responsiveness and visual fidelity, you want to fill out each of these buckets. Keep in mind that filling all these folders can make your application very large. You should choose one or two folder(s)/DPI buckets for each of the form factors you wish to support and only create assets for those. Then determine if specific assets do not have adequate fidelity on all the devices you are targeting.

Screen Ratios

Devices do not follow any rules when it comes to screen ratio, title bar size, status bar size or nav bar size and location. It is important to know what widths and heights you are dealing with when designing. You should be aware of the largest/smallest physical and pixel widths/heights for each form factor.

Spend time designing layouts that stretch and fit appropriately on both extremes. Do not design a layout that barely fits all the information on one screen as there is guaranteed to be a device that will not be able to handle the size you designed for. A use of appropriately stretching sections and margins is more powerful than using a scrolling section to fit your content.

More on scrolling below.

Fragments

Android introduced the concept of Fragments when it released their first set of tablets. Developers use these all the time to marry design with data. Getting familiar with them and designing for them in your mocks will push your application to the next level.

Fragments are very powerful tools for creating designs across multiple form factors. Fragments are literally “fragments of the screen”, they are boxes that contain data. Imagine a sports app with a screen containing a scores section and a teams section. Draw an imaginary box around each of them, or a literal one, and designate them as Fragments. Now cut and paste them between form factors changing everything from layout to position of the actual fragments on a screen but not changing anything inside the cut out pieces.

Fragments define such a section by holding data and displaying it appropriately. They can be treated as individual pieces of UI. You can and should design for a fragment the same way you would treat an asset or screen for a form factor.

Fragments have the ability to choose their layout in the same way a screen layout does (based on form factor, dpi bucket etc..) but they can do it separately from the rest of the screen. In other words the best way to design a fragment is to detach it from everything else you are doing, lay it out for each form factor and then put it back into the UI as you would any other asset.

A modern Android design for fragments is one that assumes the fragment will be the approximately the same physical size on all devices/form factors.

As an example, if a fragment takes up the whole screen on a phone, when it got to the 5”,7” and 10” devices, it would still be the same physical size, but positioned appropriately. On a 5”/7”, it may be centered with a background appearing past the margins/borders of the fragment. On 10” devices it might appear with a few other fragments that have been appropriately spaced out. A great example of this can be seen in the Google IO 2013 application. A fragment that on phones is full screened, gets its own section on the 7” and 10” form factors yet is approximately the same size.

Scrolling

There are two types of scrolling. Scrolling a variable set of similar items is efficient (smooth scrolling) and a great use of space when it comes to supporting screen with different width or height. Think of the gmail app, it displays emails (similar items) below an action bar, which does not change height. The emails section, by scrolling, ensures that devices with different heights will always make the best use of the vertical space.

Scrolling a static page, the way a web site would, with no variable content is inefficient (choppy scrolling) and not a smart way to use space. This option usually indicates that you have attempted to squeeze too much information on one screen and you should consider splitting the information. Consider using fragments to solve the issue, a flow that would be one page on a tablet, could be two pages on the phone.

If you must scroll to fit your data on one page, be creative about what scrolls and how. Introduce a parallax effect, for example: have two pieces of UI scrolling at different speeds and having one ultimately line up on top of the other. This lets you fit all your information on one screen without looking like a website.

Title Bars And Keyboards Oh My!

Users like having access to their status bar, they also need access to their nav bar, and most enjoy being able to use the title/action bar. That is 3 bars for those who are counting, add the keyboard to that… How much real estate does that leave you with?

This is purely opinion, but from experience, I find that tab bars not only look bad but take up real estate that you can’t spare, especially when in landscape mode or with the keyboard up. For those still keeping count, that becomes 4 bars and a keyboard. So please avoid them.

The left menu panel sliding panel design pattern (like the one used in Facebook) is by far the best navigation aide in terms of UI and UX, so please use it. Similarly, the overflow menu or a drop down (spinner) from the action/title bar is also a very smart way of using the space you are given.

Flat Colors and Assets

Android designs tend to be flat and rectangular. Do not cut assets for things with flat colors, borders or simple gradients. Android is designed to handle these efficiently. They will look better and draw faster if you let Android build the graphics for you. In these cases, define colors, sizes, etc.. and let the development team do the work in XML. Only cut assets that the developer can not draw using code. These can include icons, graphics, etc. Buttons and such can usually be drawn via XML, don’t be afraid to challenge the development team.

Conclusion

Designing for Android can be a difficult task if you do not approach it in the right manner. Following the guidelines above will not solve all of your problems, but will help you get better results faster. More importantly, it will translate directly into Android development paradigms and make conversations, workflows, timelines, and collaboration easier for developers and designers.

About the Author

Biography