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.)

Text

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).

Buttons

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.

Fixed-size buttons

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.

Stretchable buttons

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):
0%, white
49%, white
51%, (0.93, 0.91, 0.95)
100%, (0.90, 0.91, 0.93)
The gradient is linear with an angle of -90°.

Drop shadow:
Color: 100% black, 70% alpha
Distance: 2px
Size/blur: 4px
Angle: 90°

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.

Layout

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.

Peter pointed me to these lovely stock illustrations from Ellen Lupton. I really like the textures and whimsical treatment of subjects.

Q: To what extent has sci-fi (TV, movies, books) influenced your UX work?

A: That’s a great question. I think you can look at science fiction as our collective fantasy about technology. If you want to understand not how people use their computers but how they want to use them, popular sci-fi is the first place you should look.

In the past few years I’ve really moved away from web app design or even traditional desktop app design, favoring touchscreen devices instead. The computers of the future don’t have mice (“Hello computer!”). Rarely do they even have keyboards. We crave ubiquity and personality in our interfaces; something always there, always responsive, controlled as directly and easily as any tangible system. Star Trek predicts all of this, and now more than ever you can see those predictions becoming reality.

Something that I think will be interesting to look for in coming years is the development of the human element in UI. Will we begin to realize our fantasies of the jovial robot butler, or the sweet voice of Majel Barrett-Roddenberry greeting us when we login? Only time will tell!

“I honestly don’t know what selling out is supposed to mean anymore, the term is leveled with such regularity. I was under the impression that it meant that your principles were for sale, that an indeterminate sum had changed hands and now you were under command. … Now it appears to involve infractions of some impossibly austere, orthodox hipster code, complete with constant play-by-play analysis by psychic forum trolls and betrayed fans who gleefully plot the coordinates of your downward trajectory.”

From 2004, but strikingly relevant in the context of the iPad. From Penny Arcade, via Meg.

“Creativity is not design. Creativity has nothing to do with design. Creativity is bound by no laws, rules, or strictures …which is perhaps why it’s so intoxicating. Design, on the other hand, is based entirely on math, psychology, human perception, and a host of rigid rules and laws that can be broken by only a highly skilled few. Those unfamiliar with these laws and rules, and the associated sciences are by no definition designers.”

As usual, thoughtful and informed commentary from Andy Rutledge.

Besides being an amazingly well-executed app, Lose It! is free and has some social motivational features. So if you’re using the app too, add me at ahalsall@gmail.com… it’s always easier with friends!

A beautiful free icon set from P.J. Onori. Available in both PNG and SVG formats.

“When I think about the age ranges of people who fall into the Old World of computing, it is roughly bell-curved with Generation X (hello) approximately in the center. That, to me, is fascinating — Old World users are sandwiched between New World users who are both younger and older than them.”

A great article from Steven Frank about the iPad and the future of computing. Insightful and thought-provoking.

This past week was a crazy one for lots of people in the Mac & iPhone ecosystem, but I’m happy to finally be able to talk about what I’m working on: Inkling, a new platform for delivering interactive educational content to devices like the iPad.

If I can help spare even one student the back-breaking work of carrying 45 pounds’ worth of textbooks around, I’ll consider it a job well done.

While the HIG has a lot of good information, it doesn’t go into the details of implementation, so I’m going to go through the process of how I would design a toolbar icon. I’ve chosen the iWork style because I really like how crisp and clear they are, and I think they are a good model to work towards.

So let’s take a look at the Pages toolbar.

Let’s take a note from Gmail and add a “Labs” button. This imaginary feature would take the user to experimental or even user-made plugins and macros.

Step 1: Pick your metaphor

First we have to think about what kind of metaphor would best represent this feature. The HIG offers the following guideline:

“As a general rule, a toolbar icon that depicts an identifiable, real-world object or recognizable user-interface element gives first-time users a clue to its function and helps experienced users remember it.”

So what makes me think of experiments? A beaker seems like the obvious choice. Anyone with high-school chemistry would know that symbol. But before I draw anything I should do some research. I fire up Google Image Search and Flickr with a search for “beaker.” It looks like I have a couple of choices for the shape of the object.

This is actually the kind I was thinking of, but I think these kind of beakers are generally only used in stock photography. I’ve never seen or used one like it in an actual lab. I got a lot more results for this type:

This is also what I remember from science class. The other beaker style is perhaps a bit more recognizable, but in the interest of realism (and not looking too Weird Science) I decided to go with this one.

Step 2: Figure out your sizes

So you’ll notice that Pages’ icons are very crisp, with 1 pixel outlines at both the large and small sizes. This indicates that the designers created two sets of icons, one for the large size and one for the “use small icons” size. If they had only used one and resized it, the line would not be 1 pixel exactly on both. Whichever one that was resized would have fuzzy lines. If you have the time to do this, it’s a nice way to ensure that your icons will look good no matter what your user chooses (you can also selectively reduce detail/complexity at the smaller size to ease recognition).

I’m going to design my icon for the larger size (32×32) and then size it down as needed for the smaller size. Figure out what the “large” and “small” sizes for your app are and keep these in mind. For a pixel-crisp style like this you’ll want to design at the size the icon will appear.

Step 3: Vector outlines

Open up your drawing program of choice. I prefer Fireworks for this kind of icon because it allows me to work with vectors while zoomed in to look at where the pixels actually fall. Go ahead and trace or draw the basic shape. Keep perspective and lighting (which should be top-down) in mind. The HIG says: “The perspective of a toolbar icon is straight-on, as if it is sitting on a shelf in front of you.”

At this point it’s a good idea to look at the fingerprint of your icon. That’s what I call the silhouette of the shape. Icons with different functions should generally have distinct fingerprints. Check to make sure the shape is recognizable and not too similar to anything it’s going to be adjacent to.

Step 4: Color, detail and shading

Now it’s time to fill in the colors and details. I like to zoom in pretty close for this step, but I keep an eye on the actual-size icon as I work. (In Fireworks you can do this easily by selecting Window > Duplicate Window.)

Be brutal about cutting unnecessary shading and details. Show only what you need to in order for the user to get what the icon represents. In the case of the beaker, I added two embellishments; the bubbles, which indicate that the green goop is “active” (and hopefully expresses something experimental and/or volatile) and the volume markers, which help make the beaker more recognizable.

Don’t be afraid to use bright colors here. As the HIG says, “Making each toolbar icon distinct helps the user associate it with its purpose and locate it quickly. Variations in shape, color, and image all help to differentiate one toolbar icon from another.” Also make sure the colors that should be consistent between the icons are – highlights, shadows and outlines fall into this category.

One more thing that’s actually quite important. Watch your alpha! Make sure that things that should be transparent actually are (like shadows, or in the case of the beaker the glass). I like to work with a couple of different-color backgrounds to switch between as I draw, including one that’s the standard Leopard window color to see what it will look like in production. You have no idea what this icon might end up on top of in the future! (Er, avoiding the obvious dirty joke there.)

Step 5: Flatten and pixel-tweak

Save your file so you have the originals handy if you need to resize the icon, then go ahead and flatten your vector layers.

Time to break out the pencil tool! Start looking for places you can simplify your lines. Be especially ruthless around anti-aliased corners, which will have a mess of pixels you probably don’t need and will make your lines look fuzzy.

This is also where I add in line shading and other small details. You may not see much difference in the big, zoomed in picture, but at actual size the tweaked bitmap (right) looks much cleaner. Especially note the simplification of the spout shape.

So after fiddling with the pixels to my satisfaction, I’ll go ahead and plug it into the toolbar to see how it matches the other icons.

Step 6: Generate other sizes as needed

So I have the large-size icon but I’ll also need a smaller one. The first thing I do is size the icon down and clean up the lines. Then I’ll go over the details and make sure that nothing is lost at the smaller size. I noticed that if the spout was made any smaller, it became difficult to distinguish the shape, so I actually made the top of the beaker identical in both sizes. I also redrew the volume markers to fit better on the smaller icon.

So there you go! It seems like a tedious process, and in some ways it is (depending on your style, you may be able to skip pixel-tweaking), but once you get into the right mindset it’s not so bad. You just want to make sure you’re thinking small and keeping an eye on consistency.