Does your app icon suck?

Yeah, I see a lot of icons in my business. I often get asked what makes for a successful desktop icon. And I’ve answered many times—but never in public. This essay also gives me a chance to write about something other than the iPhone :-)

Let me begin with this disclaimer: this discussion is directed at independent software (”indie”) developers. Our corporate clients, like Adobe, Apple and Microsoft, have very different needs and objectives when dealing with iconography for software suites. Please also remember that I’m a software developer by trade, not a designer (although, I’m not completely clueless when it comes to the arts.) This discussion will cover a lot of things designers already know—and things that developers need to know.

Before I talk about the specifics of icon design, it’s important to realize what your application icon represents. It’s your brand: it shows up in the Dock, on your download page, and in product reviews. People may remember your app icon more than they remember your product name. A strong icon design results in an equally strong brand.

What do you think of when I describe an icon that’s a truck sporting a yellow cab with a purple cargo?

That’s Transmit’s brand. It’s so good, other people want to use it.

Would you believe that people actually thank us for making that little truck icon? It’s true—an icon can have a huge impact on people’s perception of your product. If your app is a joy to look at in the Dock, people will be in the right frame of mind when launching the application.

This effect of good design is contagious, too. The Twitterrific icon is an example; the strength of the icon has carried over into other applications either directly or indirectly. People associate a blue bird with Twitter now—at the time we created the application, Twitter’s only brand was the word mark.

It’s also important for your design to be unique. The world doesn’t need another globe icon for a network application. Be careful about using the “document and tool on the desktop” metaphor; it may be recommended by the HIG, but it also means you’re playing on a field crowded with other similar designs.

Of course there is still room for creativity when working with familiar metaphors. If you look at Bryan Bell’s icon for NetNewsWire or Jon Hicks’ work for Firefox, you’ll see that the globe is a secondary element in the design. The complementary colors of the satellite and the fox are what draw your eye and make the image memorable.

One of the most unique icons to come around in a long time it the Coda icon. (I feel fine making that claim because I had no substantive involvement in its design—I’m just happy to have it in my Dock.)

There’s a interesting story that went along with this icon’s creation. This story illustrates how much thinking and rethinking goes into a successful design. It also shows that you shouldn’t work in a vacuum when dealing with something as important as defining your brand.

The early concepts for Coda’s app icon was a forklift; a natural extension to the Panic truck. But the release of a similar application that used this metaphor forced us to consider a new direction. In retrospect, that was one of the best things that happened in the project.

So without a forklift to work with, some more brainstorming ensued. Gedeon Maheux came up with the idea of using a leaf or seedling to represent the continual care and growth that a web application typically receives. Dave Brasgalla started developing this concept with a series of hand drawn sketches and simple vector artwork.

Coda concept artworkOriginal concept sketch for Coda

Cabel Sasser, who did the UI design for Coda, liked the concept sketch, but was hesitant about its use in their product. Ged convinced him it was a good idea because of its uniqueness.

Once we got the go ahead from Cabel, David Lanham started developing the icon. As with any design job, there were multiple revisions before everyone was happy. I first saw the icon toward its final revision (before the addition of trichomes and the rearrangement of water droplets.) Like Cabel, I had doubts about the icon’s simplicity.

Coda icon before final releaseCoda icon before its final release

The deciding factor was that it stood out on product website and in a list of other icons. Its simplicity and uniqueness was its greatest strength.

Comp of Coda icon on Panic websiteComposition showing how Coda icon would show up on Panic website

And the punchline for this story: a conversation with Cabel at this year’s WWDC revealed that he and Steven Frank originally had the idea of doing a leaf to represent their web studio application. But they discounted it and never mentioned it anyone. I guess that means that great minds really do think alike :-)

Note: There’s more that I’d like to show about this project, but I don’t want to steal any thunder from Cabel and his presentation at C4. Hopefully this post will whet your appetite as much as a link to Gina’s. It would also be safe to assume that this post will be updated sometime after our little get together in Chicago :-)

So what should you look for when developing your own application icon? It’s really pretty simple when you get down to it—the key elements are:

  • Color
  • Shape

When dealing with these elements, strive for simplicity and clarity. How the icon looks at 16×16 pixels is just as important as its representation at 512×512. Complexity in the larger sizes will not work well at the smaller sizes. A vibrant color that looks great at 16×16 might be overpowering at 512×512.

To get an idea of how these two elements are important, let’s do a little experiment. (Regular readers will find that I love doing “real world” tests to back up my statements.)

Open your Applications folder and set the list view to the smallest size (16×16.) Now scroll down through the list and pick out which icons jump out at you. Now ask yourself why—the answer is color and/or shape.

Here are the applications that caught my interest, their strongest design element, and some thoughts I have about each one:

Adium (color & shape)
A green duck makes a strong statement, although I think making the color a preference is taking customization a bit too far.

Firefox (color)
Circular icons tend to be overused, but the fox’s “C” shape overcomes this.

GarageBand (shape)
A unique shape that draws the attention of people who like music (like me.)

NetNewsWire (color)
The complementary colors in this icon are particularly strong and make for a very dynamic icon.

PhotoBooth (color)
Unique in that it successfully uses a gradient—ranges of color typically get lost in smaller sizes.

Skype (color & shape)
One of the few icons that incorporates the word mark clearly and successfully.

Parallels (color & shape)
I have no idea what the shape represents, but it’s unique and clearly represents the brand. Without the gold coloring, the shape would be reminiscent of the brand used by DC Shoes.

QuickTime (shape & color)
A clever icon that uses the letter “Q” to represent the brand. It’s been around a long time and still looks good—you can’t say that about most applications that were released in the early 1990’s.

Hopefully this essay has given you some basic insights on how to approach the design (or redesign) of your application’s icon. There’s no way that a fantastic icon can overcome crappy code, but something nice to look at will definitely affect people’s perception of your hard work. And be sure to give brand development as much care and thought as the lines of source code in your project: it’s not something that you just slap on your application before you ship.

One line of code

Want to make your site look better on the iPhone with one line of HTML?

It’s easy—just add a <meta> tag that lets the iPhone know how wide to display the initial page. I added the following code to the <head> in my template yesterday:

<meta name="viewport" content="width=808" />

Every browser besides MobileSafari will ignore this information. But it does something very important on the iPhone: it optimizes the viewport for your content.

By default, the iPhone uses a viewport of 980 pixels—a value chosen to maximize compatibility with a broad range of web sites. When you specify the viewport width explicitly, you will eliminate any empty space between that 980 pixels and the width of your <body> element.

On this site the <body> is 808 pixels wide, so there were 172 pixels of content-free space being used to display the page. On a screen that’s 320 pixels wide, that’s significant. So much so, that by making this simple change, the headings on my blog posts are now readable on first load of the page (previously, the text was too small.)

As always, a picture is worth a thousand words. Here are the changes that could be made on a couple of my favorite web sites:

Zeldman

Looking at Jeffrey’s CSS file, I see:

html {
	min-width: 742px;
	}

So his one line of code would be:

<meta name="viewport" content="width=742" />

That’s all folks!

Daring Fireball

Likewise, Gruber had specified this CSS:

body {
	...
	min-width: 760px;
	}

Which would mean this addition to the <head>:

<meta name="viewport" content="width=760" />

But there’s a problem…

MobileSafari uses a heuristic to adjust the viewport based on the width and aspect ratio of the page. And since Gruber is a man of many words, the page is long and the initial scale for the viewport isn’t optimal. So he could use this instead:

<meta name="viewport" content="width=760, initial-scale=0.4" />

But his problems aren’t over yet—there’s still an issue with usability. You can double-tap to zoom in to read an article—and when you double-tap to zoom back out, you’re using the suboptimal scale factor again. This is easy to work around by specifying a minimum scaling factor:

<meta name="viewport" content="width=760, initial-scale=0.4, minimum-scale=0.4" />

And it’s still just one line of code!

Are you wondering how I came up with that magic scaling factor of 0.4? I used a tried and true development practice: trial and error. While using this sophisticated technique, make sure to close the window in MobileSafari (by clicking on the red X icon.) The viewport scale is not modified when you refresh the page, so you’ll only see changes when starting on a new page.

Hopefully, Jeffrey and John will read this post and make the changes to their sites—I like reading them on the iPhone :-)

Update: WordPress is turning the double quotes in the examples above into smart quotes. You’ll want to convert them before adding them to your template. And for more information on viewports, check the Apple iPhone developer page (you must click on “Optimizing for Page Readability” to view it.)

Quartz and Javascript, sitting in a tree…

Even if everything isn’t copacetic in the land of “sweet”, at least Javascript and Quartz are getting along.

Thanks to Apple’s contribution to the WHATWG’s HTML 5 specification, it’s pretty easy to use Quartz graphics technology in an iPhone application. Together with MobileSafari’s event handling, you can start to do some fairly sophisticated drawing using a <canvas> element on the iPhone.

Here’s a sample application that draws and updates a graphic based on user input: canvas_test.html

(Make sure to resize your browser to have a 360 pixel height if you’re running on a desktop instead of the iPhone. And don’t be a fool: view the source.)

A few things to note:

  • The Javascript timer events only fire if the page is frontmost in Safari. Don’t make assumptions about when stuff will happen based upon your previous AJAX experience.
  • The minimum interval for the timer is much higher on the iPhone than a typical desktop browser. Change the setTimeout() parameter from 1000 to 10 milliseconds, and you’ll see that it’s not fast enough for serious gaming. You might also want to look at CPU usage on the desktop as a clue to why the iPhone developers chose to limit the timer interval.
  • It appears that MobileSafari isn’t very fast at recognizing mouse (multi-touch) events. Try pressing the screen quickly in different locations: you’ll see that many of the events are not captured.
  • I’ve said it before, and I’ll say it again. The finger is a very imprecise pointing instrument. Try to get the graphic centered at 100, 100 and you’ll see what I mean.

And if you had any doubts about the WHATWG being a good idea: this example works just fine in Firefox, Camino and Opera. I’ll let you guess how well it works in Internet Explorer…

Update: I built a graphing calculator using the concepts presented in this essay. Try launching the application on your desktop and iPhone: there’s quite a performance difference between the two environments. To understand the differences, I ran some benchmarks.

Bittersweet

Take a look at every application on the iPhone: what do they have in common?

The answer is a navigation bar at the top and a toolbar at the bottom. The navigation bar at the top gives the user a well known location for “backing up”, starting an editing session, and canceling operations. The toolbar provides a way to switch modes, change views or other operations with the dataset at hand.

Both of these key interface elements, navigation and tools, are in fixed locations on the iPhone screen. If you’re trying to develop a “sweet” web application for this device, you’ll quickly find that you can’t follow these standard conventions. That’s because there is no fixed positioning in Safari for the iPhone. Bittersweet, indeed.

The position of the navigation and toolbar items is very important since they allow the interface designer to avoid the “finger shadow“. When you are navigating, your finger can obscure content since it’s going to change anyway. Locating a toolbar at the bottom of the screen allows you to work with data without the risk of hiding it.

Some might argue that there’s no way to have fixed positioning on the iPhone since it’s based on view ports rather than scrolling. But this argument is quickly dismissed when you consider the <meta name=”viewport”> configuration supported by Safari on the iPhone:

<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>

This allows you to specify the exact size of the viewport your web application is using. It can also prevent or limit the scaling of the viewport, so you’re guaranteed to be working in a consistent coordinate system. Most iPhone web applications I have looked at are optimized using this feature.

The lack of fixed positioning in the browser also makes it clear that everything else on the iPhone is not a web app because the elements at the top and bottom of the screen don’t move. So much for Apple eating their own dog food. Instead, we end up with a dog shit sandwich.

(Note: These applications may well be using WebKit within Cocoa views to facilitate the rendering of content, but the layout of the views on screen is not done with HTML.)

So let’s look at how this affects usability. As an example, I’ll take a look at PocketTweets—a recently released web client for Twitter. A beautiful application that’s marred by the limitation mentioned above.

When viewing a page of tweets (posts) you will quickly find yourself scrolling like crazy on your iPhone. Switching a view requires that you scroll to the bottom of a long page, often causing Safari to render portions of the page just so you can get to the buttons. Obviously, these important buttons should be located in a fixed <div>.

This limitation with fixed elements also affects the amazing work done by Joe Hewitt. Take a look at the example code on the iPhone and you’ll notice that the navigation bar scrolls off the screen when there are more than nine items in the list (e.g. the song titles.) A fixed element would solve this problem.

For those readers who don’t yet have an iPhone, here’s an example that demonstrates how the fixed element should work, and how it’s broken on the iPhone: not_fixed.html When you are testing in Safari 3, you’ll need to resize the window so that the content area is 360 pixels high. When you switch to “absolute mode” you’ll have the same experience as on the iPhone.

Finally, it’s interesting to note that this bug implies that Safari on the iPhone uses a different rendering engine than Safari 3. There’s nothing else like it, even Safari 2. Obviously, this is a disappointment for Mac and Windows developers who were hoping to use a desktop browser as a proxy for iPhone development.

If you have an ADC account, I’d suggest that you submit a bug report so that the iPhone team realizes the importance of this bug. Please reference Bug ID# 5325294.

Postscript: While writing this essay, it became quite cumbersome to use “Safari on the iPhone”. Next time, I’ll use iSafari” even though it’s not very descriptiveMobileSafari“.

Update: Apple reports that this is a known issue, please refer to Bug ID# 5327029.

The HIG still matters, even with special effects

Summary

Changes to the Dock in Leopard do not follow the Human Interface Guidelines

Steps to Reproduce

  1. Set desktop background to a light and solid color to make the shadows appear more clearly. In the examples, I used Solid Mint.
  2. Make sure Preview and TextEdit are displayed in the Dock. Additionally, you can download and launch Transmit as another example.
  3. Look at the Dock.

Expected Results

The Human Interface Guidelines contain three salient points:

  • Application icons look like they are sitting on a desk in front of you.
  • Utility icons are depicted as if they were on a shelf in front of you. Flat objects appear as if there were a wall behind them with an appropriate shadow behind the object.
  • Perspective and shadows are the most important components of making good Aqua icons. Use a single light source with the light coming from above the icon.

Reference: Icon Perspectives and Materials and Tips for Designing Aqua Icons

Based on this information, you’d expect the Dock to use either the desk or shelf perspectives. You would also expect a single light source to be used.

Actual Results

The floor displayed on the Dock does not use the perspective of the desk in front of you, nor does it appear as a shelf. Because there’s a difference between the floor angles and the traditional desktop icon angles, many icons look wrong.

An example is the Trash, which has a slight tilt forward. The Transmit truck also looks like its pirouetting on the front-left tire.

HIG AngleFigure 1. Angle defined by Human Interface Guidelines

Leopard AngleFigure 2. Angle defined by Leopard Dock

Whoops!Figure 3. Whoops!

Also, the shadows displayed in the Dock are coming from three separate light sources:

  • The traditional icon shadow, where the light source is above the icon (traditionally from the viewer’s left-hand side.)
  • A new dynamically generated shadow which uses a light source in the top-middle of the screen.
  • Another dynamically generated shadow which uses a light source in the lower-middle part of the screen.

The dynamically generated shadows often conflict with the shadow added by the icon artist.

As an example, look at the loupe in the Preview icon or the halo on the Trash icon. The shadow underneath the Transmit truck is another example.

Dock ShadowsFigure 4. How many light sources do you need?

Another inconsistency is that the “built-in” shadow is shown in the reflection—the dynamic shadows are not.

Finally, the shadows make no sense at all when the Dock is placed on the left or right side of the screen. The shadows below the icon end up floating out in space because they have no surface to be cast upon.

Regression

Previous versions of the Dock used a shelf perspective and did not have dynamically generated shadows, so this was not an issue.

Hundreds of designers have been producing icons for tens of thousands of applications by following the Human Interface Guidelines. Changes to the Dock should respect these guidelines since changing existing artwork is not an option on such a large scale.

If you’re a developer or designer with an ADC account, you might want to let Apple know if this will be a problem for your applications. Reference Radar Bug ID# 5301211.

Update: It’s good to know that there is at least one other person who thinks this is a problem. This bug report is a duplicate of Bug ID# 5176881.

Update: More proof that perspective in the new three dimensional Dock is not well thought out: Physics still matter, even with special effects.

Update: I wouldn’t have written this bug report if the Dock in Leopard looked like this.

Update: Bet you didn’t know that the Dock also defies the laws of gravity.