doron's blaahg

Adopt Sheets. I really like the use of Sheets in OS X. The use of Sheets lets me know which window my dialogue belongs to without hijacking my system.

Other examples of these animations might be to show the status of an FTP transfer, the progress of media being digitized, or an updated time signature. And don't forget that users may want to have some control over this, so give them plenty of options, including the ability to turn these functions off.

Okay, I just told you what Apple wants you to look out for with window positions, but in the real world, not everyone uses the hiding feature of the Dock, and it is unrealistic to be able to predict where each user will place their Dock at any given day or how large they will have it. However, you can build a feature into your application that allows spacing for the Finder. You can give users the option of where to position their windows and what area of the screen not to cross. I know that BBEdit provides me with this feature, and I wish more developers gave me more control over my windows.

Adhere to Layout Guidelines. Did you leave 12 pixels between your push buttons? Does the positioning of your pop-up menus make sense, and when do you use a pop-up versus a scrolling list? Are you using the right types of buttons for the proper functions?

This is the first thing your users see, and probably the single most important visible part of your application. It is the first chance you have at making an impression and the best chance to help establish your brand.

So far in these articles, I have only dipped a toe or two into Aqua's pool. I have covered basic aspects of building an Aqua-compliant application, including the building of photo-illustrative/3D application icons. Now it's time to address other components of our Mac OS X application.

But limit your animations to whatever is required to communicate the necessary information. Avoid annoying animations that discourage ease of use. Ask yourself, "What do I need to show the user, and what is the cleanest way possible to achieve that?" A good example is the Mail application for Mac OS X. Whenever a new message arrives, the Dock icon changes appearance to indicate a changed state.

To put my money where my mouth is, in each new article I'll build a hypothetical application that illustrates the guidelines I'm covering. Today's application is called "Paint" and will be based on the photo-illustrative icon I created in my last article. Together we will complete each step, and by the end of the project we should have a well-designed, 95%-100% Aqua-compliant application. I'll leave some room for personal preferences and the fact that Apple changes the OS every few months.

Help! Did you include help tags in your applications? (I'd be lost without them.) Also, be sure to take extra time to develop your other help files. The Apple Help Viewer supports HTML, QuickTime, and also AppleScript. Take advantage of it! There isn't anything I hate more than going to the Help menu and finding there isn't any help.

If an application is designed well, the reward for users is that they will learn it faster, accomplish their daily tasks more easily, and have fewer questions for the help desk. As a developer of a well-designed application, your returns on that investment are more upgrade revenue, reduced tech support, better reviews, less documentation, and higher customer satisfaction. The rewards of building a good-looking Aqua application are worth taking the extra time.