Red, White, and ... Aquaby Alan Graham
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.
The importance of becoming a good Aqua citizen
By building an application that takes advantage of Aqua's many facets, you help ensure that your application will not only look good, but have a chance of becoming a raging success. After a new user clicks on the icon of your program, the first thing he or she sees is the application interface. I know that when I review a product, I am very critical of its visual design. I usually have a short time to learn the new software, so design and ease of use are very important. Aside from those who marvel at the beauty of the command line, most users tend to react the same way.
At WWDC, I listened to Apple representatives make some excellent points about taking the time to build a 100%-compliant Aqua application, and I think all developers need to look beyond the code and listen to what the folks at Apple have to say.
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.
The simple fact is that, when all other factors are equal, where will consumers spend their money? I believe that in the long run, the best looking, easiest-to-use applications will also be the most successful. I think that's why Apple encourages developers to write programs that are 100 percent Aqua-compliant.
Many of Apple's design guidelines follow the rules that artists learned in school. But we learn practical lessons along the way too. What have your experiences taught you?
Also in Designing for Aqua:
To help you become a good Aqua citizen, Apple has created a few guidelines. I've put together a brief overview of them, and we'll be tackling many of them in the months to come.
Porting/Building Your Code. Whether native or not, this is obviously one of the first steps on your way to OS X. Keep in mind that often, the functionality of your code has a lot to do with how your interface is designed. How many developers have come up with great functional ideas from working with their interface or looking at their competitors'? Start working on your Aqua compliance from day one. Don't wait until the last minute.
Quality Icons. 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.
Complying with the Dock. This topic is one we will tackle later in this article, but it refers to making sure that your application and the dock aren't fighting it out for supremacy of the screen.
You Must Promise. To call your mother, to help old ladies cross the road, and to turn your cell phone off at the movies.
Adhere to System Appearance. Does your application use all the sweetly colored buttons, delightfully shaded windows, and all the other "bells and whistles?"
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?
Adhere to Window Models. Document windows, Utility windows, Click-through, Layering, Drawers, Controls. How do users open windows, how do you properly title windows?
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.
Adhere to File Locations. Make sure that when your users save documents, your application knows where to put them and also gives users flexibility.
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.
User Assistance. This is helping the user with the proper "next step" when performing a task. Less guesswork for the user on what to do next makes for a better experience.
Dock Animation. Sometimes animating icons in the dock can be useful in communicating the status of the system or application.
Drawers. Similar to Sheets, this is a "child" window that gives users access to items that do not always need to be present. But when do you use a drawer and when do you use a palette?
Pages: 1, 2