Caffeinated Bitstream

Bits, bytes, and words.

The lost art of threaded discussions

While catching up on a mailing list recently, I was reminded yet again of my ongoing annoyance with the structure of online discussions. Many online forums and comment pages show posts one after another, in the order they were posted. This sort of linear structure (or lack of structure) becomes unwieldy for any but the smallest discussions. The author of a post may have introduced a new and interesting angle to the discussion, but you still have to wade through page after page of postings to see if there are any replies specifically directed to his post. (Here's a random example of a linear discussion forum -- 15 pages of one post after another!)

Tree-threaded discussions offer a more sophisticated approach to online forums. (This format is often referred to simply as "threaded", although linear forums also refer to their groups of postings as "threads".) Wikipedia defines this sort of message layout as "a tree-like view applying logical reply structure before chronological order." Replies are attached directly to the message being replied to, producing a tree-like structure. This is useful because the tree structure mirrors the conceptual organization of the discussion -- as discussions progress, each "branch" of the tree may focus on different details of the subject matter. When discussion goes off on a tangent or becomes off-topic, the damage is confined to a discrete branch of the tree which can be safely ignored. Grouping messages based on reply associations makes much more sense than displaying messages based on what time they were posted -- after all, the content of a post is more closely related to its ancestor and descendants than it is to posts made chronologically before or after. (Here's an example of a tree-threaded discussion layout on Google Groups.)

However, most (or all) of today's tree-threaded discussion systems fail spectacularly at delivering the power of tree threads to the user. They use tree threads as a sorting mechanism, and perhaps indent responses to hint at the underlying tree, but they still show messages one after another in a big list. This can be seen not just on web sites such as the Google Groups example, but also in supposedly thread-capable mail readers such as Thunderbird and Mutt. These programs take a linear stream of posts, use the reply associations to internally construct a beautiful, highly structured tree, and then smash it flat to render a pale shadow of the thread's former structure. Ideally, a discussion system should bring the power of the tree -- and its close conceptual mapping of the contained discussion -- to the user. Such a user interface could provide useful and time-saving features such as:

  • Tree navigation. In addition to the usual "next" and "previous", the user could "ascend" the tree to see parent messages, or "descend" to read replies to any given post.
  • Tree visualization. If the tree is represented visually, the user could get an overall idea of the discussion's structure, and jump between branches to see what sub-topics have arisen.
  • Branch management. If the user judges that a branch has gone off on a tangent, off-topic, or into an uninteresting sub-topic, the user could "junk" the entire branch (the current post and all its descendants) and avoid seeing those unwanted messages, while continuing to peruse the more useful branches. Additionally, such junking could be persistent -- the system would know to automatically junk any additional messages that arrive on that branch.

In all my years of using the Internet, I've only come across one program that gets it right -- a terminal-based USENET client known as Threaded Read News, or trn for short. Trn, which dates back to 1990 (and is a derivative of an even older program), provides access to USENET newsgroup articles in a way that provides the features I mentioned above -- cursor keys can be used to directly navigate a visualization of the tree, and operations (such as junking or "killfiling") can be performed on the entire thread or specific branches of a thread as they are encountered. When I became frustrated enough with trying to keep up with a busy mailing list using the usual clunky tools, I decided it was time to dust off these relics of antiquity. I installed InterNetNews (INN) -- a USENET newsgroup server package -- on my host and directed the mailing list into it using a procmail recipe and INN's provided mailpost utility. The result is that I can now read the mailing list in all of its threaded goodness using trn. Here's a screenshot of trn showing a post -- notice the tree diagram in the upper-right hand corner:

Before you rush out to download the latest version of trn, you should know that these tools from yesteryear are definitely old-school and have an enormously steep learning curve. It's worth it to me because I'm already familiar with trn from using it heavily back in the old days, and also because of the most important advantage of a properly tree-threaded discussion system: speed. It is simply not feasible to consume huge amounts of discussion content in a reasonable amount of time without such a tool. What the world really needs, though, is for these concepts to be implemented in an attractive and easy to use Web 2.0 interface so we can finally rid ourselves of the painful linear and pseudo-tree discussion systems that litter the web today.