Betalogue

Mac OS X’s Address Book application is a database-driven application. As such, the user expects it to behave in ways similar to other well-known database authoring tools and database-driven applications, including FileMaker Pro, iTunes, etc.

Unfortunately, for some reason Address Book has a number of rather strange quirks that can be rather irritating for some users.

Fundamentally, Address Book is closer to a database-driven tool such as iTunes than to a database authoring tool such as FileMaker Pro in that entering new data is only something that you do occasionally. Most of the time, you browse the existing content of your Address Book database. In FileMaker Pro, the “Browse” mode is a mode in which you can both browse your existing records and create new records or edit existing records.

In Address Book, on the other hand, the default browsing mode doesn’t let you edit records. You have to click on the “Edit” button or select “Edit Card” (command-L) in the “Edit” menu to switch to the Edit mode where you can actually edit your address book record.

The interface for switching modes in Address Book is rather poor. Once you select “Edit Card” and the application switches to the Edit mode, the menu item in the “Edit” menu still reads “Edit Card”—even though you are already in Edit mode. And you have to select that “Edit Card” command a second time to exit the Edit mode.

How is possible for a phrase such as “Edit Card” to actually mean “Exit Edit Mode”? This doesn’t make any sense. The problem is that, in an attempt to keep things simple, Apple seems to have wanted to avoid actually calling this Edit mode a “mode” anywhere in the Address Book interface. The “Edit Card” command switches you to Edit mode, but the only clue that you have that you are in a different mode is the fact that the “Edit” button at the bottom of the window looks depressed, and the fields themselves are editable. But there’s no indication anywhere in Address Book’s menus that you are in a different mode. (Even without using the “mode” word, Apple could still have used something like “Save Changes and Stop Editing Card” for this menu command, though. Anything would have been better than keeping “Edit Card”!)

By comparison, FileMaker Pro has various “mode” commands in its “View” menu: “Browse Mode,” “Find Mode,” “Layout Mode,” and “Preview Mode.” If you consider that these are different modes of “viewing” your data, then I suppose it makes sense to put these commands (which also indicate the current mode) in the “View” menu. Address Book has no such commands in its own “View” menu.

iTunes, which is similar to Address Book in that it is database-driven but used mostly in Browse mode, actually forces you to go through a modal dialog box when you want to edit your tags—except for the song title tag, which you can edit by simply selecting the track and pressing the Enter key (or by clicking on the title itself and waiting a second).

So Address Book has its own proprietary way of switching between Browse mode and Edit mode, and the interface for it is not exactly perfect, at least when it comes to the way the mode is reflected in the application’s menus.

(Interestingly, during the early stages of development of Mac OS X 10.4, Apple had actually implemented another way to switch from Browse mode to Edit mode in Address Book. You could do so by simply double-clicking on any of the fields in a card. The simple fact of double-clicking was an indication to Address Book that you wanted to switch from Browse mode to Edit mode. This other method for switching modes was removed in the later stages of development of Tiger, presumably because it interferes with another use of double-clicking, which is to select entire words. I, for one, actually liked the double-clicking shortcut for switching to the Edit mode, because I rarely have to double-click on words to select them in an Address Book card, unless I am already in Edit mode. It felt rather natural to me, especially since the double-clicking method is already used for switching modes in other applications, including InDesign, where you can double-click on a text block to switch to the Text tool, and Microsoft Excel, where you can double-click on a table cell to make it editable.)

The problems with the Edit mode in Address Book are not limited to the process of switching modes itself. Once you are in Edit mode, there are a couple of small, yet significant problems.

The first one is what happens with the text that’s already there in the empty fields by default. Instead of indicating what each text field in the card is for with a text label next to the field, Address Book actually indicates the intended content of the field with grey text in the field itself. For example, the field for “First Name” is indicated by the word “First” in grey text in the field itself:

The reason for this is pretty obvious: Having a text label next to each field to define its contents would make it much more difficult to condense all this information into a fairly small window. And Apple actually uses text labels to describe sub-categories in each section of the card where you can have multiple fields. For example, in the section for e-mail addresses, there is one field for an e-mail address by default, and its text label is “work,” to indicate that it’s intended to contain the person’s work e-mail address. The only indication that we are in the “Email” section of the card is the grey “Email” text in the field itself. In other words, the sub-category is described by the text label next to the field, but the category itself is described by grey text in the field itself, which disappears as soon as you enter something.

It’s a rather strange way of doing things, and it’s particularly problematic in light of the fact that several different sections of the card share the same sub-category labels. For example, you can have a “work” phone number and a “work” e-mail address and a “work” mailing address. So in effect you have three sections of the card which are only distinguished by the grey text that is in the empty fields by default. As soon as you enter something in these fields, there is no longer anything that distinguishes the “work” phone number from the “work” e-mail address, except for their respective position in the card—and, of course, the contents of the fields themselves, since presumably a phone number will consists mostly of digits, while an e-mail address will consist of alphanumeric characters with a “@” symbol in the middle.

The basic problem with this approach is that it is fine as long as you don’t make any mistakes. But if, by mistake, you enter an e-mail address in the “work” phone number field (and Address Book will actually let you do this without any warnings about mismatched data), once you’ve entered the data, there’s no longer any visual indication that the e-mail address is in the wrong place. All you see is a “work” text label and an e-mail address next to it. Once you exit the Edit mode, the fields that contain nothing are hidden, so you have absolutely no indication that your e-mail address is in the wrong field.

This particular problem has actually happened to me a few times. I couldn’t get Mail to autocomplete an e-mail address for me, even though the e-mail address was clearly there in a card in my Address Book. I couldn’t figure out why it wouldn’t autocomplete the e-mail address. Finally, I realized that I had mistakenly entered the e-mail address in the “work” phone number field! If you do that, then of course Mail will not actually recognize the e-mail address as an e-mail address and will not include it in its autocomplete feature.

There is also another problem with this way of labelling the card’s text fields with grey text in the fields when they are empty. The problem is that this grey text is automatically removed from the field and replaced by the data you are entering only if you do things as expected. The other day, I mistakenly pressed a cursor key before starting to enter my data, and here’s what happened:

First, I created a new card, and Address Book switched to Edit mode by default automatically. I tabbed into the “First Name” field, and the “First” text in the field was selected by default, as expected:

But then I accidentally pressed the Right cursor key:

Note the insertion point in the field. Then I started typing the first name. And here’s what I got:

Obviously, this person’s first name was not “FirstMary,” and I never typed “First.” It was the default grey text, which Address Book failed to delete because I had accidentally pressed the Right cursor key before starting to type.

This simply should not happen. And it’s the same with every field in the card that contains grey text by default when it’s empty—i.e. most of the fields, except for the last one, the “Note” field.

The problems don’t stop here. I am a fast typist and I hate having to switch from the keyboard to the mouse and back all the time. So I use the text selection keyboard shortcuts in Mac OS X very often: option-shift-Right to extend the selection word by word to the right, for example, and option-shift-Left to extend the selection word by word to the left.

In the context of a database-driven application, I expect these keyboard shortcuts to work within each text field that I might be editing. And they do work in Address Book in Edit mode. The problem is that they don’t stop working when you reach the boundaries of the text field that you are editing. If you editing the “First Name” field, for example, and you press option-shift-Right to extend the selection word by word to the right, here’s what happens:

I suppose that there are some people who might argue that this is actually a useful feature. And there are indeed a very small number of scenarios where extending the selection beyond the field currently being edited might be useful. But I am afraid that, in most scenarios, it is not useful, and it is not a desirable behaviour.

See, when you use keyboard shortcuts for text selection very frequently like I do, you often have to press them repeatedly in quick succession, in order to select a bunch of words, for example. And in such situations, you frequently “overshoot” by pressing the shortcut too many times. You then have to backtrack by pressing the opposite keyboard shortcut.

But there is little risk of overshooting in a text field if the selection stays within the boundaries of the field. You can safely hit the keyboard shortcut as many times as you want; the selection will stop at the end (or the beginning) of the field.

That’s what happens in dialog boxes used to edit data, such as the track information dialog box in iTunes. When you edit the text tags for a track in iTunes, the text selection shortcuts work just fine, but within each text field. They don’t work across text fields! Similarly, in FileMaker Pro, the text shortcuts work just fine, again within the boundaries of each text field.

The problem in Address Book is not limited to this particular field. It affects all fields in a card. And it doesn’t affect the text selection shortcuts exclusively. It also affects text selection with the mouse. You can also use your mouse to click and drag across multiple text fields in an Address Book card in Edit mode. This behaviour might make sense in Browse mode, where you might want to select the contents of multiple fields to copy it to the Clipboard so that you can paste it in another application. But what’s the purpose of this behaviour when editing cards in Address Book?

Again, I fail to see how this can be useful except in a very small number of theoretical scenarios. And because of this, it’s far too easy in Address Book in Edit mode to overshoot either with the mouse or with the keyboard and select more than what you meant to select.

Finally, here’s a scenario where this behaviour is not only useless, but actually buggy. Say you are in the e-mail text field, and you already have an e-mail address in it. Your insertion point is at the end of the field, like so:

Then you start pressing option-shift-Left repeatedly to extend the selection word by word to the left. Here’s what happens. First you select the portion that comes after the “@” symbol:

Then you select the entire e-mail address:

No problems here. This is expected. But say you press the shortcut too many times. (You overshoot.) Here’s what happens. First you select the “work” label as well:

This is still OK. It’s useless, but it’s OK. But if you press the shortcut once more, you get this:

The e-mail address is no longer selected! Instead, Address Book actually selects the previous field! And if you try to correct your overshooting by pressing option-shift-Right to reduce the selection, here’s what happens:

Eek. Now we’re really in trouble! Might as well give up and start all over again!

If the previous field already contains some text, then you might get this type of correction when you press option-shift-Right once:

But then if you press the option-shift-Right shortcut again, nothing happens, and Address Book refuses to reduce the selection to include the e-mail address only again.

I am afraid that this behaviour is not only useless, it’s actually buggy. There is no way that this sequence of keyboard shortcuts should actually cause the e-mail address to become deselected at any point.

So there you have it. For the sake (presumably) of simplicity, Apple has actually created a database-driven tool where data entry works in non-standard ways and requires constant adjustments on the part of the user (who is used to other database-driven tools).

I suppose I should also note that the text input in Address Book, even though it is, presumably, a Cocoa application, fails to support direct text replacements via the input method. This means that, if you use an Input Method tool such as Spell Catcher X, you need to make sure that the option to make direct replacements (without backspacing) in that application is turned off for Address Book. Other wise, Spell Catcher’s automatic text completion and glossary features won’t work properly.

If you don’t use Spell Catcher X, you don’t have to worry about this. But it’s yet another indication that Address Book does things in a proprietary, non-standard way.

This entry was posted by Pierre Igot on Thursday, November 10th, 2005 at 6:57 pm and is filed under iTunes, 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.