Matt Gemmell

TOLL is available now!

An action-thriller novel — book 2 in the KESTREL series.

★★★★★ — Amazon

iChat iRritations

interface 17 min read


I’ve been using iChat

more or less since I installed Jaguar, and a fair bit more lately, since I started this series of UI articles. I previously mentioned a few aspects of iChat’s UI that I really like, but sadly there are at least as many which are odd, inconsistent, or just plain wacky. This article outlines a few of them.


Before we really get started, a quick note of thanks to all the zillions of people who have commented, trackbacked (tracked back?), linked and/or emailed me regarding my previous articles. We’ve been on, Daring Fireball, and scores more sites. I particularly enjoyed Stereoboy’s assertion that my previous NSSchizophrenicControls post “is, by this point, a classic.” ;)

All the discussion has been, and continues to be, great - thank you! I really enjoy talking about UI, and I plan to continue doing so - I hope you’ll all continue to help me explore this key aspect of Mac OS X.

I’d also like to draw your attention to Kevin Fox’s post at regarding inconsistencies in Apple’s UI for play/rewind/ffwd buttons in Quicktime Player, iTunes, and both the previous and current versions of iMovie. Note particularly his anecdote about dealing with Apple’s UI people when he was at Yahoo and working on Yahoo Messenger. A very interesting read; thanks to Kevin for pointing me towards it.

With all that said, on with the list.


New Message window

As you can’t help but notice, iChat pops up a translucent, white-coloured window when you receive a new instant message (as opposed to a further message in a window which is already open). It looks a bit like this:


If you’re worried at this point that I’m going to rant about how it’s yet another style of window, don’t worry - we’ll leave that for another day (when we’ll also talk about Safari’s custom metal windows, and the “synchronization warning” window in iSync ;)). The problem isn’t with the appearance of the window, but rather its behaviour.

Firstly, as Vinay pointed out previously (when he also opined that iChat “really is the super-villain of UI baddies”), when you click into such a window to display the full message, the window expands to give you a text-entry field, some buttons (about which more later), and so on. However, if you then click back out of the window without replying, the window collapses and returns to its semi-transparent state again. This breaks the visual metaphor that “white and translucent = new”, and instead tells you that “white and translucent = new and not yet replied to”, which seems like a useless distinction from simply “new”. The window should acknowledge that it has already been focused (and thus, very likely, had its message read) by thereafter remaining as a normal iChat window.

Secondly, a much bigger (and much more insanely annoying) problem. If iChat is already running when you receive a new message, everything is more or less fine - it shows the translucent window, which you can attend to whenever you like. BUT, if you receive a new message when iChat isn’t running, iChat comes to the front.

Picture the scene: you’re merrily typing into your email client, sending a love-note or a scathing personal attack or even some legitimate work-related missive, when suddenly the field you’re typing into loses the focus. Your keystrokes are now going into thin air. iChat appears, animating the Buddy Window in a leisurely fashion, then shows the transparent window. If you’re anything at all like me, you now bear an irrational yet understandable grudge towards the person who messaged you - because iChat saw fit to interrupt what you’re doing. You’ve just been yanked out of whatever you were doing, probably suffered a moment of panic, and lost your train of thought and a chain of keystrokes - all so that iChat could inform you that someone has sent you an instant message. That’s just awful.


Chat window metal buttons

Ah, iChat’s metal buttons. I’ve spoken about these before, as has Erik, and Vinay also discussed them in his aforementioned article. Here they are:


From left, the buttons: toggle the “participants” drawer, toggle bold styling, toggle italic styling, insert a smiley from a popup menu, and show a sheet to choose a file to send. Needless to say, there are problems there:

  • The bold and italic buttons should show state. Right now, they always look as they do above (unless they're being clicked). They do not look "pressed-in" when the selection includes text which is bold and/or italic.

  • The "participants" button should have some kind of indicator showing that it toggles a drawer. A left/right arrow might do, or even a little graphic of a drawer, as used in many apps including NetNewsWire.

  • The Smileys button should definitely include a down-arrow graphic to indicate that it pops up a menu. Otherwise, it looks like a one-shot "insert smiling face smiley" button.

  • The Attach File button should be disabled if you can't send a file because the other person's messaging client doesn't support it. Right now, you just get an impotent beep.

I’m happy enough with the appearance of the “attach file” button (lack of intelligent disabling notwithstanding). I’m not sure what you could do to it to make it more intuitive, other than perhaps adding a text label such as “Choose file…” or similar.


Buddy List mini-buttons

These buttons, aside from being yet another type of custom button, exhibit much the same problem as the Chat window buttons: they perform very different functions, but have no visual indicators of this, nor any grouping to help explain their relationship to each other. Vinay mentioned these too.

From left, they: show a menu to set view options for the Buddy List window, show a sheet to add a new buddy from your Address Book contacts, show info for the selected buddies, send email to the selected buddies, and send an instant message to the selected buddies. So, immediately we see some problems:

  • The buttons should be grouped. The first two act on the Buddy List window itself, whereas the rest act on the selected buddies. There should be some space between the two groups to emphasise their different targets.

  • They view button should have a down-arrow graphic to indicate that it pops up a menu of further options.

  • The icon for the view button should be changed. As it is, it says "List View" to me. My expectation for such a button would be to toggle between list view and some other view, perhaps an icon view. Ironically, a practically identical icon is used in iCal to toggle the display of a full list of all calendar-events. In iChat, it's "view options menu", whereas in iCal it's "toggle list". Nice.


Buddy Info windows

As mentioned above, there’s a “buddy info” button at the bottom of the Buddy List window; it’s the one with the “i” icon in the previous screenshot (not the visually-very-similar “!” icon, by the way). Clicking it produces a window of information for the selected buddy, including information from your Address Book card for that buddy. The problem is, you can open multiple Info windows for the same buddy.

Despite my screenshot, they don’t even tile - each new info window perfectly obscures the previous one, giving the false impression that the same window has been reused for the new information. A more serious issue, however, is that multiple Info windows for the same buddy don’t all update when you edit one of them. So, if you make two different changes in two different windows, the last one you save wins - all your other edits are lost. Nasty! This could readily be solved by, say, only allowing you to open one Info window per buddy. Like the Finder’s (recent) “Get Info” behaviour, you might say.


"New Chat"

iChat’s File menu has a “New Chat” option. My initial impression was that it would create a new instant message session with whomever you had selected in the Buddy List. I think that’s a reasonable expectation.

However, that’s not what it does at all. In fact, it opens a new empty chat window, without any participants (other than yourself). I can’t think of a situation where I’d want it to do that, unless I had no-one selected in the Buddy List (in which case I think the command should actually be disabled). What you need to do after making your empty chat window is drag people from your Buddy List into the “participants” drawer. That’s bizarre enough in itself, but the really wacky thing is that this odd “New Chat” option gets the standard command-N keyboard shortcut. Surely command-N should make a chat with the people selected in the Buddy List? This is so strange that I rather suspect I’m missing some fundamental feature or explanation. Can anyone help?


"Add Hyperlink"

Another menu command, this time in the Edit menu: Add Hyperlink.

It’s a good command to have (especially with a keyboard shortcut), since it lets you create a link and give it a custom title all in one action. You can type the text you want to be a link, select it, then invoke Add Hyperlink to get a clickable link, instead of having to type an ugly URL enclosed in chevrons. The problem is, it’s always available. Even if there are no chat windows open anywhere, in which case it does precisely nothing (not even beep).


Mind-reading in new chats

When you’re typing a message in iChat, before you actually press return to send it to the other participants, you see a little thought-bubble beside your name or icon (if you have the speech-balloons enabled, of course). That’s nice, because it lets everyone know who is currently typing something, to help avoid multiple people talking at once, or to reassure you that the other person hasn’t lost their connection or such.

The key point is that the thought-bubble only shows if you actually have some text in the entry field… unless you’ve just started a chat. When you initiate a chat, and get a new window, the thought-bubble is already there - even though your message-entry field is currently empty. iChat is reading your mind, hearing you compose your opening message before you even touch the keyboard! Several times, I’ve wondered if I’ve accidentally typed a whitespace character in there, and needlessly done a select-all to try and delete the invisible culprit. iChat should choose one behaviour and stick to it - the thought-bubble shouldn’t be there in a new chat window until I’ve actually started typing.


Buddy Window status area

In the Buddy Window, beneath your name, iChat shows your current status. In the screenshot below, my status is “Back in a bit”.

As you can see, when you move your mouse cursor over the status display, it becomes a pop-up button (a custom one, of course), which when clicked shows a list of all the different status messages you’ve defined. Here’s the issue: the active (clickable) area of the control changes depending on the width of the current status message. For example, if I were to position my cursor over the little down-arrow in the status area in the previous screenshot, then click to show the menu, then choose “Away”, the active area of the control would shrink to be just wide enough to cover “Away” and the down-arrow (which is always drawn immediately to the right of the status text). Like this:

So, if I was to click again, without moving the mouse, the menu wouldn’t appear. Clicking again in a location where, only moments ago, a click produced a menu, now has no effect. I need to move my cursor to the left until it’s over the down-arrow’s new location in order to access the menu. You can imagine how annoying that is if you accidentally choose the wrong status message from the menu (which is a common enough thing). The active area of a control should remain the same regardless of the width of its label text. NSPopUpButtons don’t resize every time you choose a new option from them, do they? Not yet, anyway.

Oh, and one more thing; one of the classic problems with implementing custom controls instead of using the standard ones: control-clicking on the status area produces the menu as expected, but positions it like a contextual menu. This is in striking contrast to a regular NSPopUpButton, which always shows its menu in the same place regardless of whether you click or control-click (as it should). If you use standard controls, you benefit from the fact that all these situations have been seen long ago, and the control implementation has been coded to behave sensibly. When you reinvent controls each time, you forget about certain possibilities and situations, and neglect to reimplement basic functionality that everyone else gets for free with standard UI elements.


Preferences: Accounts

Here are the “Status Settings” options within the Accounts panel of iChat’s Preferences window:

What puzzles me is why the “When I quit iChat, set my status to Offline” option is positioned such that it’s subordinate to the “Show status in menu bar” option. I don’t see why the “offline when quitting” option should be in any way dependent on whether or not you choose to show the iChat menu extra.

In fact, surely it’s more logically related to the “When iChat opens, automatically log in” checkbox? It’s not subordinate to it, either, but if there was to be any grouping, the logical arrangement would be to group the “offline when quitting” and “log in when launched” options together, and put the other two options in another group together. I don’t actually think any grouping is needed at all (there are only four options, and it would be a shame to spoil the clean, open appearance of the Accounts pane in general). The “offline when quitting” checkbox should be aligned with the other three, not subordinate to some mostly-unrelated other option.


Preferences: Messages

A minor point now. iChat lets you automatically save chat transcripts to a specified folder. That’s great; I leave the option enabled all the time. The problem is with the UI for that setting.

I can’t actually recall where I save my transcripts. I made the choice long ago, when I installed Jaguar and launched iChat for the first time. I presume it’s in a subfolder of my Documents folder (I just checked; it is indeed), but I don’t want to have to click “Show Folder”, then be switched to the Finder, then have to command-click the window’s titlebar, just to find out. There should be a simple little text field giving the path of the folder, maybe relative to your Home folder. Is that so much to ask?

As a side-note, even the “Show Folder” button is confusingly named. When I saw it, I expected it to reveal the folder in the Finder, i.e. to open the parent folder of the folder which contains my transcripts, and pre-select the transcripts folder so I can open it if I wish. Instead, it opens the actual transcripts folder. To me, that’s not “Show Folder”; that’s “Open Folder”. Maybe that’s just me.


Preferences: Privacy

Last but most definitely not least-annoying, the Privacy preferences. I talked previously about how much I like the little doorhanger icon used for the Privacy pane of iChat’s prefs. Unfortunately, the rest of the pane doesn’t tickle me quite so much. I remember when I first saw the popup button at the top of the Privacy pane; my reaction was one of puzzlement. Here’s a pic.

“Allow anyone” is the default option. My immediate question was “to do what?” It turns out that, if you hover your mouse over the popup, a tooltip appears to give a slightly better explanation, but that’s missing the point: the label for the control is “Privacy level”, and the initially-displayed setting is “Allow anyone”. Allow anyone to have some privacy, or what? The explanation is actually displayed much further down the window, below a list-box, and is shown in small text which makes it look like it applies only to the list-box. Clever.

It doesn’t end there. That innocent-looking list-box below the popup is an accomplice in some serious UI madness. It turns out that, rather than being a single list, that list-box shows two different lists, depending on what option you’ve selected in the popup. In order to explain, first I need to show you the options in the popup:

The list-box is empty if you’ve chosen “Allow anyone”, “Allow people in my Buddy List”, or “Block everyone”. Empty. Anyone you’ve entered into the list seems to be erased, though they’re actually just hidden. That’s extremely upsetting, especially since you need to type people’s AIM or names into the list-box yourself; no fancy “choose a person from the Address Book” sheets here. The people reappear when you choose one of the other two options… sort of.

You see, there are actually two different lists being managed: your “allow” list and your “block” list. Your “allow” list is shown in the list-box when you’ve selected “Allow people listed below”, and your “block” list is shown when you’ve selected “Block people listed below”. You can imagine the fun you can have switching between the various options, watching people appear and disappear like magic, and seeing the “+” and “-“ buttons enable and disable. Needless to say, this is hideous UI. It’s practically guaranteed to cause floods of emails to Apple, of the form “I wish iChat wouldn’t erase the people in my block-list when I temporarily change to “allow everyone”. Or perhaps the actual emails would be decidedly less polite.

The irony is that iChat already has a reasonable UI for handling two lists at one time, and allowing items to be moved between them: the status messages editor.

That would work perfectly for editing your “allow” and “block” lists, and even let you quickly switch someone from one list to the other. The lists could simply become visually disabled if you chose to allow or block everyone, or to allow just those in your Buddy List. It would be a hell of a lot better than seeming to just erase your whole painstakingly-typed-in list every time.



I’m beginning to agree with Vinay; iChat may indeed be the supervillain of UI baddies (presuming of course that the heroic Dogcow-man has already long ago captured and locked-up Kai Krause). Despite all this, I still really like iChat as a concept, and it manages to do some things really well (the speech-balloons which still allow you to drag-select text in the window, for example), but I really despair at some of the UI clangers it commits. One wonders if perhaps Apple got more than a messaging API from AOL. ;)

As always, I’ll be interested to hear your thoughts, corrections and additions. Thanks for reading.