Sending chat messages in real time

Question

I am working on a chat application where I want to implement real-time delivery of the texts. As in, the texts get sent as the user is typing it in their textbox (just like Google sheets show real-time changes). The option can be enabled/disabled by the user.

I am wondering what could be the broad UX implications and/or impact of such a method.

Answer 1

There are two aspects that you should consider.

The first one is purely technical - real time operations are guaranteed on RTOS (real-time operating system) only and TCP/IP is not real-time at all. Thus there will be some delay at all times - you won't fight it.

The other one has impact on the UX (OP's question), and on both the sender and the receiver.
Think about:

• all those slow typing users - the receiver will experience (and most likely get frustrated) how slow the words are typed, network delay can contribute to this
• the slow-typing users might be intimidated by the fact that their typing speed is exposed so clearly which can put some pressure on them
• all the typos the users may make while typing, and their corrective actions (and what about a spell-check on a system level?)
• what if the sender changed their mind half-way while typing a message? It was already seen by the receiver

Although such a functionality may be fun, it will take some of the anonymity and "protective wall" that the Internet offers.

Answer 2

I have some experience with a chat system that sent typing in real time. The old multiplayer game Avara had a chat system that worked this way. The most recent portion of each player's chat was displayed within the player list as they typed (only up to 6 players were supported). There was a line-by-line chat view but people rarely used it.

The major advantage I see it having had was in-game: a player could hurriedly type out as much of a message as they could, switch out of chat mode to operate the game controls, and go back to give more info — it's much more fluid than trying to write complete "lines" of text, and the display of six parallel streams of chat was more readable than it would be if these short fragmentary "messages" were displayed interleaved.

And, nobody can flood the chat because everyone's amount of screen space is fixed.

This particular system does not scale to having an arbitrary number of participants in the group (limited screen space) or having a complex back-and-forth conversation where you want a sensible history/"scrollback" to consult (because people could readily respond to half-typed things).

So if you have some kind of system where a small group of users are doing something in real-time and mixing chat with it at the limits of their attention or typing speed, I can see this being a useful idea to dust off and reimplement.

---

However, if you are making a general-purpose chat tool, I would not recommend doing this — whether in the form I describe above or simply showing not-yet-fully-entered messages in a conventional interleaved lines view — for these reasons:

• Accidentally pasting into the chat would immediately send the text, possibly including something private. With a regular chat input field, you get to preview before sending.

• Someone may be uncomfortable with having their typos on display, or other users could ridicule them for something they typed out and then thought better of. Of course, a conversation held with speech has some of these problems, but in my opinion the ability to do a mini-review before you hit enter is one of the ways text chat improves on speech.

• Even outside of definitely negative social effects, you can have people start to respond to something while it's still being edited, so that it's confusing which version of the thought people are talking about — or someone could respond to a message that was "deleted and never sent". (In a two-person chat this would matter less.)