We've recently been having a bit of back-and-forth about the effectiveness of multiple presentation support in Mozilla, and I've reversed my earlier, less-knowledgeable position. We should continue to support them. The cost of keeping them up is minimal and they make printing and other secondary presentations work faster (and printing is slow enough as it is without cloning the document). And I haven't seen any specific proposals (yet :) for how a single presentation will help us simplify our architecture, so there's no win yet for that. Combining content and frames, the only one I can think of, is not really a popular idea yet, and I can see it might have problems (our display: mechanism, as roc pointed out, is totally centered around that dichotomy).
On a probably related issue, I've been wondering lately what the cost/benefit is of passing PresContext to every freaking method in layout (which we do now) versus just storing them in the frames or somewhere accessible. I bet changing this to storing in the frames would be a real win--you get rid of a lot of symbols and callsite pushes. If it came down to it, you could possibly avoid storing it in the textframe and instead have textframes ask their parents. I'm told someone else was thinking along the same lines in a blog lately (dbaron?) but I can't find it.
Posted by jkeiser at April 15, 2003 10:50 AMThis problem would help solve many issues with recent RFE bugs about automated rendering of webpages to bitmaps/PS/PDF/whatever.
Posted by: B. Smedberg at May 7, 2003 8:58 PMFor 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.
Posted by: Dionise at January 25, 2004 3:06 PMClicking 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.
Posted by: Holland at January 25, 2004 3:07 PMTo 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.
Posted by: Tobias at January 25, 2004 3:07 PMFor 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.
Posted by: Basil at January 25, 2004 3:07 PMFor 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.
Posted by: Martin at January 25, 2004 3:08 PMThis 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.
Posted by: Anchor at January 25, 2004 3:08 PMAdhere to Window Models. Document windows, Utility windows, Click-through, Layering, Drawers, Controls. How do users open windows, how do you properly title windows?
Posted by: Mildred at January 25, 2004 3:08 PMYou Must Promise. To call your mother, to help old ladies cross the road, and to turn your cell phone off at the movies.
Posted by: Alan at January 25, 2004 3:09 PMIf 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.
Posted by: Christopher at January 25, 2004 3:09 PMBy 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.
Posted by: Dudley at January 25, 2004 3:10 PM