Leaked photos, back plates, bezels and case-maker “dummies” have given us confidence of dimensions and some of the design details of the next iPhones. As we move closer to September 9, it is an article of faith among Apple AAPL +0.73% watchers and the easily convinced general public that there will be two models, the 4.7″ iPhone 6 and the 5.5″ iPhone 6L phablet.
Information about exactly how many pixels those 4.7″ and 5.5″ screens will contain and how new and existing iOS apps will make use of the extra real estate has been far less certain. Two developments in that aspect of the story this week give us the most detailed answers yet to those questions. Along the way we have also discovered a possible bit of Apple misdirection designed to throw the faithful off course.
The first piece of the puzzle—and the source of the apparent head fake—emerged from deep in the bowels of the Xcode 6 Beta 6 release that third-party Apple developers, myself included, got access to last Monday. Hidden ten levels deep in the file hierarchy, 9to5Mac’s Mark Gurman discovered a file in the updated iOS Simulator called “DefaultIconState-414w-736h~iphone.plist.” Gurman understood that this was evidence of a new screen format. What exactly it specifies is a matter of debate. To understand the possible implications requires a little bit of geeky iPhone lore.
In the beginning was the iPhone, and it was small. The original iPhone, the iPhone 3G and 3GS possessed a mere 480 by 320 pixels. And then Jobs said, let it be retina! And it was, and it was good with twice as many pixels in the same 3.5″ screen size. The iPhone 4 and 4S had 960 by 640 pixels. Alas, Jobs passed on but, lo, the iPhone rose on high! The iPhone 5, 5S and 5C all have 1136 by 640 pixels. Stretching the iPhone 5 to a 16:9 proportion had a big impact on how app designers used the larger available space, but it was less of a conceptual leap than the pixel doubling of the iPhone 4. From that point on, Apple’s “retina” devices had 2x pixels multiplied by the base “points” of the native device. So up until September of 2012, all iPhones were designed on the basis of 480 by 320 point proportion, with graphics rendered at 2x resolution for the later models.
So in the lead up to the iPhone 6, many have wondered if the large screen 6 series would be the occasion of an historical tripling of the resolution based on the iPhone 5 proportions of 568 by 320 points. Gurman had based an earlier prediction on this premise and reported that Apple was testing iPhone 6 units with a resolution of 1704 by 960 pixels. Both of Gurman’s theories seemed to suggest that the two new iPhone sizes would have identical pixel counts, following the example of the iPad/iPad Mini lines.
Friday, a second puzzle piece clearly shows a different and more nuanced story thanks to John Gruber, the Apple blogger who writes under the moniker Daring Fireball. In his post, “Conjecture on Larger Screen iPhones,” Gruber wields some fearsome middle school math to show that Gurman’s own conjectures are either wrong or only partially true. My colleague Ewan Spence discussed Gruber’s conclusions in a post yesterday, so I won’t belabor the details. Bottom line, the Gruber conjecture is that the two devices will have both different pixel dimensions and different retinal multipliers. To quote Gruber:
- 4.7-inch display: 1334 × 750, 326 PPI @2x
- 5.5-inch display: 2208 × 1242, 461 PPI @3x
Yes, I know, Spence already brought this up in these pages, so what more is there to add? Actually quite a lot. Gruber may not be exactly right about the pixel counts, but the reasoning behind his calculations is knowing and on target. Gruber is a true Apple insider, but he goes out of his way to say that “No one who is truly ‘familiar with the situation’ has told me a damn thing about either device.” In the next breath, 0f course, he goes on to mention that, “I have heard second- and third-hand stories, though, that lead me to think I’m right.” Gruber is an engaging writer, but he is worth listening to because he has followed Apple so long and so deeply that knows what is “Apple-like” and what is not. He could rightly be called Apple’s Boswell .
Hardware specs aside, what is so right about the “Gruber Conjecture”? It obeys Apple’s first principles of user experience. Yes, keeping things simple for developers is nice, and yes, going from 640 pixels wide to 960 pixels wide has Pythagorean simplicity to it, but in the end the most important reference point is the physical fact of the user. Apple’s point proportions are based on the scale of the human finger and the minimum size of a touch point is defined as 44 points. On a retina 2x device that minimum will be 88 pixels, but it is still represented as 44 points. The second important human factor (as Apple’s design guidelines are known) has to do with the acuity of the human eye at the relevant distance at which a device will be viewed. Apple considers a device screen retina if the pixels are small enough at a normal viewing distance such that the individual pixels are not distinguishable by the naked eye. For the iPhone this was originally defined as >300 pixels per inch with a target of 326 pixels per inch. A device, like a desktop computer, that one may normally view from more than a foot away can have a lower density and still be technically retina, but 300 PPI is a widely respected standard.
First, it is worth saying that there are many people who really like the current form factor and will be curious to see if bigger really is better. But assuming you are actually interested in one of the larger iPhone models, one of the key questions has been how will the extra pixels most likely be used, to scale up touch targets or to add functionality? I asked this in another way last week in my post last week, “Will Big Battery In 5.5-inch iPhone 6L Buy Full HD Video Or Just Less Wall Hugging?” Gruber answers with a resounding BOTH! As devices get larger we expect larger touch targets but we also expect more content. And there is a ratio to these expectations that Apple strives to maintain as it has embraced three aspect ratios and two scaling multipliers among its growing fleet of iOS devices. Despite this apparent fragmentation, Gruber is adamant that what Apple has “ never done, and I believe never will do, is redefine the virtual point to something other than 1/44th the recommended minimum tap target size for every device.” All righty then!
But what about how the new larger devices will abandon the sacred Jobsian tenet of one-handed usage? Will this change cause a move away from top navigation in favor of bottom navigation, for instance? As a case in point, have a look at the way Internet Explorer 11 for Windows Phone renders websites with no top address bar. I asked designer Jeremy Olson at Tapity (maker of theHours time tracking app that I reviewed recently) what he thought about this possibility. “That is a huge question,” he replied. “Apple’s main navigation paradigm is built around a bar at the top. The iPhone 5 already made it a bit of a stretch to reach that top bar with your thumb when you used the device with one hand. I use my phone with one hand all the time and I can’t imagine how I would navigate a lot of current apps on a taller screen. Apple, however, has already been educating developers to use things like optional gestures to help users navigate between views without having to reach up for that nav bar at the top. So even now, instead of reaching for back button at the top, you can swipe to the right to navigate back. I don’t think Apple’s top-bar dominated design paradigm is going away but I think more and more developers will need to augment it with optional gestures or bottom navigation to accommodate one handed use.”
There are several important points within Olson’s response. With all of these changes, Apple has been trying to move developers in the direction of gesture support and flexible sizing now for years. This year’s World Wide Developers Conference placed a lot of emphasis on the use of vector graphics and auto layout to make universal iPhone apps regardless of scaling. Gruber writes that:
Apple has already started encouraging iOS developers to begin using adaptive layout techniques. See session 216 from WWDC 2014: Building Adaptive Apps with UIKit. What’s telling when you watch that session and read the documentation is that developers should clearly anticipate new aspect ratios (whether for new displays, or for a still-hypothetical but rumored split-screen multitasking on future iPads) and physical sizes…
Olson concurs that, “When talking to developers, it seems Apple has been going more and more for unification rather than fragmentation. I think marketing your app as ‘enhanced for iPhone x’ will be discouraged. Rather, I imagine that Apple would like to see developers use auto-layout (a tool that allows developers to make their apps mold to different screen sizes automatically) to ensure that their apps work really well on nearly any screen size. While Apple obviously didn’t confirm any rumors about new form factors during their latest World Wide Developers conference, they emphasized using auto-layout like never before.” Olson points out that this message, “was even more clear when developers opened up the latest version of Xcode to see that the default window for building interfaces is no longer a portrait iPhone, but a square. Apple no longer wants developers to stop thinking about designing apps at a particular screen size, and start to think how to make their interfaces size-agnostic. It even goes back to when Apple went away from rich, skeuomorphic interfaces and moved to a simpler design aesthetic. It is a lot easier to stretch a flat button than it is to stretch a button that looks like a physical object.” For a long time, iOS app developers had the luxury of fixed screen sizes, but now they find themselves in a world not dissimilar to their counterparts who make responsive designs for the web.
Another interesting point relating to number of pixels vs. battery size is relevant to Gruber’s proposal that Apple will handle the screen resolution of the iPhone 6L phablet in a radically different way than the now midsize iPhone 6. With the 6L Apple will buy both more-than-HD video and less battery-busting “wall hugging.” And all this at an “amazingly sharp” resolution of 461 pixels-per-inch. So there, Samsung! Gruber even says he’d wager that, “Apple comes up with a new marketing name for it: super-retina or something.” Meanwhile, the 4.7″ iPhone 6, which has a considerably smaller battery than the 6L, would maintain the current 326 PPI that has been Apple’s retina standard for the iPhone, but would add an extra 38% to the screen area of the current iPhone 5 line.
The 68% increase in screen real estate combined with a 41% increase in resolution—and maybe even a sapphire screen—should easily justify the rumored $100 up-charge that Apple is expected to levy on its iPhone phablet. The production demands of all that may mean that the 6L will be announced on September 9 with the 6, but the actual phones may not be delivered until later in the fall.
But wait, what about that devious misdirect that Apple may have foisted on developers in Xcode 6 beta 6? Well, you see, in the same iOS simulator directory that contains the 736 by 414 point format, there is also a file titled, “DefaultIconState-568h~iphone.plist.” This is the screen format for the existing 4″ iPhone 5 series phones. By placing the 736 by 414 pixel format in the iOS simulator, Apple would seem to be indicating that there will be only one additional format and that thus, somehow, the 4.7″ device will have a 2x resolution of 1472 by 818 pixels. Only half true according to Gruber! Yes, the 6 will be 2x, but based on a new 667 by 375 point format. And the 736 by 414 point format in the present Xcode release will be the basis of the 3x 6L, weighing in at 2208 by 1242 pixels. (We will be looking for evidence of that“DefaultIconState” file in the next release of Xcode!)
The reason why the 6L will not be, for instance, 1565 by 880 pixels, maintaining 326 PPI, is that on a larger device we want the touch targets to be bigger. The iPhone screen resolution equation is in fact a three-factor optimization, as Gruber lays it out here:
- Content area: showing more points on screen.
- Scaling factor: the number of points per inch.
- Sharpness/quality: the number of pixels per inch.
As such, a simple linear solution will never be optimal. So for app developers, the challenge is to make use of the larger screen area afforded by the new iPhone models but to continue to base designs on established human factors. Designers will want to make expanded use of gestures, particularly as alternatives to out-of-reach top navigation. The “DefaultIconState” files are merely lists of default icons, and that list is the same for the current iPhone (586h) as for the new format (414w-736h), but they don’t specify how those icons will be arrayed on the home page (aka the springboard) of the 6 or 6L. Following the iPad’s lead, It is possible that that Apple’s human factors engineers have determined that four icons across is optimal for a mobile device in portrait mode, no matter the screen size. Although, by Gruber’s logic, the 6L could make the springboard icons both larger and more numerous, in terms of usability, more may not be more. As I wrote in a very popular post back in February, “Will Apple’s iPhone 6 Phablet Push The Usability Of iOS To A Breaking Point?,” even the existing amount of icons per screen leads to more hunting around and swiping for deeper screens than is ideal.
Instead of adding more clutter, app designers and Apple itself should use the growing need for flexibility between screen sizes to introduce new organizational and navigational paradigms that are more about immediate intuitive gesture than about more elaborate hierarchies or more crowded arrays. Even though Gruber’s predicted iPhone 6 height surpasses the 2x retina iPads, Apple is indicating that the phone experience and the tablet experience are unique. The 6L will obviously be pushing that boundary, and it is now up to developers, both inside and outside of Apple, to make sure that the new kid doesn’t, in fact, break the usability of iOS 8.
No comments:
Post a Comment