Design Considerations for Android Application User Interfaces
It is important to create Android User Interfaces (UIs) knowing that apps will be running on a
variety of different devices. The Android framework provides a number of techniques to
enable developers to optimise UIs for a variety of screen sizes and pixel densities.
This article aims to help designers become familiar with what they need to know to deliver
the right assets to our development team.
Physical Screen Sizes
Physical Screen Sizes
Android breaks down physical screen sizes
measured as the screen’s diagonal length from
left corner to bottom
into four general sizes:
320 × 480 pixels is considered a ‘no
rmal’ screen size by Android. ‘Xlarge’ is in the tablet
screen size range. However, the most popular Android smartphones today have WVGA 800+
pixel HD displays. So, at the time of writing, we can say that most Android
martphones have ’large’ screen.
Design Considerations for Physical Screen Sizes
Due to the diversity of screen sizes, it is challenging for developers to create a one
all layout. For example, on a larger screen, we might want to adjust the position and size of
some elements to
take advantage of the additional screen space, or on a smaller screen, we
might need to adjust sizes so that everything can fit on the screen.
An approach we take is to design a set of layouts for 320 x 522 physical pixels and then to
introduce custom lay
outs for the other screen sizes (small, large, and xlarge if we’re offering
the app to tablet users).
Introduction to Screen Density
Screen density is the quantity of pixels within a physical area of the screen, usually referred
to as dp
i (dots per inch).
Like screen sizes, Android divides screen densities into four basic densities:
xHDPI (extra high).
A ‘low’ density screen has fewer pixels within a given physical area compared to a ‘norma
or ‘high’ density screen.
Android will try to make the most of assets that are available for a given device. Designers
should note that Android prefers to scale
down rather than scale up. For example, when
looking for a low
density resource and it is no
t available, the system prefers to scale
density version of the resource, because it can easily scale a high
down to low
density by a factor of 0.5, with fewer artefacts, compared to scaling a medium
density resource by a fac
tor of 0.75.
Design Considerations for Screen Density
Designers should provide all graphical assets (bitmaps) in sets of different densities. To
ensure your bitmaps look their best, you should include alternative versions at different
resolutions for diffe
rent screen densities. At the very least, designers will need to deliver
mDPI and hDPI sets of assets for any smartphone app.
To create alternative bitmap drawables for different densities, designers should follow the
3:4:6:8 scaling ratio between the four
generalized densities. (This differs from the iPhone,
where, at the time of writing, there’s a 2:1 ratio between the iPhone 4 and 3GS.)
Using our ratios of 3:4:6:8, designers should create four different versions of a bitmap to
hand off to our developer f
75 × 75 for lDPI screens (i.e. ×0.75);
100 × 100 for mDPI screens (our baseline);
150 × 150 for hDPI screens (×1.5);
200 × 200 for xHDPI screens (×2.0).
So, if you have a bitmap drawable that’s 48×48 pixels for medium
n (the size
for a launcher icon), all of the different sizes should be:
36×36 for lDPI
48×48 for mDPI
72×72 for hDPI
96×96 for xHDPI
Note: for mobile apps we’re only concerned with lDPI, mDPI and hDPI.
Interactive UI Elements
Introduction to UI Ele
For UI elements that may be take several different states, such as buttons, Android gives
developers the option to provide several different images to represent the same graphic.
Design Considerations for Interactive UI Elements
We encourage designer
s to create 4 states for all interactive UI elements. This helps to
make sure the effects of an action are clear & visible.
Introduction to NinePatch
NinePatch (or stretchable) images are PNG files that mark the parts of an image that can be
tched. They are similar to CS3 border
image in web design.
A NinePatch is a variation of a PNG image that uses a one
pixel border to define the area of
the image that can be stretched if the image is enlarged. The Android system uses
NinePatches for some o
f its native drawables, e.g. button borders.
An example of hot a horizontally scaleable button can be presented with
Design Considerations for NinePatch
NinePatches are a powerful tool for creating images for the backgrounds of View
Activities that may have a variable size.
To create a NinePatch, draw single
pixel black lines that represent stretchable areas along
the left and top borders of your image. The unmarked sections won’t be re
sized, and the
relative size of each of the
marked sections will remain the same as the image size changes.
NinePatch images must be properly defined PNG files that end in .9.png.
It’s not uncommon for an app to have over 500 pieces of individual graphics. Therefore, it
itely help to adopt a convention for naming the files.
A sensible naming convention allows a developer to quickly locate files and understand the
structure of a project by grouping common or associated elements together through a
shared predefined name whi
ch trails to a specific description.
Here is a naming convention that we recommend and described all elements associated
with a Contact Button within a project.
Where the colours above represent:
The current feature of the
The action of the feature
The status of the action