How screen fragmentation will affect the way interfaces are designed.
On October 13, Apple held its annual iPhone event and unveiled four new models of its smartphone. Much of the discussion has been about the new design and features, so let’s not dwell on them in detail:
I think going back to the iPhone 5 / iPad Pro style is a great choice and I personally love this design. I also love its professional features and the fact that there is now a smaller iPhone. Magnetic charging gives hope that a future Apple laptop (powered by an ARM processor) will charge in a similar way.
But behind the beautiful design, many did not notice the obvious problem.
If you’re a designer working on mobile apps (or responsive websites), you probably know that Apple’s mobile devices are on the rise. This is how artboard presets look in Sketch and Figma.
But the new iPhone models will only complicate matters. Remember when Steve Jobs introduced the iPhone 4 with Retina display?
He emphasized that the base resolution of the phone is exactly the same as that of ALL other iPhones – 320 x 480. Only the pixel density is 2 times higher.
It was a great and easy time for UI design. You designed everything at 320 x 480 pixels and exported assets @ 2x for Retina display (640 x 960).
It was in the Apple style – a clear and simple way that boils down to eliminating unnecessary complexity.
Welcome to 2020
So where did these 360×780 and 390×844 resolutions come from? This is just 1/3 of the basic resolution of these phones. But that adds unnecessary complexity, right?
So how do you deal with this?
In the case of the iPhone 12 and 12 Pro, according to this tweet, we get a new width of 390.
But the iPhone 12 Mini gets a reduced resolution of 375 x 812 – the same as the iPhone X. The problem is that this ratio is no longer 3x, but 2.88. And of course, with a smaller screen, it doesn’t hurt that much, since most of the actual calculations of how to display objects are done in code.
So how do we design?
Above, you can see the design of the application that we are currently creating on HYPE4. As you can see, it is not perfect as it needs to adjust the spacing of the top and bottom parts of the interface to display correctly on different phones. On some models, the main button needs to be scrolled, so we’ll have to adjust the entire card and font sizes so that these devices still fit. (This is happening in development).
Of course, the Swift interface and other coding improvements simplify the whole process, but during the design phase, we still want to see how the design will look on a larger device. We also use Sketch Mirror quite often for previews on these devices, so it forces us to do a little more work than we would like.
Up to this point, we have designed a 375 x 812 viewport for the iPhone X and a 414 x 896 viewport for the larger iPhone. These sizes covered most of the models, and the developers adjusted the layout to accommodate more content (or simply increase it) on the remaining devices.
But what about the new widths 390 and 428?
Should we just enlarge the design for these phone models?
Depending on the circumstances. In the case of content consumption, the interface can remain approximately the same size, while the content itself can be enlarged and displayed in much higher quality (in pixels).
But simply scaling each design can end up losing the nice balance of fonts we’ve tweaked for specific sizes. Elements may start to appear too large, too small, or too wide.
Also, some zooming in or out can result in poor anti-aliasing of very thin lines, since everything is based on pixel approximation. Therefore, if you are using very thin / light fonts, readability may be affected.
Apple addressed this issue with the release of iOS 7 by introducing bolder / thicker fonts and getting rid of most “light” fonts. But some designers (and even more so product owners) like these lightweight fonts because they somehow consider them “minimalist” and a sign of “good design.”
Fold is a rather old concept of an invisible line separating what we see on the same screen (no scrolling) from the rest of the design. The idea is that all critical elements should be positioned “above the fold” for easy access.
There were a number of arguments in favor of “people don’t scroll”, which sounds a bit silly these days (given the fact that we scroll 300 meters on average every day).
But this can affect some e-commerce projects, carefully crafted to fit as much relevant information and a BUY button on one screen as possible. Of course, we can create an overlay button, but this will not solve the problem of clipping some of the content on certain phones.
I believe it might be easier for ecommerce to test the experience by simply scaling up the same design to get bigger, as this will give us a more consistent view of what people are looking at across all devices.
The button was 44 points high (and 44 pixels high at 1x scale) was 88 pixels high at 2x scale, rendered from the same 44 pixels in a 320×480 viewport.
I miss the days when there were only two resolutions based on the same viewport. This greatly simplified the design of an experience that was also easy to measure.
With the current fragmentation, iOS is slowly becoming the same as Android – with more resolutions, aspect ratios and devices that add complexity.