Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

The web app I'm working on (a social network) allows users to chat and send each other messages. This is not the main focus of the app, but it will be used quite a lot (these conversation need to be saved, so it's good to have a unified tracking).

I was thinking about facebook's integration between chat and messages and wondering if it's a good practise and if it's applicable to my case. What are the advantages / disadvantages of having only one system / interface for chat and messages in opposition to one for each of them?

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted

Science: I've read a study last year, saying that the younger generation is unable to differentiate between communication channels: they do remember what did they send to who, but they just can't remember how did they send it.

A quick informal survey on 25-35 year old power users (geeks, hipsters, you know, what friends shall a developer have?) confirmed that it is also the case for their demographics.

On a different perspective, facebook still differentiates between communication channels. Look at the icons closely:

Facebook chat unintegration

There are mobile, "mail" and IM messages as well.

I don't think that the "subject issue" is appropriate here: subjects are usually part of formal communication, and it's an "advanced" feature it seems: I always get private mails without subject or without meaningful subject (like "Hello" "How are you?" "Ping" etc). I'm also yet to find out if my Mother had already seen there's a long input field above the message body box, albeit she's got her own e-mail address for her 50th birthday, hardly an internet native.

Subject sets context. Private communication rarely needs explicit context, albeit it depends on the amount of information needed to be parsed, and wether the social context does set the context (eg, if it's a social network for dog-lovers, the subject is set by the site context itself: it's likely that it'll be about dogs.)

Google Wave avoided this problem by setting the first line in bold. If it was "Hi," or "Hello", then that was bold. I continue to do this on FB-messages: first line is topic, two enters, actual mail.

A problem still exists with conversation continuation. I hate when FB throws in a huge mail-like message into a chat or mobile msg window. Yet history is an important tool to set conversation context - this was the last thing you've talked about. That's why it's employed by popular IM tools, like Skype.

Now let's go back to science and ask ourselves a big question:

what is the difference between chat and mail?

And for that we can grab the old science report, Interaction and Outeraction from around 2000, which was originally linked a few days ago by someone in a different topic here.

The main difference is that chat is quasi-synchronous communication while e-mail is asynchronous communication. That is achieved by the following measures:

  • Presence - Presence is the availibility to communicate. Whenever we talk about presence, we talk about passive or active communication about one's reachability. With chat, I should know about the other's availability to communicate.
  • Quasi-immediate message transfer - I think that's obvious. Namely, chat response thresholds should be under 1 second in order to be felt synchronous. This is the "awkward silence" limit. For details, refer to Chapter 12 in Jeff Johnson's book, where he cites the science needed.
  • Typing indication - of course, the above line is nonsense from a typing perspective. In the IRC times, we lived in a constant frustration (*)
  • Short messages - are an immediate result of keeping up conversation flow, unlike at SMS, where it has protocol and usability reasons (remember 90s phone keyboards?)

However, it's not synchronous in the sense that it doesn't necessitate constant focus from all participants, exactly because the known roughness of its presence indications: every once in a while, an IM service (network or client) tries to solve this by sending an 'away' presence when the conversation gets out of focus (eg. user switched windows or tabs). The result is usually frustrated contacts and regression in the next release.

With physical presence, it is immediately obvious when someone doesn't listen to you, and depending on the context and culture, you might or might not find this rude.

Since it is asynchronous, mail needs the constant use of timestamps, as the participants aren't expected to be part of the same session, same context. Chat doesn't need this and it just breaks the flow usually, it's an unnecessary UI element (unless there's a conversational gap).

On the other hand, in order to understand possible order issues with chat messages, it's important for chat archives to contain timestamps precise-to-seconds. They're instantly recognizable on the spot (simply as it'll likely arrive under the cognitive deadlines), but they can be easily confused afterwards, or when forwarded. This is how it is done in Adium archives, or when you copy-paste text from Skype.

With chat, the issue with messages received while there was a transient error (like, network loss) needs to be addressed. Also, the issue of multiple devices (called multiple points of presence in Windows Live vocabulary, resources in XMPP vocabulary) needs to be handled, when it is time to do a chat session takeover. There are looong and boring protocol specifications about this with UX consequences...

Context: for chat, the context is always the previous chat, and when it was done. For mail, it's a different issue (as it can be that we start a totally new context by writing a new mail), but usually the last received mail is the context, and its text should be visible when composing.

Does Facebook solve all these right?

I think no. The FB messaging part feels a bit chaotic to me, both as a user, a UX-ish guy, and a protocol designer for chats, it's like they don't really know what's going on. That also shows up with protocol issues (eg, sometimes it tells you there's an unread message in the "Messages" app menu, but it doesn't tell you that you have a new message in the top bar menu, sometimes it's the opposite). It's not that easy, and I guess there's some disagreement or misunderstanding inside the team, or at least inside the code.

Does Google solve this right?

Google handles chats and mails as separate mediums. It's not entirely bad, but if you're silent for half a minute, it starts a new thread, making reading chatlogs difficult. It's certainly a cleaner job chat-wise than what happens at Facebook, yet it's much worse integration-wise.

The same goes for Yahoo!, albeit there, the tab solution makes it strangely orthogonal to the site.

What about Microsoft?

I guess Microsoft with the new Hotmail.com interface is the closest to the truth UI-wise: if 4 friends write to you on Gmail, you can't read your mails. But that's just perhaps my opinion. However, they don't handle chat archives on the server-side at all, which can come from legacy protocol design.

Personally, I did some chat interfaces (like this or this), but these are about conversation windows, not about chat archives.

Shall you mix the two?

It's up to you. Remember, FB didn't solve it throughly, and the rest of the crop avoided the problem in its entirety. But where would humanity be, if we didn't have brave people who do something well first?:)

(*) Personal research: I did the mistake of talking to my teenage love through IRC daily, it was the most frustrating thing ever... does she write? why doesn't she? Typing indication wasn't even invented yet. Albeit that could also get crazy - my Mother doesn't understand the fundamental difference between e-mail and chat message length, and I'm used to not standing up from a chat when I see the typing indication. Worse: if I'm not answering in 1 second, I'm considered rude.

share|improve this answer
1  
Thank you for a fantastic answer! I am tempted to try something in between the two, because I find the lack of a viable alternative quite inspiring, to be honest. It's somehow comforting knowing that it hasn't been solved successfully. I'll check the references and give al this a try. –  Yisela Aug 7 '12 at 2:28
    
"Private communication rarely needs explicit context" wouldn't you consider this an opinion other than a fact? I find it hard to believe that that's the case. Especially on a business environment. –  edgarator Aug 7 '12 at 4:08
    
@edgarator how is a business environment private? I think by private Aadaam possibly meant personal private not business private, ie friends amongst eachother as opposed to colleagues. And friends indeed rarely need explicit context –  Marjan Venema Aug 7 '12 at 5:53
    
Concerning Facebook, maybe a part you haven't considered or at least mention is the mobile-side experience. Lot of people and especially teenagers and 20-something use Facebook messaging like whatsapp, iMessage or BlackBerry messaging. With this idea in mind, maybe Facebook implementation is not done right today but conceptually it doesn't seem bad. –  Geraud.ch Feb 14 '13 at 13:53
    
@Geraud.ch: the concept still isn't clean I guess at Facebook. Regarding SMS-style usage: SMS is a strange beast as it regards presence as ubiquitous, that is, an SMS user is like Schrödinger's cat, both available and not available at the same time. The "seen" solution is a good call. However, I guess you agree that you are surprised when you get a mail-like long writing to your phone this way and you take it a bit rude when someone answers a short line without greeting or signature to a mail. This is what this mix causes, and we were talking about mixing the two channels. –  Aadaam Feb 16 '13 at 13:24
show 1 more comment

Some Background

Integrating chat and email is a good idea if undertaken properly. You can either have someone chatting to someone else online with the instant messenger feature, or having someone chatting to someone else offline, and prompting the user to send an email afterwards, as email can be easily retrieved from an email client.

Think about Google Chat, for example (I don't know if that's the name, but I'm oviously talking about the one that you find within Gmail). If the user has gone offline, then you're prompted to send an email instead (on a different interface). Taking out of context a single message might become confusing if not handled properly by the system.

I think you need to think your process thoroughly. People might find the simplicity of the chat annoying if they are only given that option, but having email and chat working together can become a power combo.

So having said that:


PROS of Facebook Like chat/email:

  • One single place hold the whole conversation
  • It's simple to use
  • Provides an easy way to understand what happened before and after

CONS of Facebook Like chat/email:

  • Bad for Attachments (you need to scroll to find them)
  • No Subject field, delimiting where a conversation started might become a difficult task: Having one single conversation between two people among different topics becomes a burden, as people need to actually navigate all the way through the conversation to find somethin that they wrote.
  • Reviewing more than one email/chat account might add complexity to the process.
share|improve this answer
add comment

if chat vs messages mean something substantially different then a different interface is warranted. exactly how different the divergent interfaces are depends on ease of use vs making the distinctions. each different looking interface demands additional thinking by user to use it. in the case of facebook, since the whole aspect of the parties being present concurrently is somewhat abstract in this virtual world, the interfaces converge. it allows opportunity to start off with a message and do live chat if both parties present, without switching to vastly different ui.

share|improve this answer
    
Hmm I think I explained myself wrong, by interface I mean having a unified system (not a unified design), I will edit :) –  Yisela Aug 6 '12 at 22:09
    
if you mean the backend being same...saves development time. both message and chat can function exactly the same: a logged in user is shown a message meant for them. the subtle difference in meaning of chat vs message is mainly implied by humans. –  Chris Aug 6 '12 at 22:17
    
I mean from that human point of view, how user would react to one or the other –  Yisela Aug 6 '12 at 22:21
    
i think the distinction between email and other electronic messaging is mostly based on ingrained experience, especially memories of older or existing such systems. the ux blurs more and more as web chat goes ajax and can easily provide attachment, mailbox and message thread functionality. older style email clients sometimes fall in favor of web ajax interface to mailboxes. all the transmission behind the scenes is asynch. so there's very few real heuristical differences, which may or not be a limit or be prominent in a user experience and ui. unless u want only an appraisal of facebook? –  Chris Aug 7 '12 at 7:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.