Pages 2.0: Illustration of the problem with Apple’s non-standard text navigation shortcuts

Posted by Pierre Igot in: Pages
June 10th, 2007 • 11:57 am

The other days I wrote yet another post dealing with issues related to the non-standard text navigation shortcut scheme used by Apple in Pages and other Mac OS X applications.

Here’s a very simple example that perfectly illustrates, I believe, what is wrong with Apple’s scheme. I frequently have to translate documents that contain bullet lists, with each bullet item consisting of an entire paragraph of text, of which the very first sentence is highlighted in bold:

Paragraph with first sentence in bold

The question is: What is the most effective way to reproduce this effect when composing a document in Pages?

Most people probably just grab their mouse, and use the mouse pointer to highlight the first sentence in the paragraph, with a click-and-drag (to select character by character) or double-click-and-drag (to select word by word) all the way to the end of the sentence. Then they apply the bold formatting.

Personally, I do not like switching from my keyboard to my mouse for such a basic task. I want to use keyboard shortcuts instead. So I first position my I-beam cursor at the beginning of the paragraph, with option-Up:

Cursor at beginning

Then I start pressing option-shift-Right repeatedly. With the Option key down, the cursor jumps from word to word. With the Shift key down, it selects the words as it moves along:

Words selected

Then I reach the end of the sentence. By default, Pages’ behaviour, when reaching the end of a sentence (i.e. a period), is to highlight the word, but not the punctuation that follows:

Sentence selected, without period

That makes sense, because there are situations where you want to replace the words, but not the surrounding punctuation. I don’t have a problem with that. What I have a problem with is what happens when I press option-shift-Right once more after this:

Selection overlap

See the problem? I just pressed option-shift-Right once more because I wanted to select the period as well, simply because, if the entire sentence is to be in bold, then the period should be in bold too. (In most fonts, you can tell the difference between a period that is in bold and a period that is not in bold.)

But instead of just selecting the period, Pages actually completely ignored the punctuation and assumed that one more keystroke meant that I literally wanted to select one more word, so it extended the selection to the first word of the next sentence!

Pages is the only word processor that does this. Other third-party word processors and text editors, such as Microsoft Word or BBEdit, treat the period itself as a “word” and pressing option-shift-Right once more just extends the selection by including the period, and that’s it.

In Pages, on the other hand, if what you want to do is to select the period, after selecting the last word in the sentence, you have to do either of the following:

  1. Press option-shift-Right once more, which, as we have seen, selects the period, the space, and the first word of the following sentence. Then press option-shift-Left once, which, for some reason, now deselects the extra word that was selected, but keeps the period and the space selected.
  2. Instead of pressing option-shift-Right once more, which has the undesirable effect of selecting the extra word, release the Option key and just press shift-Right once. This will just select one more character, i.e. the period.

Unfortunately, neither of these methods is satisfactory. The first one, as indicated, keeps the period selected, but also keeps the space char between the two sentences selected:

Selection with period and space

Personally, I don’t like this, because there is no way to tell whether a given space char is in bold or not. And if it’s in bold and you put your I-beam cursor after it and start typing, you’ll get text in bold, even if you don’t want it to be in bold.

The second option is not very good either, because it forces you to be very accurate with your typing. When you press option-shift-Right repeatedly (to select text word by word), it’s very easy to “overshoot” and press the keys too many times. (That’s one of the drawbacks of text navigation with keyboard shortcuts. There is a certain amount of correction required, because it’s too difficult for the human mind to keep track in real time of the exact number of times you’ve pressed the same keys in a row. But of course text navigation with the mouse has its own drawbacks, including a similar need to constantly correct approximate mouse movements. So this is not an argument against using text navigation keyboard shortcuts. It’s just an observation that neither approach is perfect)

So if you press option-shift-Right one time too many and switch to shift-Right (without the Option key) to select just the period at the end of the sentence, you might end up extending your selection by one character to the right in the wrong place, i.e. after the first word of the next sentence—which requires more correction.

When a keyboard shortcut has to be used repeatedly several times in a row, fast typists will do it very fast, and will end up having to correct their move by one or two key strokes in the other direction. That is perfectly normal, and fast typists are used to that. What they are not used to—and cannot get used to—is making sure that they do this correction before switching to the next step in the sequence of keystrokes, i.e. the shift-Right without the Option key here, because the whole sequence of selecting the text with the keyboard needs to be very fast—otherwise there is no point in using the keyboard rather than the mouse.

In short, I really do believe that Apple have made a mistake with this proprietary, non-standard way of handling text navigation with the keyboard. Notwithstanding the fact that it is too hard to constantly adjust from one scheme to the other when switching from an Apple application to a non-Apple application and back, there are simply too many situations where the non-standard scheme gets in the way, at least in my personal experience. There might be some advantages to it, and even a certain logic to it, but the sad fact is that this logic doesn’t result in better usability in real-world situation, quite the contrary.

The problem, of course, is that this is a rather subtle issue that is unlikely to ever get major coverage in the Mac media. Even on this very blog, I have already written several posts on this issue, and have received very little feedback, even from my hardcore readership of word processing experts!

So Apple introduced the new scheme unilaterally, and are unlikely to change their minds in the near future due to public pressure to go back to a more standard way of doing things. In other words, we’re stuck with. And it’s a bummer.


2 Responses to “Pages 2.0: Illustration of the problem with Apple’s non-standard text navigation shortcuts”

  1. kurisu says:

    Actually, this is not a problem with Pages, but a problem with the Cocoa Text handling features, which at least ALL Apple apps that handle text depend on. I can reproduce this annoyance in Textedit.app and the editor in Mail.app, as well as in this very text box I’m typing this reply in Safari.

  2. Pierre Igot says:

    Yes, I did mention this on several occasions, more specifically in previous posts linked to here—although if you dig a little deeper you’ll see that there are actually some Pages-specific behaviours, so to me it looks like Pages uses a “customized” version of the text handling features. But the bottom-line is indeed that Mail, TextEdit, Safari, and all other Apple applications in Mac OS X, and even non-Apple applications that use the Cocoa Text handling features (such as OmniWeb, FileMaker Pro, etc.), also use these non-standard annoying behaviours. Conversely, the major non-Apple applications that involve word processing and text editing, namely Microsoft’s and Adobe’s applications, do not use these behaviours. Hence the constant need to adjust one’s own behaviour.

    To be honest, however, even if the Cocoa Text behaviour was the universal standard in Mac OS X, I still don’t think I could get used to it. It just doesn’t make sense in real-world text editing situations.

Leave a Reply

Comments are closed.