Exactly the point I was trying to make in a previous comment (http://www.mozillazine.org/weblogs/mt/mt-comments.cgi?entry_id=1729). I really think that's the only solution to this mess. Give just a few elite developers (Blake, Hyatt, Seth, et al) access to cvs checkins for a few months and see what happens.

What mozilla needs from the UI perspective is a UI owner (this could be a few people, but only a very few). This owner needs to have buy-in from staff, drivers, and super-reviewers so that people don't override his decisions at every step. This UI owner should have complete say over all UI decisions. This owner should be responsive when UI patches get proposed (marking the bug wontfix or invalid is a fine manner of being responsive).

People who whine or reopen bugs over and over should lose their bugzilla accounts.

All we need is the guts to do this. And someone willing to ignore a lot of flak from all the morons that make up Mozilla's user base.

You forgot to mention, this UI owner should know A LOT about general user interface guidelines. We do not want someone who wontfix'es a Home button on the toolbar for this task, right?

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.

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.

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.

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.

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.

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.

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.

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.

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?