Designing a Great UI the Aqua Way
Pages: 1, 2
Deity is in the details
Little details are a big deal, so take time to consider them. Some items seem trivial, but they can add up to a major issue that will turn a user away from your application. A good example of a small detail is when developers place buttons in illogical locations. An example would be this actual application.

When you initially launch this program, you fill out a number of configuration windows. On more than one occasion, I’ve hit the Cancel button accidentally because I move my mouse to where the Next button would logically be. I then have to go through the entire configuration again.
Toolbar hoedown
There is nothing worse than opening an application that presents you with a 8” x 8” toolbar and hundreds of microscopic icons waiting for you to peruse their help tags. Resist the desire to give everything a default place on the toolbar. When the user buys your application, it becomes their toolbar. Let the user customize the toolbar to fulfill their needs.
99 steps
One thing that concerns me is an application that uses multiple windows to complete a single task. I can’t stand going through three or four steps (or menus/sub-menus) to complete a task that perhaps a palette (utility window) could handle.
Too many palettes
Of course let’s not go palette crazy. You need a place to locate and keep all of your settings and tools, but there can be too much of a good thing. Palettes can consume an enormous amount of real estate. How many times have you started to perform a task and you end up running into a palette? There are many times you start something that you can’t complete because there is a palette in the way. Even if the application allows you to make a change behind a palette, you can’t see through it. If you have multiple palettes in your application, you need to have some creative solutions to handle them.
One of my favorite graphics applications has six palettes and one toolbar that I need constant access to, but they monopolize my screen space. One delightful way they managed this is by letting me hide all my palettes by pressing the Tab key. I can grab a tool or make settings and dismiss everything with one button. Consider a keyed "hide" option if your application has multiple palettes. Another possible solution I would like to see is giving users opacity control for palettes. It would be fantastic if I could set my palettes to be semi-transparent. Even better, when I click my mouse to perform a task, my palettes would ghost or vanish, allowing me to use my entire work space. No keystrokes.
Microsoft Word X has an intriguing way to handle palettes. They’ve taken items that normally might be considered separate palettes and combined them into one. Their size is managed by making them expand and grow as needed. I really like this feature. The only drawback to their solution is that the palette can actually expand right off your viewable screen.
Mmmm, feedback
Nothing is tastier than good feedback. I was recently testing an application that told me that it was running by displaying the word “Running.” Although a fantastic application, this simple static feedback leaves me a little wary. I like to see an application that uses some type of iconic representation to show me something is happening. Now don’t go placing huge garish icons that pulsate or blink mercilessly. Simple progress bars and small icons in motion add an element of action without annoying the user.
Aqua consistency
Not only do you need to be consistent with your apps internal functions, you need to be consistent with Aqua. I have seen a lot of applications that ignore Aqua guidelines. Consider these items when building your UI.
- The system text is Lucida Grande. Let the system draw your text. Always use anti-aliased text and don’t mix fonts. Using your own fonts in Menus and Windows will only confuse your users.
- Be careful not to use System 9 elements (Platinum) in OS X applications. I can’t tell you how many Cocoa applications I have found with System 9 elements such as icons.
- Don’t make your own windows. Use the Aqua pin-striped windows and allow the system draw them.
- Do not use buttons for labels. Aqua elements are built for specific functions. If you use a button for a label, users will become confused as to why they can’t activate it.
![]() |
Finally…
Remember that at some point everyone is a novice with your application. Your goal is to build an interface that makes sense, decreases the learning curve, and increases productivity. Take a look at other successful applications that you admire when designing your application. What makes their UI so appealing? Be sure that you take your UI design as seriously as you take your code development. In the next column, we’ll actually fire up Interface Builder and begin building our first UI.
Alan Graham is the creator of the Best of Blogs book series and is a frequent writer on the O'Reilly Network.
Read more Designing for Aqua columns.
Return to the Mac DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 5 of 5.
-
But what's really hard about UI design.
2001-12-19 20:37:13 purenumbers [Reply | View]
i think the real issues about user interface decisions come down to making the interface useful. in an ideal UI, as in Bryce, nearly every feature of an application is accessible, obvious, and unconfusing. That is to say, every single element in a UI does what it looks like it's supposed to do, and the user finds the element to do a given task easily.
Part of that is a predictable UI. Thats' why apple doesn't want you to mess with the Aqua. Users get used to the way applications look and react.
Getting all of the features in an application in reach of the user is alot harder though. I'm presently neck deep in that issue, designing an Appointment application. There are a great many ways of displaying and collecting information, but it won't do to show all of that information at one time. My application needs to show only fragments of the information, but also make it possible to switch from fragment to fragment, and do so intuitively.
I find myself asking a fairly small number 1. Can i design this element more simply? 2. is it easy to locate and use this element? 3. does this element do everything that it needs to?
i think these questions are pivotal to a good UI. it makes it easy to learn to use the application, and it makes it easy for savvy users to use the application to it's greatest extent.
A good example of this kind of design is, ironically, Interface Builder. All of the tools in IB are grouped logically in two palets, and their meaning is immediately obvious. IB is only usefull to users that know what to do with nib files, but if you are savvy, then the only obstruction to using IB is your own creativity in Interface Design. The Tool itself is nearly transparent to its use
-
I don't like Aqua
2001-12-16 12:37:46 theolein [Reply | View]
I get quiet tired of Apple sometimes. Aqua is a nice UI but it would be nice if Apple provided some flexibility in system wide font choice , widget choice etc.
-
Yes, but...
2001-11-19 10:31:00 adamrice [Reply | View]
While I felt that all the points in the article were well made, it seems to be picking the low-hanging fruit. The tricky parts of interface design are the less tangible ones. Do you present a feature through a button, menu item, whatever? Are some options even worth presenting, or should they be hard-coded, out of reach from the user (tough call, Dock positioning is an example of leaving a feature in without presenting a ready way to manipulate it)? How do you organize different-but-related features? MS's Word 4 was notorious for its disorganized design, that placed table-related menu items under three different menus, with multiple layers of dialog boxes to drill through to access some features.
Less is more in interface design. You don't want to load every interface element with too much functionality, but often you can use one widget to do more than one thing. The play/pause toggle in iTunes is an obvious example. Graying-out a "next" button when there is no "next" is another good example that isn't always followed. Grayed-out icons in BBEdit to represent an unsaved file are nice (if you notice them and know how to interpret them). -
Yes, but...I agree
2001-11-19 17:26:24 Alan Graham |
[Reply | View]
I absolutely agree. The problem is condensing all these elements into 1600 words or less. When I began writing the column I thought I would simply cover the technical aspects of UI design, assuming that many people were well versed in design...and then I realized after looking at many current applications...that building for Aqua is like landing on the moon for the first time. How do you describe the scope of something so new and unique...to an audience that has never been there before? Never in history have developers had to meet such high standards. Apple has really raised the bar here. This article was an attempt at bridging the gap between philosophy and common sense. If this were a book on Aqua design...I would elaborate on many of the subjects you mentioned. But this piece is really focused on those new to design...to give them some basics to think about.
BTW...the iTunes example is a very good one. A play/pause easily replaces an additional button for Stop...giving you similar functionality while simplifying the UI.
Thanks for the reply. Excellent points.







The dock-peace that many professional users are longing for, would require a division of dock functions into two or three dock frames.
1. One frame for stable icons only: finder-icon, residing applications and folders, trash. One might place it down at left corner of the desktop. Fill a row of folders into, which then open in hierarchical menus. We can navigate now from the left to the right, all over the screen, through the whole system, more flexible than in the old apple menu and its substitutes. Maybe not compliant with apples human interface guidelines, but very effective for visually oriented webdevelopers and designers. Test it with the present apple-dock: You see on the long run, the only fuss of the present dock are icons moving and a trashcan wandering.
2. One dock or frame holding active applications for switching only.
3. One dock or frame holding zipped windows only.
All frames placeable where it pleases, growth direction automated like in the original, on touch frames snapping together, all with choice for transparency.
Whether apple allows multiple original docks and a divison of functions of the original dock? If not, we need a killerdock app, comparable elegant, at minimum allowing to take either the fixed or the unstable items out of the original. If apple policy forces to build an app with two or multiple docks, one will find out, how to switch the original off.
If not possible as a freeware or open source project, i suppose, many would be happy to pay for a reliable, elegant and uncluttered shareware solution.