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.
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.
|
Also in Designing for Aqua: An Interview with Ivor St. John Clarke About Aquafying Office X |
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?
|
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.
|
In building your amazing Aqua application, one of the most important things to consider is the Dock. There are three things your app needs to be "Dock Compliant." Now, I write this knowing that the Dock will be going through some major changes soon, but for the most part, these should still hold true.
Number 1: Dock Location
Due to the positioning of the Dock, remember that when you build an application, you have to be sure that new document window sizes and positions do not violate the Dock's space. Dock is temperamental and Dock loves his space. If you default to a window size that expands behind the dock, users will have a difficult time reaching the navigation and resize areas at the bottom of the screen. I can personally say that more than once I have been rather peeved that I couldn't get to an area of the window to resize because the default window settings always pop up behind the Dock. In addition, the new Dock in 10.1 will allow users to position their Dock location on either side of the screen as well.
|
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.
Number 2: Dock Clicks
Clicking an application in the dock should always bring forward an active window. If the user clicks on an open app's icon in the Dock, the application is active and all unminimized windows come along with it. I have found a few problems with windows behaving independently of their application.
For example, if you see an AIM window peeking out from behind your browser and you click on it, that window will come to the front, but the main application window will not. The Mail.app/Activity Viewer is another example. The Aqua system of layers works well in many instances, but not in all. Thank goodness that the Dock is always there to come to the rescue. I know that clicking on an application icon in the Dock will always result in not only the application coming to the front, but also any non-minimized windows associated with it. And if the application is active but no windows are open, clicking on the Dock icon should create a new window in that application.
Number 3: Dock Animation
Not quite as entertaining as Shrek, but Dock animation can be an important and useful function in your application. For example, Dock animation is a helpful way to indicate the status of your 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.
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.
For my Paint application, I created a series of icons to simulate a rendering algorithm. While the application is performing this CPU-intensive task, you can always see the status of the document by the icon changing in the Dock.
|
I hope you find these suggestions useful. Stick around for future columns while we learn how to be a good Aqua citizen together. Maybe we can even come up with an oath?
I promise to do my duty, to Apple and my country...
Rendered photo-illustrative icon
Comply to Dock
Adhere to system appearance
Adhere to layout guidelines
Adhere to window models
Adhere to file locations
Build help file
User assistance
Dock animation
Drawers
Speech Recognition
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.
Copyright © 2007 O'Reilly Media, Inc.
