BBEdit Tip of the Day

A mark of a great interface is that when you try a shortcut that you think should work, it does. Today’s example, from BBEdit: hold down Option when selecting New with Stationery to edit the stationery pad instead of creating a new document.

Apple Retail Success

MDJ’s 8000-word converage of Apple’s financials includes this nugget:

That means that after sixteen months, Apple’s US-only retail stores are now contributing more revenue to the company than FileMaker, Emagic, PowerSchool, and all Asia and Pacific countries (except for Japan) combined.

System Keyboard Equivalents

In the October 16th Your Mac Life (streamed, downloadable), David Pogue says that Apple intends Command-Option keyboard equivalents to be for system use, citing the Dock and Jaguar screen zooming as examples. My recollection is that Command-Option was always for application use and that the Control combinations were reserved for the system. A quick look through the human interface guidelines (classic, 8/9, X) didn’t provide any confirmation for my memory or Pogue’s assertion, though evidence from Apple’s recent software (which, of course, doesn’t always follow the guidelines) is certainly on his side. In any case, I would prefer that Apple state once and for all that the system will stay away from Command-Option (except for the specifically mentioned equivalents like Command-Option-H) and applications should stay away from Control. Applications need Command-Option because with OS X Apple has co-opted so many of the plain Command key equivalents. (Plus, if an application uses a plain Command equivalent, it should be able to use the Command-Option variant for a related command.) It would be better if Apple reserved Control for its own use because that’s the only way to allow for future expansion of the system equivalents without taking back combinations that some applications are already using. And, similarly, Control equivalents are the only sure way for users to assign global shortcuts (e.g. with QuicKeys) that are guaranteed not to conflict with applications.

Joel on Mozilla and XUL

Joel Spolsky of Joel on Software writes:

It may turn out to be the case that one of the biggest benefits to come out of the Mozilla project is XUL, which seems to be one of the first solid frameworks for true GUI portability (WORA). Basically, you design your interface in XML, glue the events together with some JavaScript, and call binary XPCOM classes (virtually the same as Microsoft COM classes) when you need to do something fast in C++ that doesn’t need a UI. And UI’s never need to be that fast, so this is a good division of labor.

Theoretically, you get cross-platform Nirvana. And thanks a lot of hard work all the little platform-specific touches (like Alt+Space N to minimize a window) are finally right, which is one of the biggest weaknesses of previous efforts at WORA like AWT and Swing. If I had to start developing a new commercial app I would seriously look at XUL.

…XUL may well be a real benefit to Apple and Linux, because application developers finally have a way to deliver to all three platforms for perhaps 110% of the cost of Windows alone.

Unfortunately, most of the Mac platform-specific touches are wrong. The UI doesn’t look right or feel right. I would guess that XUL is to blame for why Mozilla is so slow to start up and why the UI is so sluggish even after it’s running. I’m not sure XUL is any better than Swing from the user’s point of view. But I do think Joel is right about Netscape and IE; Netscape dropped the ball, and most people used IE because it was better.