Numbers 3.5 (iWork): Hijacks cursor keys when editing cells

Posted by Pierre Igot in: Macintosh, Pages
February 27th, 2015 • 10:41 am

On February 25, 2015, I used Bug Reporter to submit the following bug report (#19951698) to Apple:

When I select a cell and start typing, the cursor blinks inside the cell. Yet if I use the Left or Right cursor key, Numbers jumps to the previous/next cell, instead of navigating inside the current table cell.

Steps to Reproduce:
1. Open any Numbers document containing a table.
2. Select a table cell by clicking ONCE on it.
3. Start typing.
4. Press the Left or Right cursor key.

Expected Results:
I expect the Left or Right cursor key to move INSIDE the current table cell by one character to the left or to the right.

Actual Results:
The Left or Right cursor key JUMPS to the previous/next table cell.

Numbers 3.5.2.
OS X 10.10.2.

To add insult to injury, the behaviour is not consistent across iWork apps. In tables in Pages, I get the expected behaviour.

I think this report is quite self-explanatory. For completeness’s sake, I probably should have added that when, instead of simply selecting a cell in Numbers before you start typing, you double-click on the cell to make its contents editable right away, then, for whatever reason, the cursor keys work as expected.

I can see absolutely no visual difference between a selected cell that becomes editable when you start typing and a cell that becomes editable when you double-click on it. And yet, in the first instance, the cursor keys do not work as expected — they jump from cell to cell, even though the I-beam cursor is blinking in the cell — whereas, in the second instance, they work as expected — they jump from character to character inside the cell whose contents you are currently editing.

I also should have pointed out that the impact of this hijacking of the cursor keys is that it also affects one’s ability to use the keyboard to navigate word-by-word inside cells, because the shortcuts for jumping from word to word inside a cell are the same standard shortcuts as elsewhere in OS X, i.e. option-Left and option-Right. In Numbers 3.5, after you select a cell and start typing in it, if you use option-Left and option-Right, instead of jumping from word to word, the application actually gives to those shortcuts the meaning that they have when you are not inside a cell, i.e. they insert a new column to the left or to the right of the current column. (I have already written here about the idiocy of that other hijacking of commonly used keyboard shortcuts in iWork.)

And of course, the additional impact of this hijacking of the cursor keys is that it also affects one’s ability to select text inside cells, because the shortcuts for extending the selection to the left or to the right are based on the cursor keys and are shift-Left and shift-Right. In Numbers 3.5, after you select a cell and start typing in it, if you use shift-Left and shift-Right, instead of extending the selection to the left or to the right inside the cell, the application gleefully selects you out of the cell and starts extending the selection of cells to the left or to the right.

(I should also mention the shift-option-Left and shift-option-Right shortcuts, which are also affected. In that case, Numbers ignores the Shift modifier and assumes that you meant to hit option-Left and option-Right, and so it inserts a new column to the left or to the right of the current column.)

Finally, it should be stressed that, when you enter a cell by double-clicking on it, all these other cursor-key-based shortcuts also work as expected, as do the cursor keys themselves. So at least the inconsistency is consistent (although I doubt very much that this is deliberate).

To Apple’s credit, I got an answer to my bug report within 48 hours:

Engineering has determined that this issue behaves as intended based on the following information:

Yes, this is behaving as designed. In tables in Pages we are expecting a user to type more text in a cell and so we favor text navigation with the arrow keys. For Numbers, we are expecting cells to contain short bits of data, like a number in each cell, so for that pattern we use the arrow keys to navigate to the next cell. That way a user could type 1, right arrow, 2, right arrow, 3, and quickly enter values into 3 cells.

If you have questions regarding this resolution, please update your bug report with that information.

We are now closing this bug report.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

I am afraid this makes very little sense. If indeed the idea behind the hijacking of the cursor keys is to enable the user to “quickly enter values” in a series of cells, then why is the behaviour different when the user double-clicks on a cell to make it editable?

In addition, we already have long-standing shortcuts for quickly entering values in a series of cells: the Tab and shift-Tab keys.

Also, just because the bits of data might be short, it does not mean that the user is less likely to make errors in his or her text input that require small corrections, which are one of the primary uses of cursor keys!

As well, the very reason for having universal, system-wide standard shortcuts is so that people can develop “muscle memory” that enables them to use these shortcuts in all contexts without even thinking and expect them to work all the time. Any application that hijacks universal keyboard shortcuts to give them a different meaning goes against such expectations, and there is simply no way that you can reasonably expect someone who has developed such muscle memory to remember to do the non-instinctive thing when she or he is in a specific application and refrain from using the shortcuts.

Finally, if indeed the expectation is that in tables in Pages, the user will “type more text in a cell”, and therefore have even more reason to use keyboard shortcuts for text navigation and selection, why are the keyboard shortcuts for word-by-word navigation and for extending text selection also hijacked in that application? (Granted, the hijacking there is limited to what happens when you are not inside a table cell, but it’s still far too easy to think that you are currently editing a cell and accidentally use these shortcuts when you shouldn’t.)

All this is to say that I cannot help but feel that the response I got from Apple is a lie and that nobody has really thought this through. If they had really thought this through and paid real attention to the issue, the behaviour would be the same whether you enter a cell by selecting it and starting to type or by double-clicking on it.

And even if the whole thing is deliberate, I think it’s the wrong decision. The theoretical advantage to some users (who might never have heard of the use of the Tab key to “quickly enter values” in consecutive cells) is simply far too insubstantial compared to the on-going disruption caused by this hijacking of universal, standard system-wide shortcuts.

Comments are closed.