Betalogue

Sometimes one really feels that nobody at Apple uses the keyboard for anything other than typing text. It is as if Apple’s engineers are not even aware of the support for keyboard navigation within their own applications. They keep breaking it.

The latest case in point is the new iCal 3.0 that is part of Mac OS X 10.5. iCal revamped the entire iCal application, and in the process managed to completely break support for keyboard navigation when editing iCal events.

Take this very simple situation. You double-click on a day in iCal’s main window to insert a new event. You type the title of the event with the keyboard, and then you press command-I to bring up the information “bubble” for this new event.

Then you press the Tab key repeatedly to go to the “alarm” section of the information bubble, until the focus (blue halo) is on the local control for adding an alarm:

Then you press the space bar once to bring up the alarm menu and you use the Down cursor key to select the “Message” option.

Then you press the Return key to select that option to add a message as an alarm. And here’s what you get:

What’s the problem here? It’s simple: there is no focus. There is no blue halo. The focus should be on the newly inserted alarm, more specifically on the number field containing the default “15” value, so that the user can type a different value without having to lift his hands from the keyboard.

But the focus is completely gone here, which means that the only option is to grab the mouse and click on that number field manually to put the focus back on it, and then go back to the keyboard and type the new value. (Alternatively, you can also press the Tab key a dozen times again, since the focus is actually back on the bubble as a whole, but you have to start from the very top again.)

This is really ridiculous. How could they break such a fundamental sequence of keyboard-based actions? (It used to work just fine in iCal 2.0 under Mac OS X 10.4.) Since they can’t really be suspected of having done this intentionally, the only logical conclusion is that Apple does not test its own software properly with a focus on keyboard navigation. Support for keyboard navigation is almost always an afterthought, and something that we end users are forced to remind them of again and again through bug reports and complaints each time they break something.

It really is frustrating.

I am aware of this recent post by John Gruber on his Linked List, where he reminds us of an old study by Bruce Tognazzini that shows that, even though test subjects consistently report that keyboarding is faster than mousing, the stopwatch consistently proves mousing is faster than keyboarding.

But surely even Tog himself would agree that this gives no right to Apple engineers to break support for keyboard navigation in their applications.

This entry was posted by Pierre Igot on Tuesday, November 13th, 2007 at 12:19 pm and is filed under Macintosh. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.