Training Users (the Bad Kind of training)
More often than not, it’s a Good Thing that users can learn and adapt to new software and new situations. Unfortunately, as my advisor Dr. John Anderson showed many years ago (with emacs and “perverse emacs” no less!), there can often be what is called “negative transfer”—users learn something so well that they want to make use of their learned skills when they encounter new situations. Such is life with Jabber and iChat.
Back in the day, there seemed to be two basic approaches to instant messaging: ICQ and AIM. ICQ’s messages, for those unaware, were more like really short emails than an interactive chat session. AIM took a more IRC-like one-liner approach. I think that while these choices seem unimportant to the casual observer, they caused drastic changes in the way users worked (in my anecdotal experience, of course).
ICQ was dependent on queuing up messages. When you received a message, it sat in your list (or your taskbar tray), awaiting your approval before displaying itself. Users therefore tended to take their time composing messages (well, more time than an AIM/IRC message), possibly even typing several sentences instead of just one—or even a paragraph. This style of writing messages was aided by the fact that ICQ’s servers were dog slow. In this fashion, ICQ was much less obtrusive than your typical AIM session. When I felt like reading what people sent me, I clicked on the the flashing message icons and read through. I could then take my time and compose a reply. This all sounds rather slow, but it was still much more rapid than email. It is, as I said, somewhere between email and AIM.
AIM, I think, is the more familiar model to most people, because it is what MSN, Yahoo, and other messaging systems adopted. You have a chat history window with a tiny writing space encouraging short, quick messaging back and forth. Combine that with the fact that when you get a new message from someone one of these windows pops up in your face, and you have a much faster-paced system in which people expect that you’re reading what you type within seconds of them typing it.
The more interesting difference for this thought piece, though, is that ICQ supported offline messaging. AIM does not. You could start composing a quick paragraph to your buddy in ICQ, have them go offline, and go ahead and send it anyway. When your buddy came back online, they’d be bombarded with whatever messages were sent to them while they were offline, including yours.
I think the notion that ICQ messages were like short, fast emails in design as well as behavior was not an accident. It may not have been entirely intentional, but at some level the behavior and the design were appropriate for one another. AIM windows just don’t scream “hey I work when your buddy is offline too”.
Jabber, of course, supports offline messaging. With Gabber I was very observant of the advantages of ICQ’s system (especially the message queuing aspect), and was careful to make that a priority. I was also well-aware of the (seemingly) psychological differences between an ICQ-like short email message and an AIM-like chat window, so I included both. I called them “Normal Messages” and “One-on-One Chats” (I regret the name of the former, but not the latter).
I noticed that friends of mine who were more formal in online etiquette much preferred the Normal Message (ICQ) style, composing short paragraphs which they would send for my perusal and eventual reply. Less formal friends would use the One-on-One Chats and send quick messages, expecting more immediate response.
I often found myself sending Normal Messages when a buddy was offline and I wished to type up a longer paragraph for them to read. Initially this was part of my motivation in including Normal Messages in Gabber—I felt their email-like looks would make people more comfortable in sending offline messages. It just seemed more appropriate and comfortable, since, well, people were already used to email messages working regardless of the online status of the recipient. But after a while I stopped this practice and simply always used One-on-One Chats. I believe the same happened to my friends. Once we got used to the idea that One-on-One Chats were perfectly acceptable for offline messages as well as online messages, we just used them. Especially since Gabber had queuing for that kind of message as well, should one wish to make use of it.
More interesting, however, has been the adoption of Jabber in iChat. None of my iChat-using friends send me offline messages anymore—even those who used to use Gabber or other Jabber clients. Is this because iChat does not have any sort of longer, more formal messages? Or is it because users have become trained that you cannot send offline messages in iChat? Would things change if we had offline messages in AIM? Or have those annoying “AIM error: The person is not currently online” messages trained us that we cannot send messages to buddies who do not appear there right this second in this particular application?
I’m a strong believer in the last.
If you liked these thoughts, you should probably check out a paper I wrote on similar topics. I promise that I don’t wander off-topic as much in it.
I can’t comment for people in general. But I know I’ve stopped using Jabber offline messaging as much because, doing all this work on making stuff work with Google Talk, I’ve gotten out of the habit of ‘oh, yes, right, offline messaging is supported.’ Because, with Google Talk, it isn’t. But as I also use iChat on my Mac to test things with… I think within iChat, yes, you’re right. When the person is greyed out, we don’t think to send messages to them, because in iChat we’re trained not to.
Apropos of nothing, as an ICQ user from the early days, I have to admit the description of the servers as ‘dog slow’ made me laugh. (Not that the client itself didn’t turn into a giant, slow and bloated monster…)
[…] This very interesting article came up in my inbox this afternoon. It talks about the different approaches to Instant Messaging(IM) by ICQ and AIM and how Jabber tries to cover both options. I must admit that I can been unaware of the Offline Message features but could use them for the more complex communications—or would an email be better for that purpose anyway? It does archive so I am not sure I agree with Julian. […]
Sparks - well, Google Talk not supporting offline messaging is basically exactly the same reason. ;)
Rick (via trackback there), I certainly don’t agree that offline IM and email are the same thing. They’re very different, and I would argue that there are a lot of things I would say to people in an offline IM message that I wouldn’t bother to send a full email about.
I think you may be converting me (thanks for the comment). I help run an international project which uses Jabber extensively to keep the members in contact. These are relatively lo-tech people and a lot of the contact is just warm hugs and confidence boosters plus a help line and it is mostly done using a room. Just occasionally we use one-to-one if it needs to be more private but some messages are just for information (checking in and milestone reached etc.) and I can see that an offline IM would be ideal for that purpose.
Our members are on a mix of Exodus (PC) and PSI (Mac) so, if iChat doesn’t support offline, then I need to convince the Mac users not to change over from PSI.
Thanks
iChat supports offline messaging—it’s Google Talk that does not support offline messaging.
The old email-like IM interface never made any sense to me at all. It reduced the IM client to a [usually really badly designed] email program, that happened to deliver messages pretty quickly. The speed benefit didn’t outweigh the bad UI, the drawbacks of running yet another app, and having only a limited set of people you could message compared to email.
Other than the quick delivery, what benefit does email-like IM have?
And why does messaging offline people matter? If they’re offline it doesn’t matter that the message could have been delivered quickly.
Sorry to sound contrarian … this is just something that used to annoy the hell out of me in old-school IM programs, and I’ve never heard anyone defend it before =)
I’m not sure I’m necessarily defending email-like IM—I’m just trying to explore the differences and why people act the way they do. I’m certainly not suggesting that iChat needs email-like IM. That wouldn’t be good. :)
I do think offline messaging is important/useful, but there are reasons people aren’t using it much (the largest one probably being just that pretty much nothing supports it).
To be a bit clearer on what this is all about:
I’m basically wondering whether there’s something Whorfian (you think only those things which your language is capable of expressing) going on with UI design here. This is something I often wonder about UI. But whenever I deeply think about this stuff, it usually ends up being nothing more than a case of training and (”negative”) transfer. But maybe that’s all it takes for something to be Whorfian? I don’t really know.
As for whether or not one should use Normal Messages—I think Gabber’s solution was an interesting one for attempting to explore these sorts of thought experiments, but it only worked at all because my target audience was Linux users :) Don’t mistake me: I don’t want to see Normal Messages rise from the dead (where they probably belong for most cases).
iChat’s real issue, I think, is that its primary protocol is AIM. From what I understand of AIM’s protocol in this area, it’s basically impossible to design a good UI. People can appear offline, but actually just be invisible, so the only way to know whether or not a message can get to them is to actually try to send the message and then get AIM’s error. That’s why we get the annoying sheets in iChat windows. To make matters possibly more trained, iChat now won’t even let me double-click an offline AIM user to even try to send them a message, yet it still does what was described before—so there’s two types of training going on telling me that I simply shouldn’t bother trying to IM people who don’t appear online. (One thing which I do think may be a design issue with iChat is that there’s no quick and easy way to tell whether or not someone’s online from a chat window—you have to hope the messages were displayed in the window and read those to figure it out)
That, of course, is interesting in and of itself, in that it’s an instance of a network protocol pretty much dictating bad UI. The Jabber people don’t usually want to hear that that’s possible. :)
Julian –
You’re right about the AIM issues. AOL sometimes adds new features onto the protocol without IMHO doing everything it takes to make them work right. The “invisible” mode is one of those, introducing the problem of not being able to tell in advance whether sending a message is even possible. Another example is allowing a single screen name to be logged in from multiple computers: unlike Jabber, which has “resources” to disambiguate, with AIM you can’t distinguish between the multiple logins or control which of them gets replies.
Back when I worked on iChat, the input line was the indicator whether the other person was online. If they went offline, the input line disappeared, then it came back when they came back online. Simple and functional. But with the advent of “invisible” mode they took that out, because the user might be invisible instead of offline.
I would agree that we have been trained by AIM that sending messages to users who are not immediately available is impossible.
I run DoorManBot, which does offline message relaying on AIM. Despite being very aware that I can send an offline message just by opening another window to DoorManBot, when using the native AIM client, I find that I rarely do so.
The TerraIM client supports offline messaging by offering to relay the message if the user is unavailable. However, even when using TerraIM, I find that I am only slightly more likely to take advantage of this.
Using Gaim with buddy pounce, I still would not take advantage of sending offline messages, despite the completely native integration.
So, I would agree that AIM has users trained not to think of the possibility to communicate with offline users, even when it is possible at varying levels of integration.