Live Threaded Chat

This white paper compares and contrasts asynchronous forums, particularly threaded forums with synchronous chat, and then proposes a hibred of both to provide the advantages of each.

Comparison

Threaded forums allow messages to be posted at any later time in response to a specific message or a thread of messages. In some systems, adding a new messages at the top level of a forum is referred to as "creating a new thread" to distinguish that from merely adding a reply. All the messages in a forum are stored persistently either in a centralized place that is accessible to the readers, or the messages may be replicated on several servers or emailed to participants. The persistence is what allows the asynchrony, and that is an advantage when participants cannot meet at the same time. The distributed access is an advantage for large numbers of participants who are themselves distributed geographically.

Chat systems are typically synchronous, at least to the degree that each line is sent to all participants as it is entered. The immediacy of the communication has some of the feel of live in-person chatting, although the delay between one-line messages means that participants can engage in multiple conversations simultaneously. Some chat systems support character-at-at-time synchrony which has an even stronger feeling of "presense", but as a consequence it is more difficult to have multiple simultaneous conversations. Still, character-at-a-time chat is not as immediate as live voice and video. Virtual reality worlds give another sense of "like really being there", and several systems offer text chat in that context.

The goal seems to be immediacy because that leads to a sense of really communicating with the person, but there are some advantages of chat systems in not being quite so present. Specifically, there is a little time to think on your own, to edit one line or one phrase or sentence, and to read other messages while waiting for a reply to your previous message.

Chat systems tend to be centralized, unless there are only a very few participants, just to get the scalability up. In a centralized system, each message (e.g. a line) is sent from the author to the system, and then it is typically broadcast out to all the participants.

One of the main differences concerns the rapidity of updates. Synchronous systems have a comparitively rapid update of messages, that is, the amount of time that passes between the time a message is created and when it is received by other participants. In contrast, asynchronous systems are not nearly as concerned with rapid update since the participants may not even be on-line at the same time. Furthermore, some participants who primarily only read messages (and rarely write messages) may prefer to receive a digest of several messages at once rather than one message at a time as it is created.

The threaded vs non-threaded structure of messages is an issue independent from the issue of synchronous vs asynchronous updates. But chat systems are invariably non-threaded. Why is that? Partly it is attempt to simulate the in-person audio chat where one person talks at a time, so as time passes, the discussion can be described at a low level as merely a sequence of messages with no relationship between the messages other than time ordering. Inferring the relationships is actually a very difficult problem, whereas having users specify relationships is usually too much of an additional burden.

In contrast to what is explicitly supported by chat systems, in terms of the struture of discussions, real chat sessions with as few as two participants may result in very complex implicit relationships between the individual messages. Two people might be replying to each others messages, while two others are having their own parallel conversation, but everyone may read all of the messages. While waiting for a reply, one can create other messages, possibly adding yet another conversation to the mix. A message may reply to or make implicit reference to several other messages, or to the gist of the conversation as a whole. (By the way, all of this is true whether the messages are delivered with short or long update times.)

Forums have the potential be threaded, but moreover, the asynchrony almost makes threads a necessity, especially in a distributed system where the participants typically do not see all of the messages at the same time. This is a major reason that Usenet messages are threaded, although not all news readers support the threading. Similarly email messages are threaded, though not all mail readers support the threadeing.

Without threads, in a single asynchronous forum, a message might have been written in response to a message that is days old, but there is no way for the reader to figure out what the context is unless the original message is essentially copied. In fact, quoting is frequently done on usenet and email partly because we lack the assurance that readers have systems that support the threading. Another common convention is attaching the whole original email that one is replying to.

Furthermore, the ability to reply to particular messages in a threaded forum requires a degree of asynchrony since it is often some earlier message that one is replying to. If it were always the latest message one replies to, or if there is no response chain ordering at all but only time ordering, then there can be no threading either.

Most chat systems do not store transcripts of chat sessions persistently, though there are a few exceptions. Partly the reason for this lack of persistence is the lack of desire by anyone to read the transcripts. With multiple discussions going on simultaneously in a single chat session, it is difficult to follow a train of throught unless you were there as one of the participants.

Merging

Part of the process of merging the systems invovles merging the terminology. We can either find new neutral terminolgy, or adopt one or the other systems terms, or create new terms that are a combination of terms from both domains.

The primary difference between synchronous and asynchonous collaboration systems in general is merely a difference of the time to transmit messages. As such, the difference can be converted to a range from slow to fast delivery and notification time. When participants are actively present in a chat-forum, they can be notified almost immediately when new messages arrive. For participants who are off-line, obviously they cannot be notified about new messages that have been posted, but must wait until they are again on-line. Some participants may choose to only receive a digest or summary of previous messages even though this imposes a considerably longer delay.

To merge the threaded forum structure with the unthreaded chat structure, we could either make both threaded or both unthreaded. Since we argue that asynchronous collaboration requires threads to be effective, we need to make the synchronous chat mode use threads too.

The main obstacle for adding threads to chat is that users must have a simple way to specify which message they are responding to. What follows is a proposal for one way to do that. It assumes that people will want to remain active in a few conversations while observing a few others, and relatively infrequently change activity status, from active to inactive and vice versa.

Certainly the display of the threads of conversation should reflect the structure of the threads. But it should also be possible to switch to a chronological order regardless of the threaded structure.

The display of the threads that one wants to either observe or actively participate in should be visible in one window. Multiple windows, one for each conversation, might be feasible or desirable in some cases, but it shouldnt be required. Part of the issue is that a single conversation can split into multiple threads, many of which have a limited useful life, so why create new windows for each?

The replies to observed threads should also be displayed, but the full thread is not as interesting as the most recent few messages, so the older messages should be hidden by default. Scrollable windows are used to hide material that cannot fit in the available space, but we should probably use elision (e.g. '...') here instead because we have potentially several threads to keep track of in a single window. Any part of the tree of threads should be hidable or showable with a single click. This is like an outline editor, but with portions hidden other than complete subtrees. For the parts that are visible, new reply messages should also be made visible by default. For the parts that are hidden, there should be an indication of the number of hidden messages and the number of new messages that have not yet been seen.

For the threads that one wants to participate in, there should be a set of keyboard-only commands for selecting which message to reply to, entering a reply message, and switching to the passive observer state. It should be possible to do the most frequent actions via keyboard only to avoid switching to the mouse.

For example, successive active messages could be selected using the Tab key. The currently selected message should be highlighted in some visible way. When you reach a message you want to reply to, simply enter the message and hit return to send your reply. The message you replied to should then be made semi-inactive (because you probably don't want to reply to the same message twice but you may want to reply to other replies to that message or to your reply). Also, the next active thread should be selected automatically in preparation for a reply to that message. To switch to passive mode for a selected message, simply hit return to enter an empty message.

When a message is a reply to any earlier message in one of your active threads, thus creating a new thread, it should also be made active. You can deactivate it if you wish when it is selected by entering an empty message.

To reply to a message in a thread that is not currently active, a mouse selection is probably required to make it active. Other keyboard commands to select messages in these inactive threads would probably confuse matters, and would probably not be used much anyway.

So here are some definitions distilled from the above.

• An active message is one that you may want to reply to, so it should be in the selection cycle (repeated Tab keys).
• One active message can be the selected message to which actions apply, such as adding a reply.
• An inactive message is one that you do not want to reply to, so it is not in the selection cycle.
• An active thread is one that you are watching. It is a thread (a message and its replies, recursively) in which any new replies in the thread are active by default when they first show up.
• An inactive thread is a thread in which new replies are inactive by default.
• (...) A hidden thread may or may not be active, but the messages in the thread are not visible currently. The message at the top of a hidden thread is not hidden by the thread itself, but it may be hidden by a higher level hidden thread.

Example

	testing
	1 2 3

1995, Aug 01 | Sara Jane How To Do Threads 1995, Aug 02 | Daniel LaLiberte On this site, you ask. 1997, Jan 16 | Alicia Coolidge Hypernews installed without informations.html 1997, Jan 16 | Daniel LaLiberte Use these instructions 1997, Jan 16 | Alicia Coolidge /_ Thank you 1997, Jan 16 | Daniel LaLiberte /_ You're welcome Jan 30, 13:46 | Ferd A Nerd WHY? Jan 30, 22:31 | Joe Hardly What do you mean by the verb "thread"? Jan 31, 12:34 | ... (5 messages) 1996, Aug 29 | Eric Lofland can I use this file for help on my setup?? 1996, Aug 30 | Daniel LaLiberte Please do use this instruction - customized to your needs.

Add Message:

Related Systems

Some people refer to "threaded chat" but they mean the asynchronous variety that we are calling "threaded forums".

Many web sites offer both asynchronous forums (whether threaded or not) and synchronous chat, often side by side. But no one seems to be attempting to merge them into one system.