Shrinking and Expanding Selections in Mac OS X (continued)

Posted by Pierre Igot in: Macintosh
April 29th, 2009 • 3:47 pm

Since my original post on this topic has been Daring-Fireballed, has generated a fair amount of feedback, and has been followed by another post on Daring Fireball, I thought I should clarify a few things.

First of all, I want to stress that my initial post raised two clearly separate issues. One is the logic behind the behaviour that I described as “smart unanchored selection” (for lack of a better term) and the other one is the inconsistency across Mac OS X applications.

The first issue (the logic behind) has generated a variety of responses. Both John Gruber and Dmitry of Coding Robots provide an explanation for the behaviour, which is essentially that text selections made with the mouse are unanchored, i.e. their behaviour does not depend on whether you clicked and dragged from the left to the right or from the right to the left.

The one important point to note is that, when selecting with the mouse, you can actually select text without going either from the left to the right or from the right to the left. A double-click on a word will select that word, and, as Dmitry rightly argues, such a selection has no direction, so there is no apparent reason to give a predetermined anchor to the selection.

Similarly, a triple-click on a paragraph selects the entire paragraph. Here again, there is no way for Mac OS X to determine a direction for the selection based on the user’s actions.

Possibly because of these situations where the direction of the selection with the mouse is undefined, Apple has adopted HIG guidelines for extending text selection with the Shift and arrow keys, whereby any selection with the mouse is effectively unanchored and the direction of the extension is determined by the first keyboard shortcut used after selecting with the mouse.

I don’t necessarily agree with this choice, because I think that, in cases where the user clicks and drags (instead of double-clicking) or double-clicks and drags (instead of triple-clicking), there is clearly a direction to the selection. I would also argue that it is easier to be more accurate with the click before the dragging than with the mouse button release at the end of the dragging. Dragging is an operation that creates tension in the muscles of the hand and, in my opinion, reduces the accuracy of one’s movements. Because of this (although I obviously don’t have hard scientific evidence to back it up), I believe that users are more likely to make a error (to go too far or not far enough) with their selection at the end rather than at the beginning. And that’s why I find it a bit difficult to adjust to the idea that even selections with clicking and dragging are unanchored.

The other point is that making the selection unanchored is not the only alternative when the mouse selection is direction-less (i.e. when the user’s actions do not indicate a direction). Even though double-clicking on a word does not indicate a left-to-right direction for the selection, it can be reasonably assumed, in a left-to-right written language such as English or French, that the user is more likely to want to extend his selection to the right than to the left. How often do you double-click on the last word of a phrase and then proceed to work you way back to the beginning of the phrase? I sure don’t do that every often.

That said, in my original post I clearly said that I was willing to believe that Apple’s engineers had thought hard about this issue and decided that the “smart unanchored” behaviour was the best compromise in the circumstances—which the HIG guidelines appear to confirm. So I wasn’t really “complaining” about their choice (contrary to what John Gruber and Dmitry say). I was just saying that I found it somewhat difficult to adapt to and was not entirely convinced it was the right choice.

What I was really complaining about is the second issue, i.e. the inconsistency. What the Apple HIG guidelines don’t tell you is that some of Apple’s own applications do not comply with the guidelines. Text selections in a file’s name field in the Finder do not work that way, and neither do text selections in iTunes. (They are both anchored.)

Dmitry explains that it is probably a Cocoa vs. Carbon issue. Well, I don’t care. I don’t think the user should have to put up with two different behaviours depending on whether the application is a Carbon application or a Cocoa application. We have had enough of these engineering issues interfering with the usability of Mac OS X applications. If Apple has defined guidelines, then it needs to update its own Carbon routines to make them comply with the guidelines as well. Otherwise, we’ll still have to wait many years until all traces of Carbon are eliminated from Mac OS X (if they ever are).

And what makes the consistency issue worse is that the “smart unanchored” selection behaviour does not extend to selections of items in a list. Why? I do realize that there is no equivalent of word selection (with a double-click) or paragraph selection (with a triple-click) when selecting items in a list with the mouse. So there is no purely “direction-less” selection with the mouse (except for a single click to select a single item).

For consistency’s sake, I feel that extending selections in lists should work the same way as extending selections in texts in Cocoa applications.

And there is simply no excuse for having an anchored selection in Mail’s message list and Numbers tables and an unanchored selection (which is yet another behaviour, different from both the anchored selection and the “smart unanchored” behaviour) in iTunes track lists and lists of files and folders in the Finder.

Again, it appears to be a Cocoa vs. Carbon issue and again, I don’t care. I want consistency across all applications.

Of course, as I said in my post yesterday, when you had third-party applications to the mix, things can get even worse. Can you believe, for example, that it is still impossible to use the Option key with Shift and the arrow keys in Adobe InDesign for word-by-word selection? You have to use Command with Shift and the arrow keys in that application.

So good luck achieving consistency when you have developers like Adobe and Microsoft still playing such an important role in the Mac industry.

Finally, just for fun, one more thing. If you really want to see a selection-extending process gone crazy, look no further than iTunes’s album view. Go to iTunes, switch to album (grid) view, create a selection with the mouse, and then try extending that selection with Shift and the arrow keys.

It’s so ridiculous it’s hilarious. (Thanks to Adobe Gripes for the tip.)

One Response to “Shrinking and Expanding Selections in Mac OS X (continued)”

  1. On Anchored Selections in Windows, Gnome, and Mac OS X says:

    [...] Update: Pierre published a follow-up. [...]