In our last journey down the polishing road, I outlined what Mac polish was:
- Excellent UI design
- Drag-and-drop
- Keyboard access
- Authentic Apple Help (ie. using Help Viewer)
- Other little things that are always overlooked (like setting a table cell editable on insertion)
I gave a few examples of these with Flying Meat Software’s VoodooPad. I highlighted their use of sample data for new users, the benefits of having a short application name in the menu bar and using a subtle registration nag rather than a timed window for your shareware products.
In today’s installment, I want to cover a more narrowed topic: toolbars. Many of the comments on the previous article discussed toolbar icons and what they thought constituted good icon design.
One of the things that sets Mac OS X apart from its Windows counterpart is its conservative use of toolbar icons. In a typical Windows application the user will be bombarded with stacked toolbars filled with small, non-descriptive icons. Rather than focusing on a few key functions that a user may commonly access, Windows applications tend to place all functions in a toolbar. And in the case that one toolbar has too many icons, have no fear: developers like to have several toolbars. I think Microsoft Word 2003 has almost ten toolbars that a user can enable!
In Mac OS X it is a completely different word. Instead of small icons, we have big icons. Below the icons, we also include a short description of what the icon’s function is for the novice user. Mac OS X developers understand that users are not going to need access to all of their application’s functionality in the toolbar. Instead, they choose to include their most commonly used functions in the in the toolbar.
Today let’s analyze one of my most frequently used applications: Panic’s Transmit. I spend a lot of time during the day transferring files from my Mac to a Web server, so I appreciate this application’s easy to use and intuitive interface.
When you first launch the application there are ten functions in the toolbar. Each one is something that many users will tend to use in their everyday work flow: a view menu to switch between list and column, an action menu with several “Finder-like” functions, create a new folder, refresh a folder, etc. The only one that I consider suspect is Synchronize, but I suspect that Panic includes it in the menu bar because it’s one of the big features touted in version 3.
One thing that I think almost all data-driven applications need to include in their toolbar is a search field. Transmit’s search let’s you search your local data or the server’s data depending on where your focus is. Apple has made it incredibly easy for developers to include search in their application thanks to the Search Kit API. If you are storing a lot of data in your application, let your users search it.
To achieve Mac Icon Zen and have a polished application, keep these guidelines in mind:
Hire a professional: You are a developer, not an artist. If you plan to release an application to the public, invest in a good set of icons for your application. There are several great designers out there doing amazing work. Find one, and work with him.
If in the off chance that you are a developer AND an artist, still get a professional icon designer. Spend your time perfecting your applications user experience and functionality. Let someone else worry with the artwork.
Use illustrative imagery: Your icons should help the user understand what their function is. In Transmit, the stop transfer button is a stop sign. The button to open the preview drawer is an image with a magnifying glass over it. You don’t want your user to look at your icon and wonder what it is or what it is used for.
Steal Apple’s Ideas: Don’t necessarily steal Apple’s icons, but steal their general idea. If you have an info panel in your application that is similar to the Finder’s Get Info window, you are probably going to want a blue button with an italicized i in the middle. The user understands the function of that button.
I think this might be one of the areas that Apple and I disagree in terms of their Human Interface Guidelines. They say:
Don’t reuse Mac OS X system icons in your interface; it can be confusing to users to see the same icon used to mean slightly different things in multiple locations.
If you are mimicking the functionality, use their icon. If you are creating a new page in a notebook application, use a pencil and paper for your icon. Even though Mail.app use the same thing to signify creating a new Mail message, I don’t think the user will get confused if they see a similar icon in your application.
Keep It Simple Stupid: When you are designing your icons, make them a one trick pony. Each icon should have a central focus in terms of functionality and design. In the pencil and paper icon I mentioned earlier, the dominant imagery in the icon is the piece of paper. The pencil is complementary. Don’t create an icon with a pencil, paper, pen and eraser to signify that you want to create a new page. Not only will your icon be overly complex, it will also look pretty lousy.
For an example of not so great icon usage, I am going to look at one application: Check Off. Yes, I know it’s my own application, but its icons suck. I admit that Check Off’s user experience isn’t the greatest, and that I need to eat my own dog food. Where can I improve?
Check Off’s toolbar has five functions: add new item, add new group, delete item or group, label and an action menu. The add item button is a plus, which isn’t such a bad thing. I don’t think it fits the design scheme of the other icons though. For creating a new group of items, I am using the icon of a folder. Not only is it not really descriptive of what its function is (when you add a group, it’s just a parent group in an NSOutlineView. Not a folder), but it also doesn’t have any sort of marking of what type of action it is. If it had a plus or something on it, it might be a little bit better, but not perfect. Because of this, it has to go. :-)
The delete icon is acceptable. It’s something a user recognizes and understands. Next to it, however, is a design faux pas. To signify that the user can create a label on their item or group, I am using the color wheel! When a user click it, he probably expects the Mac OS X color palette to open up and let him pick any color he choses. Instead, a menu is displayed listing the five choices he has available. Unacceptable.
Instead of the color wheel, I should create an icon similar to the one in the Finder’s preferences window that is in the shape of a label.
The final icon is a gear that displays a menu with several printing and exporting options. None of these options are available in the Finder’s action menu, so I am somewhat wary of using the gear. This is why developers need to hire professional icon designers to help with these issues.
One thing you will also notice is missing from the toolbar for Check Off is titles under the icons that describe the function of the button. Titles come along for the ride if you are using the NSToolbar class in Cocoa, but since Check Off is a menubar-based application, it doesn’t have such luxuries. Even so, each icon should have a short, descriptive title under it to help the user understand what the function is.
When choosing your verbage, you should almost always start with an action verb: Get, Delete, Create, Send, etc. The user is performing an action, so the first word they should see is is the action’s name. If we were redoing Check Off, it should include the following: Add Item, Add Group, Delete, Label, Action. Once again Action isn’t the greatest choice, but it’s hard to work with a menubar-based application. Returning to our “good example” Transmit’s default set of icons includes several action verbs: New Folder, Synchronize, Disconnect, Stop, Refresh and Preview. Most of this is common sense isn’t it?
Finally, developers need to put some thought into what can go into the toolbar. To avoid being like a Windows application, refrain from having an icon for every single function your application has. Also, don’t include every single function in your default toolbar. Choose five to ten functions (depending on the size of your application) that you think users are most likely to be referencing often. Tuck everything else away that they may want to have in the toolbar. If they want to access it, they can customize the toolbar. That’s why Apple made it that way.
Hopefully you learned something from all of this. In our next installment, I think I will make a case for Apple’s Help Viewer and why developer’s should embrace it.
