September 26th, 2006 • 9:48 am
Ah, Adobe. You have got to admire their ability to always come up with new ways to annoy you.
We have also seen the shameful lack of polish of some of their applications.
Today, I was launching Illustrator CS2, and, after the lengthy startup sequence, the application showed its startup dialog with the three buttons “New Document,” “New From Template,” and “Open Document“:
Nothing new here. All Adobe applications come with such a startup dialog by default. You can turn it off by unchecking the option in the bottom-left corner… the only problem being that Adobe Illustrator CS2 only properly remembers that you unchecked that option when you actually quit the application.
Given that I tend to leave my applications open once I’ve launched them, and that I might not have any reasons to quit them for several days, and that the overall crappiness of Adobe’s code means that the applications are much more likely to crash that to be quit properly, the likelihood that such a change will actually stick on my machine is pretty low.
In other words, it’s not really surprising that, after all this time, this option is still checked and I still get the startup dialog on my machine, even though I don’t particularly like it. But anyway…
My problem here today with this dialog is the following: To dismiss it, you have to press the “Close” button in the bottom-right corner. Most Mac users will probably do that will the mouse. But some Mac users like to use the keyboard instead of the mouse. Properly designed Mac OS X applications provide keyboard shortcuts to access the various controls and buttons in their dialog boxes.
In fact, Mac OS X even comes with a feature called “Full Keyboard Access” that makes it very easy for third-party developers to provide easy access to all the controls in their dialog boxes.
Unfortunately, Full Keyboard Access is one of these features full of promise that are still not applied and used consistently in Mac OS X.
Adobe has a long history of failing to embrace such standards properly. For example, when you try to close a document window in Photoshop without saving it first, the alert box that comes up has three buttons: “Don’t Save,” “Cancel,” and “Save”:
As you can see in this screen shot, the “Save” button is in pulsating blue, which means that it’s the default button in the dialog box and you can trigger it by simply pressing the Return or Enter key.
The “Cancel” button can also be triggered by pressing the Escape key, which is another universal convention in Mac OS X. Adobe properly supports that.
But what about the “Don’t Save” button? The button has no obvious keyboard shortcut. With Full Keyboard Access on, you’d expect to be able to access this button by pressing the Tab key repeatedly, which normally causes a blue halo to appear and cycle through all available controls in the dialog box.
Unfortunately, Adobe doesn’t do Full Keyboard Access. So you can press the Tab key all you want in that dialog box. Nothing will happen. No blue halo will appear, and you certainly won’t be able to access the “Don’t Save” button with the keyboard that way.
But in actual fact you can access the “Don’t Save” button with the keyboard. You just need to know that the keyboard shortcut to access this particular button in this particular dialog box is… command-D. There’s nothing that says that this is the keyboard shortcut to use.
But that’s the way it used to be very long ago, way before Apple ever introduced Full Keyboard Access: You typically could trigger buttons in dialog boxes by pressing a shortcut consisting of the Command key with the first letter of the first word of the button label text. So here it is command-D as in “Don’t Save.” Like I said, you just need to know.
Now, in Adobe’s defense, Apple itself seems to have trouble embracing its own Full Keyboard Access feature in some of its applications. iTunes is one glaring example. There are numerous dialog boxes in iTunes where Full Keyboard Access simply does not work, and you also have to use arcane, undocumented shortcuts instead. But thankfully, with Apple, it is the exception rather than the norm. (iTunes is one particularly glaring exception, admittedly. But it is still an exception—although the startup dialog in GarageBand 3 is another pretty glaring one.)
With Adobe, on the other hand, Full Keyboard Access remains a pipe dream… But wait a second! What’s this I see when I press Tab in the afore-mentioned startup dialog in Adobe Illustrator CS2?
A blue halo? My word! Could it be that Adobe has actually embraced Full Keyboard Access?
Sure enough, if I press Tab again, the blue halo jumps from the “Close” button to the “Show this dialog at startup” checkbox. And then back to the “Close” button. Amazing!
There is only one small problem here: The cycle with the blue halo doesn’t go through the three main buttons in the dialog box. In other words, the Illustrator startup dialog box appears to support some form of Full Keyboard Access, except that this support excludes the three most important buttons in the dialog. Ahem.
And unfortunately, it gets worse: While this blue halo does indeed appear around the “Close” button and the “Show this dialog at startup” checkbox, it doesn’t actually mean anything. If you press the Space bar when the blue halo is on either of these controls, which should normally be the equivalent of clicking on the button, Illustrator does… absolutely nothing. More specifically, it does the correct visual thing, i.e. the “Close” button becomes blue (as if you had clicked on it) and the “Show this dialog at startup” checkbox changes to a darker shade of blue (again, as if you have clicked on it), but nothing actually happens. The checkbox’s status doesn’t change, and the “Close” button doesn’t actually close the dialog box.
So what’s going on exactly here? Well, given that, as far as I can tell, Full Keyboard Access is not supported anywhere else in the Illustrator CS2 interface (except for the “Open File” and “Save As…” dialog boxes), the likely explanation is that, to design this startup dialog box in Illustrator CS2, Adobe’s developers did use some kind of standard user interface design tool that includes some level of built-in support for Full Keyboard Access. But in order to fully support Full Keyboard Access, they would still have had to do a bit of extra work and somehow connect the visual side of the Full Keyboard Access feature to the actual commands that it’s supposed to trigger.
And obviously they didn’t bother to do that, probably because they never meant to support Full Keyboard Access in the first place. The visual effects of the Full Keyboard Access feature just came on by default when they designed the startup dialog box, and they obviously couldn’t be bothered either to remove it (since they weren’t planning on supporting Full Keyboard Access anyway) or to implement it properly.
So there we are: We have a dialog box that looks like it supports Full Keyboard Access when it actually doesn’t. I don’t know what’s worse: An application that openly refuses to support Full Keyboard Access or an application that looks like it does, but actually doesn’t. I really have no reason to believe that this appearance of Full Keyboard Access visual effects in an Adobe dialog box is an indication that Adobe will eventually properly support Full Keyboard Access in its applications. In my opinion, it’s purely an accident, and it doesn’t mean anything.
Adobe, like Microsoft, continues to refuse to embrace some basic Mac OS X features, and there is no real sign that this will change in the near future. (I haven’t had a chance to test Adobe’s Lightroom, which is supposed to be a real “Cocoa application.” Maybe that particular application is better. But there is no indication that Adobe will rewrite its existing flagship applications to improve support for core Mac OS X features such as Full Keyboard Access.)