I'm currently working on wireframes for a mobile app and there's something that seems to slip my mind: In the Android Design Guidelines, they state the following:
On average, 48dp translate to a physical size of about 9mm (with some variability).
But, according to the Android Developpers Dev Guide, they calculate a dp
using the following formula:
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. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
So let say that for simplicity, I'm doing my design at 160dpi so my graphics have the right size according to recommended standards. When printed, I scale down my document by 2,22 (160dpi/72dpi) so the printed result gives the actual physical size on paper.
I want my buttons to be 48dp high. But if I do the maths, following everything I read, I'm nowhere close to a 9mm size by specifying 48 as my button height.
48dp / 160dpi = 0.3 inches, so 7.62 mm...
What am I clearly missing/doing wrong? Where is that 9mm coming from?
Thanks!
Update
Here's what helped me understand what I was missing from the accepted answer.
Take as an example the screen density of 200. Android will use 240 to base its calculations. So:
Now the trick is that the actual device density was 200. So the pixels will appear bigger than on a 240dpi screen. To get the physical size on the 200dpi device, we have to get the difference between both resolution and apply it to the 0,3 inches:
I know this is exactly the same as stated by @kabuko:
(48dp / 200ppi) * 1.5 * 25.4 mm/in = 9.14400
but the step by step way helped me figuring out what was happening under the hood.
The exact statement you're referencing is:
On average, 48dp translate to a physical size of about 9mm
If you look at this image from the Supporting Multiple Screens doc:
You'll see that there are density buckets (ldpi, mdpi, hdpi, xhdpi). Each of these are not fixed densities, but rather a range of densities which end up mapping to fixed numbers used for various density calculations (120, 160, 240, 320 respectively). 160 is rarely the actual pixels per inch for an mdpi device, it's just the abstracted value used for simplicity's sake.
Your calculations are correct, but you assume that 160ppi is the average density (assuming mdpi devices) just because 160dpi is the abstracted value for mdpi. Apparently it's not, if the statement you reference is indeed true. I suspect that there are a lot of devices which average out to around 200ppi which end up getting categorized as hdpi. That would be: (48dp / 200ppi) * 1.5 * 25.4 mm/in = 9.14400 mm. Just a guess, but certainly I think the underlying reason is that the average isn't 160ppi.
Update:
Here's another quote from the doc from the design site:
If you design your elements to be at least 48dp high and wide you can guarantee that [...] your targets will never be smaller than the minimum recommended target size of 7mm regardless of what screen they are displayed on.
So the size varies from > 7mm to at least 9mm (given 9mm is supposed to be average I would think the top range should be < 11mm). Yes, 48dp should be "approximately" the same size on all screens, but what "approximately" really means is not really specified. Your 7.62mm is within range. Their 9mm value is just for the "average" which is an unspecified ppi.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With