Everything is a grid

When you design or build a website, app, icon or UI element, you’re designing to a grid. It doesn’t matter if that grid is pixels, points, percentages, inches, centimetres or some other kind of measurement. It can be as abstract or specific as you like. It’s still a grid.

Design grid and screen grid #

The unit of measurement, the positioning and how the design grid relates to the way things are eventually displayed on the screen make a big difference to the image quality of the result. This is true if you’re drawing everything in code, everything with vectors, or using bitmaps. The important factor is how the design grid relates to the screen grid.

If the design and screen grids don’t match, pixels get blurred. Quality is lost. Every single element on the screen is subject to these rules — elements drawn in code, as a vector or as a bitmap (if they’re scaled, bitmaps lose even more quality than things drawn in code or as vectors).

The rise of mobile OSs like iOS, Android and Windows 8 Metro have ushered in a large range of display sizes and pixel densities, as well as various methods to cope with the variations. Mobile device pixel densities range from about 160ppi to 320ppi. Apple took the high road and limited UI scaling to two sizes, with newer displays being exactly double the pixel density of the first generation of their devices. This is ideal for scaling. Android and Windows 8 can’t easily do that, due to the range of devices they’re run on. Their business model dictates variety. Variety dictates non-ideal scaling. Non-ideal scaling dictates blurry pixels or non-ideally placed pixels.

Android uses density-independent pixels as its preferred design grid, and scales UI to match the resolution of the device’s screen. Assets are often created at 160ppi, 240ppi and 320ppi, which relates to scales of 100%, 150% and 200%.

“The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a “medium” density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels.”

Windows 8’s Metro does a similar thing. Metro assets are created at 100%, 140% and 180%.

“Windows scales applications to ensure consistent physical sizes for UI elements regardless of the pixel density of the screen.”

Matching design and screen scales #

If your design is being scaled, which scales offer the most accuracy? The chart below compares design pixels to screen pixels.

A perfect match is shown in green (this is desirable). The matching pattern repeats every 20 pixels due to the scales used in the chart, so we can work an approximate score for any screen size (it will be an exact score if the screen size is a multiple of 20). The overall score given to each scaling percentage is a comparison of perfect matches to overall attempts.

As you can see, scaling to any size other than exactly double is detrimental to the accuracy of how your original design is represented on screen. The asset scales of 140% and 180% required for Windows 8 Metro hit their target less than 25% of the time. Android’s 150% scale lands on a neat pixel boundary half the time.

Here’s how the various scales mentioned above treat a simple graphic. As you can see, the only scales that maintain their integrity are both the extremes, 100% (1.0) and 200% (2.0). Note that the shape below was drawn as a pixel snapped vector (the best method possible).

Icons can be specifically redesigned at each scale, but some of the decisions involved become difficult. That’s because the decisions are creative, not technical. Strokes have to be made thicker or thinner. Things that were centred previously can’t be. Redesigning an interface for several fractional scales is a huge amount of work and is likely to give poor results, due to the simple, but inescapable maths involved.

Android and scaling #

Android 4.0 Ice Cream Sandwich’s status bar can be seen below at 160ppi, 240ppi and 320ppi (100%, 150%, 200%). These screenshots were taken from the Android Emulator. It’s possible the image assets aren’t final, but to me the icons look horrible at all sizes and have obvious bitmap scaling artefacts.

iOS and scaling #

On the other hand, iOS’s UI scaling gets a perfect score, because Apple only ever use 100% and 200% scaling. Apple’s tight control over the hardware and software for their mobile devices gives a distinct advantage for UI design accuracy at their chosen screen pixel densities. The image below is the iPhone’s status bar as seen on the iPhone 4/4S and the iPhone 1/3G/3GS (yes, I’ve cut it up a little to show the battery icon next to the Wi-Fi icon).

Apple solved the problem by making strong product choices.

This is why I like designing for iOS.

Published 4 November 2011.