Why stop at the Dock?

If the changes to the Leopard Dock are a good idea, shouldn’t Apple go all the way and do the same thing to the Finder? And then applications, too! Hell, I can totally see these windows flying around with Spaces and Exposé and Core OMFG!

The Finder of the future?

Forget about October, I’m stoked about 10.6! Let’s hope they add more reflections and transparency, too!

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

iPhone scrolling tip

If you’re an iPhone owner, you’ve probably encountered a problem with scrolling. For the most part it’s very intuitive, but there are occasions where you can’t get to what you want. The problem is that there aren’t any traditional scroll bars, so it seems like you are stuck. Even very smart engineers who know a lot about mobile computing are having problems.

Here are a couple of situations I’ve encountered:

  • While editing in a text area with a lot of text. You probably have resorted to using the insertion point to (slowly) reposition the text.
  • On a web page has content displayed using the CSS scroll:auto property. You’re stuck looking at the top of a <div> and can’t get to the lower part of the content.

Fortunately there is a very simple, yet unintuitive, solution for both of these situations. Use two fingers to scroll the content.

Flicking doesn’t work, but it’s better than nothing. I certainly wouldn’t design an interface around this “feature” due to its lack of discoverability—just use it as a workaround to deal with existing sites. And considering that people are submitting bug reports about scrolling not working, it looks like Apple has some work left to do with this “scroll within a scroll” gesture.

Credit for finding this trick goes to Matthew Krivanek on the iPhoneWebDev mailing list. I found his post while looking for solutions to the fixed positioning problem in MobileSafari.

Multi-touch on the desktop

Now that the iPhone has given us all a taste of a multi-touch user interface, I have been hearing many people say how cool it would be to have touch-based input on a new line of desktop displays from Apple.

If you’re one of the people who think that a multi-touch monitor is a good idea, try this little experiment: touch the top and bottom of your display repeatedly for five minutes. Unless you’re able to beat the governor of California in an arm wrestling match, you’ll give up well before that time limit. Now can you imagine using an interface like this for an eight hour work day?

One of the things that people don’t realize about the iPhone is that it works at a low angle (as opposed to the high angle of your desktop or laptop display.) Our bodies are more comfortable and adept at handling repetitive physical tasks when they are performed at these low angles. What works well for the eyes does not work well for the hands.

If you’re old enough to remember a time before CAD systems, you’ll likely remember drafting tables. These tables were adjustable from completely flat (a low angle) to somewhere around 40° (a medium angle.) A drafting table is an environment where it is easy to work with your hands and associated tools for hours on end.

The iPhone’s multi-touch UI works similarly: if you watch people use it, I think you’ll see a lot more people working at waist level than at chest level. The only time you need the interface close to your head is when you’re enjoying those 3 pt fonts in MobileSafari :-)

Of course, Apple could come up with some kind of ergonomic multi-touch desk. Or we could all go out and buy a Microsoft Surface real soon now. However, I’m pretty happy with the recent demise of the glass-based CRT and not looking forward to the added weight that a touch based interface would add to a 30″ LCD monitor.

But even if there was a solution to the ergonomic issues, there would be problems mixing mouse-based applications (with small hit areas) with touch-based inputs (and large hit areas). Touch-based UI is not something you just bolt onto existing applications—it’s something that has to be designed in from the start.

You can already see this mismatch between the mouse-based and touch-based environments. All you need to do is view a web application that is targeted at the iPhone browser. In a desktop environment the controls seem large, but on the phone they are comfortably sized.

Resolution independent interfaces may solve some of the problems with control sizes, but the fact remains that a desktop interface has a much higher information density than a mobile one. A desktop is a multi-tasking environment while a mobile device is typically oriented towards a single task (making a call, finding a restaurant, getting directions, etc.) Don’t assume that the multi-touch you are using in a single task environment, with its lower information density and more focused interface, will be equally successful in a high density, multi-tasking desktop. Take another look at Jeff Han’s amazing demo and realize that he’s only working in one application at a time—what happens when you add a browser, an e-mail client, and some of your other favorite applications to that desktop?

I also find it difficult to believe that any kind of touch-based UI will replace the keyboard anytime soon. For people who are touch typists, you can’t beat the feedback of a key press for common applications like word processing and e-mail. Eventually we’ll have haptic interfaces with simulated feedback which will obviate the need for a separate keyboard.

The bottom line is that we’ve only just begun a journey that will fundamentally change the way we interact with machines. A major part of this change will be evaluating new and better ways to use computers—what has worked well in the past may not work so well in the future. And because of the magnitude of this change, I think there will be an extended period where touch-based, mouse-based and keyboard-based interfaces will need to coexist. If we’re not careful about developing these new interfaces, we’ll end up with something like Victor Frankenstein’s creation: pieced together and frightening.

Update: Tog agrees with me. Make sure to check out the Starfire video for ideas on how horizontal and vertical work surfaces can be integrated. Even though the cultural and technological elements are a bit dated, the human-centered design is still relevant.