3

If you're laying out an interactive touch UI element, such as a button, you want something with a sensible physical size, so the user can hit it comfortably. In this way, laying out a touch UI is just like laying out physical buttons and knobs on an electronic device. And for this kind of physical engineering, millimeters (or inches) are the unit of choice.

For some reason this doesn't seem to be the case in touch UI design. I don't consider myself extremely well-read in the subject, but I've honestly never seen anybody use mm as a unit in, say, an Android layout file. But I've seen endless debates about "px" vs "dp" vs "sp" vs who knows what.

The "device-independent pixel" (which on Android is defined in terms of physical length - 1dp ≈ 0.16mm) seems like a really convoluted way to specify a length.

Why not just use millimeters?

Is it a problem with devices not supporting these units properly? Is it a cultural thing (programmers might be more used to thinking in "some sorta pixels" rather than physical units)? What's going on?

Matti Virkkunen
  • 63,558
  • 9
  • 127
  • 159

4 Answers4

6

Generally, you'll find mobile usability folks talking about millimeters. But programmers and visual designers talk about density-independent pixels or points (1 Android "DIP" = 1 iOS "point") because even if you could specify a measurement in millimeters exactly, you'd end up with rounding issues or half-pixel anti-aliasing ugliness:

1mm equals 6.3 DIP (degree of precision there depends on the exact DPI value of the screen, since dip are quantized to the nearest of 120/160/240/320/480/640 dpi). That means on a standard G1-style 160DIP screen, if you specify a button as (let's say) 8mm, it'd be 50.4 pixels on that screen - good luck rendering that with any degree of precision, or telling Photoshop to end a line exactly 50.4px. And just rounding isn't much of a solution; the screen is still a fixed total width in pixels, and those rounding errors would compound in ways that mess up symmetry if you're (let's say) laying out a grid of buttons with specific sizes and padding amounts.

Specifying that as (let's say) 48DIP is much better, since that smoothly scales: 48px at 160DPI, 72px at HDPI (240) and 96px at 320DPI (AKA 2x in iOS terminology), no fractional pixel rendering or rounding needed.

As to why exactly the 160DPI pixel won out as the 1x mobile unit of measurement for the density-independent pixel, blame the first few iPhones and the HTC G1, which shared that configuration.

Yoni Samlan
  • 37,905
  • 5
  • 60
  • 62
  • Ah, so using a unit like dp makes it easier to size things so that they still end up on pixel boundaries, even if the pixel density changes. I guess you could still run into ugly rounding in some cases (say, 13dp on 240DPI would be 19.5px), but it does definitely make it easier. Makes sense. Thanks! – Matti Virkkunen Oct 22 '13 at 19:55
  • Yeah, that's really an Android issue only; iPhone only has MDPI and XHDPI, which works out pretty cleanly as always 2x the DIP measure. LDPI, HDPI, and XXHDPI+ can cause those fractional/rounding issues on Android unless you use 4DIP multiples only, since LDPI and HDPI end up being 0.75x and 1.5x respectively. – Yoni Samlan Oct 22 '13 at 20:04
2

I think the W3C provides a decent explanation of various units of measurement for screens, and where each has advantages and disadvantages. I would also very highly recommend Roman Nurik's Density Independent Pixels video. While it doesn't directly answer your question, it provides a lot of great information.

Here are my arguments for DPs instead of mm:

Resources

This is probably the biggest one. When designers and developers create image or video assets, we don't use physical sizes. If you take a picture with your camera, you can't say that the picture is 5 inches tall. How tall the picture is depends on how you decide to print it out.

Thus if I want to display an image to my users or I want to create a button graphic, I can't simply create the resource at 10mm wide by 10mm tall. That one image will render at different sizes on different screens. Even if the device/code does scale the image to exactly 10mm tall, it will look incredibly pixelated on most TVs, and/or will have more detail than a low density device (such as a watch) will be able to display (thus wasting the device's resources).

The answer then is to export a single image at different sizes so that it looks good across multiple devices.

Of course there are other ways around this. Vector graphics could solve this problem, but that's a completely different topic.

DP

As for an Android-specific answer- we kind of do. As you pointed out, we use DP which can be roughly converted to conventional physical units of length such as mm.

However, using DPs works in tandem with Android's density buckets to allow designers to create assets for a finite set of display sizes. In my opinion, labeling these buckets with a physical measurement would be a bit more confusing, as a 4.2" phone might be in a 4" bucket.

SP

SPs are used primarily for text to allow the user to customize their font size. Defining a font size in pixels or mm would be misleading once the user changes their scaling.

Bryan Herbst
  • 66,602
  • 10
  • 133
  • 120
  • Good point about the density buckets. I didn't think about those. Unfortunately I can't accept two answers... Let's hope some day (with really high density screens and vector graphics etc) we won't have to worry about creating such a large number of assets to support everybody. – Matti Virkkunen Oct 22 '13 at 20:17
  • Buckets are a good call. The `swXXXdp` buckets Android 3.2+ supports are a nice way of talking about screen sizes without resorting to diagonal measurements. That said, they could just as easily be called `swXXXmm` without really changing how they work. And vector graphics don't really solve the underlying issue: at the end of the day, even vector graphics need to be rendered onto the display's actual pixels, and so unless you specify measurements for laying those out that convert to real pixels, rounding or half-pixel anti-aliased rendering types of issues would still occur. – Yoni Samlan Oct 22 '13 at 22:04
  • @Yoni: When the pixel density is really high enough, rounding and anti-aliasing shouldn't matter anymore. – Matti Virkkunen Oct 23 '13 at 21:12
0

it is because Android supports many device sizes and resolutions. Would you want to develop an app that accepts touches in certain places measured by mm and have that location be different on a phone vs a tablet? Or a hi-density tablet of the same size as a low density tablet? Or even just the height/width ratio differences between phones and tablets.

Millimeters is a hard measurement that reflects real life distance, but not the number of pixels. Units such as "dp" and "sp" take into account the pixels as well as the size

Martin
  • 4,711
  • 4
  • 29
  • 37
  • 1
    A "dp" *is* a real life distance. See link in question. – Matti Virkkunen Oct 22 '13 at 19:36
  • It's more of an approximation of a real life distance; see my below answer. DIP are quantized, not based on the exactly accurate DPI value of the screen. But Martin is incorrect about the overall point: DIP don't take physical screen size into consideration at all, only density. That is, whether the screen is 3" or 10", if the panels are exactly 320DPI, a button specified as 160DIP = 320PX = 1 inch, on both displays. But if the panel is 360DPI, that 160DIP button would actually render at 0.88 inches, since Android would still consider that to be an XHDPI display, not some fractional variant. – Yoni Samlan Oct 22 '13 at 19:56
  • @YoniSamlan: Ah. The quantization thing must've been on some page I didn't take a look at, since the definition on the page I linked to pretty much says it's exactly that distance and that's it. – Matti Virkkunen Oct 22 '13 at 20:18
  • Yeah - they call this "generalized screen density." There's a diagram on Google's "Supporting Multiple Screens" [documentation](http://developer.android.com/guide/practices/screens_support.html#range): "Two devices that report a screen density of hdpi might have real pixel densities that are slightly different. Android makes these differences abstract to applications, so you can provide UI designed for the generalized sizes and densities and let the system handle any final adjustments as necessary." – Yoni Samlan Oct 22 '13 at 21:58
0

Using sp/dp will make your Android applications compatible with multiple screen densities and resolutions

Which is not possible with mm where your app layout is independent of resolution .

Vivek Mishra
  • 350
  • 2
  • 12