My Reasonable iPhone 6 Prediction
Since a larger iPhone is all but a given at this point, the interesting question is how will Apple do it? There are several directions Apple could take. Before I delve into speculation, let’s rally around some terms.
Logical Size – The size of a display measured in points, not pixels. An iPad 2 and an iPad 4 have the same logical size (768x1024), even though they have different scales.
Resolution – The size of a display measured in actual pixels.
Scale – The multiplication factor applied (by software) to a display’s logical size. Up until now, Apple’s retina displays have used a scale factor of 2 – or “@2x” in common parlance. With the scale factored in, the iPad 4 has a scaled size of 1536x2048 compared to 768x1024 for the iPad 2.
Pixel Density – Independent of logical size or scale, pixel density is a measure of how many physical pixels occupy a given area of a display panel. The iPhone 5s and the iPad mini with Retina Display have the same pixel density, 326 pixels per inch (PPI). The mini’s display is logically and physically larger, but both displays are “cut” from the same materials.
Now for some fun speculation.
@3x Scale, Same Logical Size
Apple could increase the iPhone’s scale from @2x to @3x, re-using an existing logical size (either 320x480 or 320x568). This would allow them to use the same display panel already in use in the iPhone 5s, but cut it into a larger shape. This is more or less what Apple did with the first iPad mini; its display panel was the same as that of the iPhone 3G, just larger. The problem with this approach is that it would result in a phone that seems comically large for an Apple product:
320x480 points at 3x scale.
This would look even more ridiculous if I’d mocked up a 320x568 point ratio at an @3x scale.
Historically, Apple’s designers opt for modest differences in the physical sizes of a given product range (for example, 13-, 15-, and 17-inch MacBooks Pro). So if Apple chose to bump the scale to @3x, I would expect them to also use a higher pixel density than 326 PPI. This would require a new LCD panel, which might be prohibitively challenging. From what I understand, shipping LCDs with a new pixel density would require significant engineering and infrastructure resources, as compared to merely cutting existing panels to a larger size.
@2x Scale, New Logical Size
Alternatively, Apple could re-use the current retina iPhone LCDs, but cut them to fit into a new logical size. I think a logical resolution of 396x656 would be an interesting choice. This would increase the home screen layout by one row and one column:
396x656 points at 2x scale.
To my eyes, this looks like a more sensible size increase and a better use of the larger display. It also has the benefit of re-using the same 326 PPI display panel technology already being manufactured.
My Bet
For all these reasons, I think Apple is much more likely to ship an iPhone 6 with a new logical resolution at an @2x scale than an existing logical resolution at an @3x scale.
A Practical Introduction to Photoshop for iOS Developers
What follows is a crash course in Photoshop for iOS developers. I’m going to take a very nuts-and-bolts approach. I hope to demystify what it is that an iOS app designer means she says things like “working in vector” or “pushing pixels.” Beware the following caveat: this is an article about tools, not design. If this were an article about ice sculpture, it would teach you how to turn on the chainsaw. It’s up to you to sculpt an angel without losing a limb.
I’ll give you a winter prediction: it’s gonna be cold, it’s gonna be grey, and it’s gonna last you for the rest of your life.
Photoshop is a big beast. In some places its interface design capabilities feel tacked-on as an afterthought. When mocking up an iOS app in Photoshop, you’ll find that you only need a fraction of the available features. The unused features make it hard for newcomers to know where to begin. It helps to find your bearings before opening your first document.
A Stack of Layers
A photoshop document is a stack of layers that are composited in real time down to a single two-dimensional image. Every layer has several components:
1. Layer Content
Setting aside any other effects or styles that may be applied, a layer’s content is its most basic component. There are four main layer types, each with it’s own kind of content: raster, fill, shape, and smart object.
Raster – Raster layers are a (virtually) infinite canvas of bitmapped pixels. Photographers typically work with raster layers.
Fill – Fill layers fill the document canvas with either a color, a gradient, or a pattern. When designing an iOS app, you’ll almost exclusively be working with both shape layers and fill layers (more on this below).
Shape – Shape layers are vector paths filled with a solid color. Technically, a shape layer is just a fill layer with a vector mask. But it’s helpful to think of them as a separate type, since you’ll use them much differently.
Smart Object – Smart Objects are akin to blocks in Objective-C. Much like a block is both executable code and an object, a Smart Object is both a layer and link to another Photoshop document. Smart Objects are useful when mocking up new screens, but you’ll want to avoid them when creating image resources for production use.
2. Layer Masks
Every layer has an optional set of masks, which function like stencils. An individual layer can have up to two masks: a raster mask and vector mask (except shape layers, which can only have a raster mask, since they already have a vector mask by definition). For example, a raster layer could have a heart-shaped vector mask:
Masked Crusader
3. Layer Styles
Each layer has an array of options that apply styles to the inner and outer regions of its content. Layer styles include things like drawing a border around the visible edges of layer content (a stroke), or adding a drop shadow that casts a shadow on layers underneath.
Layer Styles Window
There are lots of layer styles, each with its own suitable purposes and range of possible effects. I’ll go into detail about some of them later on.
4. Blend Modes and Opacities
Non-opaque areas of layer content are composited with underlying layers according to the selected blend mode for that layer. The blend mode selector defaults to “Normal”, but there are many other choices. Many of the blend modes have exaggerated photographic effects, as you can see here:
Three blend modes, same shape and color.
Except for certain specific cases, you should always set each layer’s blend mode to “Normal.” When it comes time to save image slices as PNGs to use in your app, Photoshop will blend non-opaque areas with an empty translucent background, thus losing the information produced by a dynamic blend mode.
There are also two opacity sliders for each layer. The one officially dubbed opacity adjusts the opacity for the entire layer, including any layer styles that have been applied. The other opacity slider is called fill. The fill slider adjusts the opacity of the layer’s contents without affecting the opacity of the styles. The difference between opacity and fill is easier to understand with a visual example:
Opacity versus Fill
5. Layer Groups
Layers can be organized into a group, which looks like a folder in the the layer panel. Since Photoshop CS6, layer groups have their own layer styles and masks, as well as opacities and blend modes. This can be difficult to wrap your head around in the beginning, but it comes in handy when mocking up complex layouts.
Working in Vector
With new device form factors always on the horizon, it’s important for iOS designers to build mockups and image resources in ways that are easy to scale up or down as needed. The recommended approach is called “working in vector,” which is not necessarily a reference to working with SVGs. Most iOS app image resources are loaded as PNG files. But that doesn’t mean the Photoshop documents that generated them aren’t vector-based.
A vector-based Photoshop document is composed entirely of shape layers and fill layers. It is trivial to scale a non-retina @1x resolution document up to an @2x document, as long as it’s entirely composed of these two layer types. It’s often as simple as using the “Image Size…” menu item.
Some designers do all their mockups at non-retina scale and then scale up to retina for final processing. I prefer the opposite. Others make large sprite sheet documents that have both normal and retina scale images for app resources, side-by-side, sliced up for easy exporting. Whatever your approach, the most important thing is to avoid using raster layers at all costs. Scaling up a raster layer to a higher resolution will make your hard work look terrible:
Vector versus Raster
Sample Project: A Classic Button
Let’s put together everything discussed above in a sample project. It may not be in-fashion these days, but a classic iOS button is a great learning project for experimenting with shape layers, layer styles, and vector-based documents.
“Gee, our old LaSalle ran great…”
1. Create a New Document
New Document Modal
A document for mocking up an iOS app should be in the RGB color space with a resolution of 72 pixels per inch. I usually work in a 16 bit color depth since it produces smoother gradients. If you plan on exporting PNGs for use in an actual app (say, for button states), be sure to have a transparent background.
2. Disable Color Management
Notice in the screenshot above that I selected “Don’t Color Manage This Document.” Photoshop processes color differently than other OS X apps. When you’re designing for mobile apps or for the web, you’ll want to disable all forms of Photoshop’s color management. In addition to disabling color management for all new documents, you’ll also want to select “Monitor RGB – Display” for “RGB Working Space” under the “Color Settings…” menu item:
Color Settings
Using the native RGB space of your Mac’s display, your Photoshop document will look similar to what you’ll see on a device. But there’s no substitute for using something like Skala Preview to preview your designs in situ on an iPhone or iPad. Marc Edwards from Bjango has an excellent article that goes into detail on color management and Photoshop.
3. Enable Pixel-Snapping
All vertical and horizontal edges in your mockup should be aligned to whole integer pixel margins. It’s possible for shape layers to have path segments that are out of alignment with whole pixel margins. When this happens it makes the edges of your shapes look fuzzy:
Pixel snapping is crucial.
There is an option in Photoshop’s general preferences screen called “Snap Vector Tools and Transforms to Pixel Grid” which, when enabled, makes this much easier to manage.
This button toggles pixel snapping.
If you’re working on a retina resolution document (1536 by 2048 pixels for a portrait iPad), try to make all horizontal and vertical edges line up with even-numbered pixel margins. That way when you scale the document down for a non-retina screen, your edges won’t fall on sub pixel boundaries (which leads to fuzzy edges).
4. Add a Solid Color Fill Layer
Using a fill layer makes it easy to non-destructively tweak the background color of the document whenever you wish. To speed up my work, I use John Gruber’s system keyboard shortcut for the Help menu search box. I just start typing N-E-W F-I-L-L until the desired item appears in the drop-down.
New Fill Layer
After picking a color, your document will have a backdrop to go behind the button.
Fill layer in action.
5. Add the Button Shape Layer
First put up some guides (either with the menu item or manually by dragging inward from the rulers) to get the size and position of the button the way you want.
Measure twice, draw once.
Next, choose the rounded rectangle shape tool from the tools panel. You may need to click and hold to switch between the shape tools from the sub-menu.
Shape Tool (click and hold)
When you’ve selected the rounded rectangle tool, the options toolbar changes to show the options for this tool, including a corner radius:
Corner radius option
If you can’t see the options menu, toggle it’s visibility under the “Window” menu item.
Change the corner radius to something neither too small or too large. Since this is a big button at retina scale, I think 16 pixels looks good. Now draw in your shape:
Newly-drawn Shape Layer
Notice that there is now a layer in the layers pane called “Rounded Rectangle 1”. I recommend giving a proper name to every layer in your document.
6. Change the Button’s Color
To change the fill color of your rounded rectangle, double click in the thumbnail preview for that layer in the layer pane (can it be less obvious?). This will make the color picker appear. Pick a bright blue color, but not too saturated. Something like this:
New Shape Layer ready to go
7. Experiment With Layer Styles
With the options in the Layer Styles window, there is shocking variety of possible effects you can achieve – even with just a single shape layer. The full breadth of each tool is outside the scope of this post, but I’ll give you a taste with the following recipe. To show the Layer Styles window, double click in the empty gray area of a layer row in the Layers Pane (yeah, I know, even less obvious).
Inner Shadow
Inner Glow
Gradient Overlay
Gradient Overlay Submenu
Outer Glow
Drop Shadow
Bonus Points: Add an Icon Shape Layer
For bonus points, switch the shape tool to the custom shape option and add a white icon to your button:
Style the icon to make it look sort of like mine does here. Remember this star is just one shape layer. You should be able to create this glossy, raised look with just its Layer Styles window alone.
Basement Menus and Breaking the “Rules” of App Design
Luis Abreu has an interesting breakdown of basement menus in his recent post: Why and How to avoid Hamburger Menus. It has some great points and is certainly worth a read, but it got me thinking about when to break the “rules” of UI design.
During the course of my design critique of Glassboard for iPhone, I listed the questions I ask myself when considering whether to use a basement menu in an app:
Is there a single screen where the user spends most of her time?
Is there a dynamic number of equally-weighted menu items?
Are the contents of the menu easy to memorize?
Are hard-to-memorize items used infrequently?
Are the number of items kept to a minimum?
It’s important to note that this is a list of questions, not a list of reasons. There are times when a basement menu is a bad choice, and there times when it is a great choice. Every app has a unique set of goals and constraints. It’s up to the designer to find a good solution. Don’t limit your choices prematurely by assuming some options are off-limits.
As I’m discovering with Unread for iPad, even design patterns that are almost universally maligned can sometimes be the best choice. Apple, via moments like an on-stage presentation by Phil Schiller1, taught us all how much better iPad apps are than most Android tablet apps. The latter are typically just scaled-up versions of their phone-form cousins, whereas iPad apps are designed to take advantage of the iPad’s display. I don’t know about you, but I found myself immediately agreeing with Schiller’s comment that day. From then on, I took it as a given that no self-respecting app designer would design an iPad app that is just a blown-up form of its iPhone version.
But a scaled-up iPhone layout turned out to be the best choice for Unread on the iPad. As I describe in detail here, a full-screen iPad layout is more faithful to Unread’s goal of a relaxed, focused reading experience. It also makes it possible to navigate almost anywhere in the app without having to reposition your hands from the edges of the device.
The fun and the frustration of creative work are two sides of the same coin. Treat every project like it’s your first. Marc Edwards shared a fantastic anecdote about this recently. He recalls what it was like to work with a lead designer who, from the outside, appeared to be an indecisive flake:
Then it clicked.
He’d intentionally try different and crazy things, knowing that most wouldn’t work. He didn’t care. He didn’t care and it didn’t matter — we’d end up in places we never would have if we over thought the layout. The question wasn’t “what is the best way?”, but “what are the many ways?”, deferring judgement until the last possible moment. Judgement may feel good, but it has no value. The value is in the outcome.
And the outcome was often solid, stunning designs that were unconventional. Non-obvious solutions. From the outside and to other art directors, it appeared magical. But, from within the process, far less nuanced and intentional.
No Friday App Design Review This Week
I meant to post this yesterday, but there will be no Friday App Design Review this week. Family is visiting us. I’m working on a special post for iOS devs next week, though.
AutoLayout Myths, Table View Performance, and Side-by-Side iPad App Multi-tasking
With the prospect of a new iPhone form factor and/or side-by-side iPad app multi-tasking on the horizon, iOS app designers and developers are likely to face new challenges when building their apps. Since it was introduced, a lot of people have championed AutoLayout as the cure for these challenges. This post is going to debunk that myth. Or more fairly, this post will show the limits of what problems AutoLayout is able to solve.
Multiple Layouts
For the purposes of this post, let’s assume you’re an iOS app developer planning the architecture for an app like Unread. We have to plan for scrollable table views with as many as 20,000 rows. Each row has a dynamic height based on several factors:
- The length of the title, blog name, and article summary.
- The presence or absence of an image thumbnail.
- The user’s chosen font size.
So, given a container with width w, how should we layout our elements?
As the developer, we’ve been handed some design mockups which we’ll use to write code that calculates the size and position of all our elements. Given a container with width w1, our layout might look like this:
The math and logic required to calculate the position of all these interface elements can potentially become very complex. It is this problem that AutoLayout is designed to solve. AutoLayout makes it easier to write and debug code that calculates the layout of a set of interface elements for a given container size.
It’s important to note that you can’t assume that the container width will always be equal to w1. Apps might have to handle at least two possible container widths: portrait and landscape. So what does our layout look like for a second width w2?
This layout is much different from the first one. AutoLayout makes it easier to calculate the correct positions of all these elements. But as the app developer, your problems are much bigger than just calculating a layout for a given container. You also have to deal with extrapolating that calculation across thousands of model objects and many possible containers. This problem is much more difficult and is beyond the scope of AutoLayout.
Cell Heights and Performance
Notice that the second layout above produces a different total height than the first. What are the implications now that your app has two layouts with two different heights?
When a table view is loading, it needs to know how many rows it will display and how tall each individual row will be. For designs that produce dynamic row heights (as the design above does), these metrics can be very expensive to calculate. You don’t want your app to pause for several seconds while calculating these heights. So what are your options?
Use the new estimated row height API. – On first blush this seems like the best answer. The problem is that
estimatedHeightForRowAtIndexPathhas many bugs. I’ve gone into greater detail on them in another blog post, but the short version is that any app feature that requires accuracy (such as tapping the status bar to scroll to the top of a list) simply won’t work with a table view that implements that method. So this is not a good solution.Pre-calculate and cache all row heights. – Using iOS’ ability to perform work in the background, your app can calculate the height of every table view row ahead of time. Then your table view will load “immediately,” without pausing the execution of the main queue.
Pre-calculation is a better solution, if you can pull it off. It’s difficult to do correctly. There are many factors to consider:
- How many layouts must you pre-calculate for? Portrait and Landscape? Are there others? Every new layout multiplies the total amount of pre-calculation that must be performed.
- What if the user changes themes or font sizes while a long-running pre-calculation is underway on a background queue?
- If you’re caching the results of the background calculation, what kinds of events would invalidate that cache? Date changes? Content changes?
- What if a table view will have 20,000 items in a single list? Is it possible to perform all that work on an older device like an iPad 2, even on a background queue? It could take 15 to 30 seconds to do all that work on an older device. Will you then have to re-write your model collections to support paging in new content as needed?
iPad Multi-tasking & Performance
In the example above, your app was already strained to achieve good performance with only two layouts of static widths. If iOS 8 allows iPad apps to enter a multi-tasking mode with dynamic widths, this would exponentially increase the difficulty of achieving good table view performance. Pre-calculation would be practically impossible.
Assuming the estimated row height API is still buggy and pre-calculation is impossible, the only other alternative would be for devs to start over from the beginning with a design plan that doesn’t allow elements with dynamic heights to also have dynamic widths. This would make good performance achievable, but it would defeat the purpose of a flexible app container. It is for this reason that I think if Apple adds iPad app multitasking, it will only be by scaling app containers without changing the underlying logical widths (768 or 1024 points for portrait or landscape respectively).
The Point
The point to remember is this: AutoLayout makes it easier to calculate a single layout for a single container, but it is irrelevant to the challenge of efficiently calculating a large number of layouts for multiple possible containers.