Where the design community meets.
Some more info, to build on Joshua’s reply.
The Pixel uses a density of 2.6×. The Pixel XL uses a density of 3.5×.
Those are both non-integer values. When the UI is rendered, the view sizes and positions get scaled to the display size and rounded (to snap to pixels). The assets get bitmap scaled down. This is actually fairly abnormal for Android devices, where most have integer densities.
When rendering the display on a Pixel XL, Android will use 4× assets and bitmap scale them down to 3.5× (87.5%). That means they’ll be blurrier.
The scaling method for iOS is a bit different (I can provide a comparison if you’d like).
Skala Preview (with the Sketch Preview plugin) sends the current artboard from your Sketch document at the size it was created. Skala View shows the exact image it was sent, using 1:1 pixel mapping (you can also zoom in Skala View, and zoom factors snap to integer values, unless you have fit to screen enabled).
Please note that the Sketch Preview plugin has some scaling settings that will affect results, too.
If you create a 1440×2560 artboard in Sketch, and the Sketch Preview plugin has its default scaling (1×), Skala Preview will send the 1440×2560 image to Skala View, and Skala View will display it at 1440×2560, filling the screen (assuming Skala View is at 100% zoom).
But, that won’t match a production app, if you’re creating your artwork at 3× or 4× scaling in Sketch. If you’re creating your artwork at 3×, then Android will display it larger (3× → 3.5×, or 116%). If you’re creating your artwork at 4×, then Android will display it smaller (4× → 3.5×, or 87.5%).
What’s the solution? That will depend on how you want to work.
If you want to work at 1×, where 1 pixel in Sketch = 1 Android dp, then use these settings:
Working at 1× means you can use the exact dp sizes noted in the Material Design docs. This is my preferred way of working.
Those should mean the preview is the correct size. Please note that it won’t perfectly match how Android will render things, but it will be very close.
Disclaimer: I haven’t done any tests on a Pixel or Pixel XL yet, but I believe all the information above to be true. If someone has corrections, feel free to let me know.
Incredible comment. Thanks, Marc.
You're the man, Marc! Thanks a ton!
1 more question: It isn't completely clear to me why I should use the 412x732 resolution instead of the real 411x731 resolution. Why is that? :)
You can’t use 411.4285714286 or 731.4285714286 for your artboard dimensions, so you have to round the values up or down. Use whichever you’d prefer, but 412×732 sounds easier to work with, because it’s perfectly divisible by 4.
Ah cool, makes sense! Thanks!
So would it be correct to say that when working at 1× on the Pixel, the artboard dimensions should be 416 × 738?
And here I've been designing at 360 × 640…
Marc is suggesting 412x732. I'm not too sure where you got your numbers from. :)
360x640 will still be the right size, only the Nexus 5X & 6P and Pixel devices use the 411x731.
Using 2.6 as the scale factor for the Pixel (non-XL), here's my math so you don't think I'm crazy:
Does that make sense?
Oh yeah, for the regular Pixel. Makes sense, haven't thought about that.
Makes sense to me. :)
Hopefully I’ll be able to do a test on a Pixel and Pixel XL to confirm the numbers are correct (current numbers are based on screenshots and conversations with other designers).
Hey yeah I noticed the same thing but https://material.io/devices/ lists both devices as 411/731dp. The math for these devices just never find a source of truth, everywhere I look there is some weird rounding going on. Even if you did what I did and undo their math of how they arrived at 2.6 it doesn't add up. They list the dpi of Pixel at 441. 441/160 = 2.75625, not 2.6.
Personally I'm still not convinced that using the 2.6x or 3.5x approximate sizes (412 or 416) are better than using a multiple of 360. For one thing the math seems to work out better. I'm guessing this has to do with what happens when the mocks are rendered on a physical Pixel phone screen, or maybe because developers are using 412 or 416 dp's instead of 360 dp's. Still not fully understanding the reason behind this.
Definitely with you on the math. I much prefer the numbers that multiples of 360 give me.
However, if you're using something like Skala to preview your mocks, everything would look a little smaller in real life than in your mockups.
If you're following the Material guidelines, this probably doesn't matter too much; you're going to be spacing things at 8dp, 16dp, 24dp, etc. regardless of how it looks on a test device.
If you're creating your own layout guidelines, however—and you want to be sure you're seeing what the end user will see—then using the correct scale becomes more important.
Ok maybe I don't understand the meaning of density, because wouldn't it be easier to just use 360x640 artboards or some multiple of 360, since 1080/360 = 3, and 1440/360 = 4, vs. the repeating decimals of using 411 or 415, both of which are only close to the true number of 1080/2.6 or 1440/3.5. Including the material design spec, why aren't the @1x guidelines designed for 360/640 artboards, or 720/x artboards. It seems the piece missing in my comprehension is the 2.6x and 3.5x density information. I don't get why this piece makes us design in artboards of /2.6 or /3.5 size, instead of simply a multiple of the screen's pixel dimensions (1080 or 1440 wide). Thanks for all your explanations btw!
The device’s UI density is used to scale Android’s dp units to the screen pixels.
This means 1 dp will become 2.6 pixels on the Pixel. If you want to deal with dp units on your canvas when designing, you need to use a canvas that’s the screen res divided by 2.6. Dividing by 2.6 results in a fraction, so it has to be rounded up or down. It’s not as perfect as working with integer scaled displays, but I still think working at 1× is the best way to go.
Hopefully that makes the maths a bit clearer?
It’s worth noting that 1 dp becoming 2.6 pixels is a little more complex than noted above, when it comes to the final app running on the device — bitmap assets will be bitmap scaled down from the nearest larger size (probably 3×), and view sizes will be rounded so they align on a pixel boundary.
Anyone know why 2.6 and 3.5 were chosen when, if you do the math, they are closer to 2.75 and 3.4?
The Pixel has a ppi/dpi of 441.
mdpi by default is considered 160
441/160 = 2.75625, not "2.6".
if it were to be 2.6, you would need to do this: 441(dpi) / 2.6 = 169.615..., so rather than considering mdpi as 160 you'd have to consider it as 169.615 etc
Same goes for Pixel XL
Has 534 pixel/in
says it's 3.5x
534/160 = 3.3375
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.