Mac OS X’s Save As dialog boxes: Inconsistent and counterproductive behaviour when clicking on file namesPosted by Pierre Igot in: Macintosh
February 27th, 2006 • 3:10 pm
Recent versions of Mac OS X include a feature that was first introduced in third-party add-on products such as St.Clair Software’s excellent Default Folder X.
It’s a feature that makes it easy, in “Save As…” dialog boxes, to copy an existing file name into the file name field at the top of the dialog box, instead of having to type it out manually. In order to insert an existing file name in that field, all you need is an existing file with the file name in question in the list of files underneath the file name field. Then you can just option-click on the file name of the existing file, and Mac OS X will automatically insert the exact same file name in the file name field at the top of the dialog box.
For example, in Pages I have the following situation: I have a file called “Work FR.pages” that I want to save under a new name. So with the file open in Pages, I select the “ ” command and I get the following dialog box:
The current file name in the “Save As:” field is “Work FR.pages.” I want to copy an existing file name in the list of files below, which displays the contents of a folder in View as List mode. In order to do so, I option-click with the mouse pointer on the desired file name—in this case the very first in the list (“Deputy Minister 2006-02-27 Canadian Heritage FR.pages”). As soon as I do that, I get this:
And that’s where the first problem with this feature is. Note where the focus is now. Instead of having a blue halo around the file name field, I now have a blue halo around the file list itself.
Why does Mac OS X switch the focus? It is utterly useless to have the focus on the file list after such an action. Unless I want to use the exact same file name and replace the existing file, the next thing I’ll want to do is edit the file name that I have just inserted in the “Save As:” file name field! And I will want to edit the name with my keyboard, of course.
Mac OS X unnecessarily switches the focus away from the text field, forcing me to click on the field again to bring the focus back there. Why does it do this?
And then of course when I click on the file name field again to put the focus back on it, Mac OS X puts the insertion point somewhere inside the file name, instead of selecting the file name as a whole. Again, this forces me to use the mouse again or keyboard shortcuts for text editing to put the insertion point where I want it.
I simply do not see why Mac OS X has to change the focus here.
The interesting part is that there is one particular situation where Mac OS X does not change the focus and correctly leaves the focus where it should be, i.e. on the file name field itself. Mac OS X keeps the focus on the correct interface item if and only if you are in a Cocoa application (such as Pages) and the list of files underneath the file name field is in View as Columns view mode:
But if you are in a Carbon application (such as Microsoft Word 2004), even if the file list in the “Save As” dialog box is in View as Columns mode, option-clicking on a file name to copy it to the file name field still unnecessarily changes the focus.
In other words, the situation is as follows:
- “Save As” dialog box in Carbon application with file list in View as List view mode: option-click switches the focus away from the file name field
- “Save As” dialog box in Carbon application with file list in View as Columns view mode: option-click switches the focus away from the file name field
- “Save As” dialog box in Cocoa application with file list in View as List view mode: option-click switches the focus away from the file name field
- “Save As” dialog box in Cocoa application with file list in View as Columns view mode: option-click keeps the focus on the file name field
You want to know what I think? I think that the Apple engineer who implemented this option-click feature in “Save As” dialog boxes in Mac OS X simply failed to test the new feature in any situation other than the 4th one, i.e. a Cocoa application with the file list in the “Save As” dialog in View as Columns view mode. He made sure the focus stayed on the file name field in that particular situation, but neglected to make sure that it would behave in the same way in the three other situations.
Why? Because some Apple engineers clearly have a user interface bias and think that every Mac user should use Cocoa applications and that every Mac user should always browse the contents of their hard drives in View as Columns view mode exclusively.
This bias was very clearly from the very early days of Mac OS X, when the View as Columns view mode was actually the only view mode available. Apple’s Mac OS X engineers only added back the other view mode (View as List) later on, presumably because of a significant number of Mac users protesting against this stupid restriction. But they still have the same bias and clearly, as the example above illustrates, they don’t pay as much attention to what happens in the other view mode. And they also don’t pay as much attention to what happens in Carbon applications—again a sign that they are deliberately ignoring the needs and preferences of traditional, long-time Mac users.
But the lack of quality control does not stop here. In fact, even in the one situation out of the four outlined above in which the focus stays on the file name field, the feature turns out to be flawed. If you look at the third screen shot above carefully, you’ll notice not only that the blue halo is still around the file name field (which is good, and expected), but also that there still appears to be a selection in the file name field. But this selection is totally arbitrary. It actually is a left-over from the situation before the option-click.
Before the option-click, what was selected in the file name field was the file name without the file extension. After the option-click, what is selected in the file name is simply the beginning of the new file name, with the same selection length as before the option-click.
But of course the new file name is completely different, and therefore this existing selection is utterly irrelevant. What is the point of selecting a partial string in the new file name, based on the text string length of the selection in the old file name? It serves no purpose whatsoever.
If Apple’s engineers really paid attention to such details, they would either ensure that the selection after the option-click spans the entirety of the new file name, or that nothing is selected at all. My preference would be for the former, obviously, but the latter would at least avoid the unsightliness of a partial selection that serves absolutely no purpose and looks more like a visual artefact than anything else.
These days, unfortunately, it appears that Apple’s engineers no longer pay attention to such details. As the implementation of the option-click-on-existing-file-name feature illustrates, those engineers don’t even bother to properly test the new features that they implement, and their implementation is such that it has unsightly side effects that no one at Apple seems to care about.
It’s sad, because attention to detail is what attracted many people to the Mac platform in the first place.