Creating UI assets for the iPhone OS
Posted on 12 April, 2010 at 5:35pm
So I wrote this up recently for internal use at Inkling, and thought it might serve as a good general purpose guide for iPhone/iPad UI designers who work in tandem with developers. Hopefully it will help you work more efficiently and have more harmonious, fruitful partnerships!
Some general guidelines
- For UI elements, use 24-bit PNGs with a transparent background.
- Use alpha transparency, not index transparency. Be careful to not use fancy blending modes on top of transparency in the source file – anything beyond basic alpha transparency won’t be respected in a flattened PNG.
- Include any drop shadows or highlight effects in the exported image. Keep in mind the lighting source should always be the top center of the screen.
- Keep a source file around (i.e. PSD) for each asset you export, so you can make changes to it in the future without messing up the dimensions or alignment of the image.
- Use Photoshop or Fireworks to create graphics for production. AI is resolution independent, so it is much harder to control pixel-level details and you will often end up with blurry lines when you rasterize the image.
- If you find that antialiased lines look fuzzy in your flatted PNG, you may need to whip out the pencil tool and clean it up by hand.
- When providing colors, use RGB values. Your developer may want the values in percentage format; to get this, use the color picker to get the numerical value and divide it by 255. If it needs to be partially transparent, specify an alpha value. (20% alpha means the same thing as 80% opacity.)
Any text labels in the UI are implemented directly in Cocoa, so you should provide detailed specifications for how the text should appear. Most labels in the UI should be Helvetica, the system font, but you can specify any font that is included on the device.
You should also specify whether overflow text should be truncated (as with button/titles in the default UI) or wrapped (as with an expanding content area).
What you should provide: Font name, size, and color, as well as parameters for any shadow effect that should be rendered (shadow color and x,y offset in pixels).
A "button" is pretty much anything that is tappable, and it can have different visual states depending on the context. You need to take all of these states into consideration when building custom buttons.
Your average button has three states you should provide to your developer:
• Normal: The button is active and can be tapped.
• Disabled: The button is inactive and cannot be tapped.
• Highlighted: The button is currently being touched.
And there is a fourth state that may be required for buttons that can be toggled, or buttons which are part of segmented controls:
• Selected: The button has been toggled on can be tapped to return it to the normal (off) state.
It is important to ensure that the assets you provide for these states are identical except for the differences in visual styles. You should also specify the appearance of the text label (if present) for each state.
When delivering assets for production, you have a few implementation options, depending on the properties of the button.
Some buttons are always going to be a predictable size. Generally speaking, this applies to buttons that rely on iconographic imagery and therefore don’t contain any text. Buttons that contain text, even when presented at a fixed width in the UI, should always be stretchable in at least the x-dimension to accomodate changes to the label or localization.
For a fixed-size button, you can export the asset as-is. When you have a number of fixed-size buttons that share a single context, it is often easier for the developer to achieve the proper alignment if you choose a universal height or width for all buttons in that context.
What you need to provide: Just the image at the proper dimensions to be fitted into the UI, along with any applicable visual states.
In Cocoa, it’s possible to take a button image and do automatic slicing to make it stretchable in either the x-dimension, y-dimension, or both. This is really nice for us because we don’t have to slice them up ourselves. Yay! It does have some limitations, though, and these are important to remember.
The way it works is that it takes the button image, then uses a pixel value for cap size to slice the image in code. The caps are then set aside, and the inner pixels are repeated in whichever direction is specified.
If you want your button to stretch in both directions, it must be a flat color or tiling pattern (basically, it needs to repeat elegantly in either direction). A gradient will not stretch properly. In the example above, the button can only stretch in the x-dimension and must have a fixed height. For most UI buttons this is perfectly acceptable.
Generally speaking, it’s best to provide UI assets in the smallest form possible, so try to reduce your image to include only the caps and whatever needs to repeat in-between.
What you need to provide: The button image for all applicable visual states and the cap size in pixels for each direction you need the button to expand in. In the example above, the cap size is 8px and it expands horizontally.
Drawing the button in code
So what do you do when you want a button that expands in all directions and has a gradient or some visual style that defies stretching? Well, chances are good the button could be replicated in code, although this can be significantly more work for the developer, is harder to modify, and sometimes incurs a penalty to performance. Always check with the developer before embarking into this territory.
This button is a good candidate for drawing in code thanks to that fancy highlight effect and its need to support arbitrary amounts of content. In this case, what you need to provide to the developer is not images but a set of parameters. Generally speaking, Cocoa can draw most of the things you can draw in Photoshop: shapes, gradients, shadows, even blending modes.
Here’s how you would describe the normal state of this button to a developer. You can access all of these parameters in Photoshop.
Shape: Rounded rectangle with a corner radius of 9px
Gradient (stop, rgb):
51%, (0.93, 0.91, 0.95)
100%, (0.90, 0.91, 0.93)
The gradient is linear with an angle of -90°.
Color: 100% black, 70% alpha
Inner padding: 15px on all sides. The text should be 16px bold and centered vertically.
Here’s a nice tutorial on creating a glossy button in code. It should give you a sense of how the process works and what’s possible.
What you need to provide: Detailed specifications with all the color, style, and shape information needed to recreate the button. Don’t forget to also provide specs for all relevant visual states.
When laying out a UI, you are usually dealing with content areas that are either of a fixed size and position, or variable size and position relative to contents. It can be very helpful to developers to describe these parameters as explicitly as you can, while also providing guidance on how to handle elements that reflow, expand, or change size & position.
What you need to provide: Pixel-level specifications about where UI elements (or blocks of elements) should go, as well as guidance for how to handle elements that move or change dimensions.
Masks & compositing
You can use any solid black shape on a transparent background to create a mask that can be applied in code. The mask can also use partial transparency, so you can actually achieve sophisticated effects this way if you want to get creative.
Generally speaking, it’s most useful for fitting dynamic content into a more general UI asset. For example, you could take an image of a CD’s album art and make it appear to be part of a prerendered CD case by using an image mask of the proper shape and size.
You should talk to your developer about how to implement artwork like this before you create your assets. Sometimes masking and compositing is the right approach, but sometimes it can come with a performance hit. Some cases would be better handled by generating the artwork in code and caching it for reuse.
What you need to provide: For masks, provide a black shape on a transparent background. For compositing, provide all the graphics that you need to layer together to create the object. Make sure they all have the same dimensions and are already aligned properly, as with the fixed-size buttons described at the beginning of this document.
Get creative and work together!
This really just scratches the surface, and if you take the time to learn about how graphics are implemented on the platform you’ll discover lots of creative ways to build a UI. I highly recommend sitting down with your dev (or someone familiar with the features of the platform) and talking through your ideas. You may discover options you hadn’t considered, and together you may come up with a plan of attack that is more beautiful, responsive and fast than it would be if you never put your heads together.
No related posts.