Volume Number: 19 (2003)
Issue Number: 4
Column Tag: Mac OS X Migration

Redesigning Right

How we adapted the Transmit interface for Mac OS X

by Cabel Sasser

Mac users are crazy. Not clucking-like-a-chicken-in-the-reference-stacks-of-the-public-library crazy, but the good kind of crazy - the kind that can inspire an intense passion, love, commitment and evangelical fervor for something as dry as a computing platform. And as Mac users, we love our interface in an almost unnatural way - your application could print diamonds and candy from an ordinary bubblejet while whistling Dixie (and I'd like a copy, please), but if your app isn't easy, pretty, and thoroughly Mac-like, it will be dismissed. With the arrival of Mac OS X, the importance of interface has become even more critical - Apple has set the bar for quality UI design even higher.

Thus, if your Mac OS X application at all looks not quite right, you're in trouble. Maybe your default buttons are aligned left, or your status text is still Geneva 9, or your Preferences are only accessible via the "Edit" menu, or the background of your window is filled with a scaled photograph of a beautiful Icelandic mountain goat. No matter what the offense, when a Mac application doesn't follow the Apple Human Interface Guidelines to the letter, people notice, even if they have no idea that there is such as a thing as "Interface Guidelines".

When we took our first stab at a Mac OS X port of our FTP client Transmit (the Carbon-based 1.7b2), we pretty much brought the interface over identically - the good ol' "Bare Minimum" port. We updated the font to Lucida Grande, replaced some old folder icons, spaced things out a little, and added a new 128 x 128 icon, but that was about it. After a few months of getting under Mac OS X's skin, it was clear to us that 1.7b2 wasn't even remotely enough. Mac OS X threw almost everything we knew about Macintosh interface design out the window, but things had improved - now, when we booted in Mac OS 9 things felt odd and cumbersome, no longer the other way around.

So, once we made the decision to rewrite Transmit in Cocoa, we decided we would remodel the entire interface as well: the goal, as with all Panic products, was to make Transmit feel like a part of Mac OS X itself, as if it came straight out of Cupertino.

Two things make Transmit unique among FTP clients. First, the main interface is all-in-one - it not only contains its own built-in local file browser, but also an in-line connection panel for entering server information, all in one window. This unification allows the user to breeze through their FTP session. Secondly, we rely heavily on Finder-like metaphors and behaviors to make our application feel more like an extension to the Finder itself rather than a stand-alone FTP app. For example, you drag and drop to upload and download. You click and wait to rename. You drag to the trash to delete. You drag into a folder to move. As we like to say, "If you can use a Mac, you can use Transmit."

When updating the main interface for Mac OS X, it was important that we maintained a careful balance: adopt the best new design features that Mac OS X has to offer, but don't destroy the essence of our application's identity - don't break what works well, but improve what doesn't. It was a very tough task. Here's the result:

The first thing we added to Transmit 2's interface was a toolbar. You'll notice them in virtually every Mac OS X application, from Mail all the way down to the humble Print Center. Despite seeming gimmicky, we've learned to love toolbars: it's far easier to mouse over to a shiny icon than to navigate through menus when you want to perform an action in a hurry. Additionally, some of your best features can get lost under heaps of cascading menus -- toolbars help new users easily discover all your application has to offer.

So, if your application has a lot of "actions" tucked away in the menus, there's no quicker way to make it feel like a good Mac OS X citizen than to install a toolbar. Here are some things we kept in mind when designing the Transmit 2 toolbar:

• Choose your items carefully. Don't make everything available in your toolbar, only the actions you think the user is likely to access often. If the feature is so obscure that only 5% of your users care, it probably doesn't need to go into the toolbar. For example, we didn't add "Send Raw FTP Command" to the toolbar - it's so hard core, it's best left in the menus.

• Choose your default toolbar set even more carefully. Don't overwhelm the user with a toolbar longer than the Great Wall of China on first launch. In Transmit, we have "Upload" and "Download" buttons that the user can add to the toolbar if they desire, but we don't put them in the toolbar by default - we want the user to discover the "drag and drop" method of uploading and downloading first, since it's far more natural.

• Don't add fundamental application actions to your toolbar. It may seem obvious, but your toolbar should not have a "Quit" button. The same goes for "Preferences", "About", "Help", "Hide", etc. Your application should be already providing a common and consistent place for these typical, every-app actions.

• Try to use the toolbar to simplify your interface. You'll notice we moved the "Cancel" button from our main interface window up into the toolbar - nestled among the other actions, it reduces the clutter in the main interface view, and fits well with other actions.

• Think a bit about your default toolbar's item order. In Transmit's case, the two destructive actions - Cancel and Disconnect - are the black sheep of the toolbar, shunned away on the right and separated with a flexible space to reduce the likelihood of accidental clicks. You'll also notice that a separator sits between the action icons (New Folder, Refresh) and the location icons (Home, Documents), letting the user know that these sets of icons behave slightly differently. Simple things like spacers and separators can do wonders for usability.

With the toolbars set, we started picking and choosing our primary interface elements, carefully considering the usefulness of each and asking ourselves, "Can we do this better?"

In the bottom of the original Transmit window was a "Show More Information" disclosure triangle. When clicked, the window would resize to reveal multiple informational text fields containing data about the active connection. Although it was a fun widget to mindlessly click on while a transfer is running, there was really no reason for "More Information" to be optional - virtually everyone ran Transmit with "Show More Information" open. After all, who wants to choose "I want to know less"? We took the contents of this optional panel and, although we lost a little information in the transition, we managed to roll all of it into a single easy to understand status line in Transmit 2.

We kept the trashcan in the lower-right hand corner of Transmit's interface, but it is still a matter of some contention. Optimally, since Mac OS X offers an always-available trashcan in the Dock, we wanted to encourage users to drag their items to the Dock instead, removing an extra control from our window in the process. However, we found that old-school Transmit users felt very lost and bewildered without their convenient trashcan waiting for them in the corner, and users who had their Dock set to auto-hide were even more confused about how to delete items, since no trashcan was visible to them while using Transmit. In short, we let the trash can stay... for now.

Finally, you might have noticed a path pop-up control, and a parent button, smack dab in the main interface. "Aren't we supposed to 'simplify' these kinds of things by placing such items in the toolbar?", you might be asking. Well, technically, you're right. After all, the Finder has both a back button and a path pop-up in its toolbar, and they work just fine.

The problem here, however, is that Transmit has two separate file views in one window to consider: local and remote. If the "parent" button was in the toolbar, the user would first have to click the side they wanted to change -- say, "your stuff" -- and then, with a side selected, they'd be able to click the parent button. By having two sets of these controls, one on each side, the user can immediately affect the one side they wish to affect -- we eliminate a selection step in a frequently used action.

There's one very important thing Transmit's interface isn't: metal. With the introduction of Jaguar, Apple provided a simple checkbox in Interface Builder that still to this day gives me night tremors and cold sweats: "Textured Window". This innocent looking box makes your application all shiny and metal, very much like iTunes, iPhoto, and, somewhat questionably, Address Book.

In the Aqua Human Interface Guidelines, Apple provides a very logical description of when the metal look is acceptable. You should read it if you're curious, they've certainly put some good thought into it. But I will personally summarize it thusly: "Your application should use the textured appearance [...] never."

In all seriousness, no Mac user wants a patchwork-quilt of a desktop, with some windows ice-lined and others molten-forged. Unless your application fits the acceptable guidelines to the letter, I say don't check the box. I know it looks cool and has a high novelty value, but if you ship a word-processor with the metal texture, we will come to your house and hurt you. Seriously.

Ah, preferences - gateway for the everyday tweaker, long-standing domain of the power-user, and defender of all-that-can-be-changed. In migrating an application from Mac OS 9 to Mac OS X, you'll likely spend a great deal of time re-creating your preferences, since they're very control and layout heavy. The Mac OS 9 Human Interface Guidelines had a very strict set of rules for typical window layout (lots of group boxes, left-justified controls, tabs galore, and the like), and all of it is irrelevant in Mac OS X.

When it comes to re-designing your preferences, I say: start from scratch! Don't load up your old resources and excitedly start re-arranging and re-sizing them. Instead, open up Text Edit, and write out a good old-fashioned simple list of each of your Preferences. Then, walk through the list, and consider each preference carefully -- look for ways to combine preferences, to clarify controls, or weed out preferences that are so obscure that they're probably not worth the clutter. Finally, once your list is done, fire up Interface Builder, and start building a new Preferences window from scratch, working only from your list. Your preferences will thank you for it! (Although that'd be a little creepy...)

Here's some other advice we took when bringing Transmit's preferences up to code:

• Think centered. Mac OS 9 dialogs and windows were traditionally left justified, but in Mac OS X, the world is centered - even the drop shadows cast down from top and center. That doesn't mean each item should be individually centered, though -- instead, group your related controls and captions, and then center that entire group. See our "Downloads:" group for an example.

• Keep a close eye on fonts. As of this writing, Lucida Grande reigns supreme, almost always in 12 point. And take heed: there should be no Geneva, Charcoal or, god forbid, Chicago!

• Let your window breathe. Mac OS X windows and dialogs are much more spaced-out than their Mac OS 9 counterparts, and the result is a much more airy, much less totallysupercrampacked experience. Now that the minimum resolution supported by Mac OS X is 800 x 600, there's no reason to jam all of your preferences into a 100 x 200 window.

• Get rid of group boxes. They're oh-so-1997. Place a static text heading to the left and top of a series of controls if you wish to group them visually. Or, for bigger groups, use a static text with a horizontal rule bottom-justified to the right of it, then place the controls (and sub-groups) underneath.

• Remove your tabs. True Mac OS X preferences should now use a toolbar-like control at the top of the window, and the window should resize appropriately when sections are accessed.

• Prune. Like I said, we took this re-writing opportunity as a chance to re-consider every preference we had. "How many people use this?" and "Is this really that important?" should be questions you ask frequently. If you remove a control that 4 people use, sure, you'll probably hear from those 4 people (it might be the same 4 people we always hear from!), but hundreds of other people might just be more likely to find what they're looking for now that the obscure option has gone away. I know it's counter-intuitive to take something out of your application, but be brave! And if you need moral support, call us.

Follow these basic rules - and keep the HIG on your nightstand for a while - and you'll be well on your way to a shiny, Mac OS X-like preferences experience in no time.

In the land of Mac OS X, icons are king. Really. There's no greater investment you can make for your application than going out, finding a quality icon designer, and making an original set of icons. Cobbling together your own icons from other applications, snagging icons from the Finder, or re-using freeware icon sets is almost always a bad idea - this usually lends to situations such as: "Well, I can't really find an icon for 'Reset Cache' anywhere, so I'll use this cool icon of a rubber duck in a top hat wearing a delightful little monocle, since people love rubber ducks! And monocles! Right? Besides, help tags were invented for a reason, right?"

In the case of Transmit, we went straight to The Iconfactory, who we've worked with since 1997 - we're always amazed by their creativity and quality. They're not alone, though - there are many talented Mac OS X-specializing icon artists, some who may even work for free (although, if you work for Microsoft, I suspect they might charge you.)

Your best bet is to Google for something like "Mac OS X Icons" or search through the news links at The Iconfactory, browse the free icons out there, find an artist whose style you like, and write him or her an e-mail explaining that you need their talents! Make sure the artist is equally good at both the tough-to-clarify 32 x 32 toolbar icons and the very-large and photorealistic 128 x 128 application icons. Also, make sure you can clearly explain your exact icon needs. Good direction is crucial! And when it comes down to price (always tricky), I suggest simply asking the author what they want in return for the work. Icon people are good people, as long as you're a good person in return. (I guess that's true for many things in life.)

When working on the Transmit 2 toolbar icons, we kept coming back to the importance of consistency - the icons needed to resonate with each other, in order for the application to feel cohesive and whole. At the same time, we wanted the icons to feel Finder-like. So, we had to strike a delicate balance between our own style and the Finder's style. The complete results are as follows:

As you can (hopefully) see, each icon shares the same language: badges are consistently white shapes with a soft shadow, non-real-world graphics are rendered in graphite, each bookmark-related icon shares the same basic book, etc. As a whole, the Transmit toolbar icons feel like a family, and help the application gel.

Don't be afraid to continually revise your icons, either, as your application winds its way through development. Our toolbar icons went through many revisions before we felt fully comfortable with them. It's an inexact science - my only advice is to trust your intuition and tweak until the icons just feel right. If you know for a fact you have no design intuition, grab the pickiest Mac-using friend you know and run everything by them. (As for our many stabs at the "refresh" icon, pictured below, I'd like to thank Dave at Iconfactory for being so patient when I wrote him notes like "I don't know... that one's a little bit too wispy." Great, Cabel. Thanks.)

There was one snag during the creation of our toolbar icons that is worth mentioning. Since many features in Transmit mirror those in the Finder, our instinct was to make our toolbar icons as Apple-like as possible. We even considered using the exact same icons that the Finder uses for things such as "New Folder". However, as we began to investigate Apple's icon language, we noticed some inconsistencies, and eventually came to the conclusion that it would be smarter to invent our own, Apple-like style, but with a Panic twist.

Take, for example, icon badges - little icons that combine with other icons to create new icons. Phew! Here are three of Apple's:

As you can see, each icon has a different take on badges - one is pseudo-3D, one is centered flat white, one is white with a border, etc. With so many styles present in Apple's work, we struggled to pick which one was "correct" for our own badges. It was a riddle with no answer, as even Apple is still refining and perfecting their style -- there is no "bible" just yet. So, we wound up creating our own New Folder icon, based on Apple's, but fitting within our own Transmit style. It's a bit smaller, and uses a badge style consistent with all of our other icons. We think it's a good balance.

I've always believed that an application icon needs to have this unspoken attractiveness to it that just makes you want to uncontrollably double click it even when you don't have to. I'm not sure if this is vestigial stimulus from early childhood or some kind of terrible comment on society as a whole, but I think the more attractive, cute, and polished an icon is, the more likely it will gain a permanent place in a user's dock, and thus be a part of their everyday toolkit. Admittedly, I've put some ugly icons in my dock in the past, but only out of necessity - once a more attractive icon came along, I've almost always dumped the old one and immediately upgraded to the new, beautiful one. Okay, now this is just sounds weirdly personal.

The very first Transmit icon used the standard limited color palette for Mac OS 7.5 icons, and was basically a "Copland-style" three-dimensional truck. The next revision of the icon got a whole lot of shading and a little bit of an alpha-channel shadow, thanks to the 32-bit icon capabilities of Mac OS 8. Once Mac OS X came out, the truck grew to 128 x 128 - but it was one of The Iconfactory's first Mac OS X icons, so it was really more of a "scaled-up" 32 x 32 illustrative truck, rather than a photorealistic, Mac OS X-style icon. Finally, the Transmit 2 icon underwent the ultimate upgrade -- a true piece of icon art, even down to the headlights and tire treads, that fits perfectly in Mac OS X.

When designing your application icon, don't forget to spend a few days doing what we call "The Dock Test". That's when you drag your new icon into your dock and.. well.. leave it there for a while! Just live with it. Does it fit in? Does it stand out? How does it look next to everything else? The Dock Test is terribly helpful in deciding if your icon is ready to go.

Finally, in case you've ever wondered "why a truck?" Well, Transmit was originally called Transit! It made a lot more sense back then, really, before the lawyers got involved.

The HIG, impressive tome that it is, can't always give you all the answers. In our case, there was at least one place where we "flew solo", creating a control that isn't really covered in the HIG or used anywhere else in Mac OS X.

The favorites menu in Transmit sits in the corner of the connection panel, containing a list of the user's favorite servers. In Transmit 2, it's a pop-up menu with no caption to the left, and the pop-up menu itself doesn't display any text - just an icon. Yes, it's not something you see often, and those are certainly two violated rules.

But, in our defense, we think this custom control works pretty well by combining two global concepts. First, a pop-up menu, distinguished with the down-arrow, obviously contains a list of items that are revealed when clicked. Second, a simplified bookmark icon, used throughout our application and nearly universal in its readability, indicates favorites or bookmarks. We think that anyone looking at this control will know that it's a menu that contains favorites. Or, at least, we hope so.

(A note about the design of the bookmark icon itself: we modeled its gray, flat appearance off the "utility buttons" Apple has introduced in applications like iPhoto. But, as a twist, we shaded the icon with glossy white highlights to match Mac OS X 10.2's pop-up menu itself. You won't find this kind of stuff anywhere in the HIG, but darned if it doesn't feel right!)

Before you go whipping up some kind of crazy circular scrollbar, remember: you should rarely, if ever, find yourself rolling your own solution, and if you find yourself inventing your own controls more often than using Apple's, you're either doing something very wrong, or working a new version of Kai's Power Tools.

Here at Panic we've always believed that a truly great application is 50% engineering and 50% design - with any luck, you're now ready to tackle that last 50% and bring every corner of your application up to spec. With a little interface intuition, intense attention to detail, and good old-fashioned Interface Buildin', you can make your application shine as brightly as it deserves to under Mac OS X. It's worth the effort, and believe me - your crazy users will thank you!

http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/index.html

Cabel Sasser is the other co-founder of Panic Inc., and is Panic's primary right brain, responsible for design in all its many forms. He also buys all the weird new food products for the guys in the office to try out (Funky Fries, anyone?). Feel free to send Cabel any e-mail at cabel@panic.com.