Previous Entry Share Next Entry
Conversation Threading Models
jducoeur wrote in querki_project
[Continuing from "Querki, Comments and Conversation"]

In the subject so far, I've tossed around the word "threading" rather casually. To understand where I'm going here, it's crucial to understand the three models of UI Threading.

Important caveat: the terminology here is entirely my own -- I invented these terms some years ago, because I need them in order to keep things straight. I use them pretty consistently, but don't expect to find them elsewhere.

When I speak about "threading", I mean how replies are displayed in a conversation. In any online conversation, you have the problem that a given comment can generate multiple replies. How you display those replies isn't just a detail -- it actually has fairly deep effects on how your conversations *work*. There is no "right" or "wrong" answer here, but each model produces different kinds of conversations. Here are the three primary models.

Flat Threading is the most traditional and simple way of displaying conversations: the whole conversation shows up as a simple flat list of comments, in order of when they were posted, usually with the most recent comments at the bottom. (A few systems put the most recent comments at the top, which I think is misguided -- while it does make it easier to get at the most recent comments, it makes the conversation very hard to follow.) A few systems have an underlying concept of messages replying to specific comments, and display that as something like: "Mary replied to Joe's comment", with a link back up, but most don't even keep track of that -- they view the entire conversation as a simple stream of messages.

The advantage of flat-threading is simplicity, and that's nothing to sneeze at. It's trivially easy to understand the conversation, and it's easy to display, especially on the increasingly important small screens.

The conversational effect of flat-threading is to *strongly* privilege the most recent comments over earlier ones. Plain and simply, folks get distracted by whatever was said most recently. It is hard to have deep side-threads in a flat-threaded conversation; instead, attempts at side topics either get lost or turn into a tangent that distracts away from the previous topic.

Flat-threading is very good for social chat, where ease of interaction is the main purpose. It is very bad for purposeful conversation where you are trying to get something accomplished.

Lightweight Threading is the exact opposite of Flat Threading, and is the way LiveJournal traditionally works. Each reply is indented below its parent, so that it is explicit which message replies to which.

The challenge with light-threading is that you wind up with endless indentation. It is conceptually simple, which is no small thing, but a back-and-forth conversation can quickly wind up going off the right-hand side. It is very easy to lose track of context: the amount of indentation is central to understanding the conversation and who's replying to whom, but it is difficult to visually parse how *far* a given message is indented when things get complicated. As a result, if the conversation gets into deep back-and-forth, it becomes hard to understand.

Light-theading does not privilege the most recent comments at all. If anything, the opposite is true -- if it works like LJ, the *oldest* comments are privileged, since they are displayed first, and people tend to reply most to those topics, often never even getting to the most recent comments at the bottom.

Light-threading is very good for blogs and other places that have a primary writer, with a lot of commenters who are interacting with the head topic more than each other, where most replies are at the top level but a few get one or two sub-comments. It becomes problematic for deep collaboration, where you can wind up with a number of deep side-threads that indent and indent, and you can too easily lose context. It works rather poorly on small screens, since the indentation becomes too expensive in screen real estate and context is trivially lost.

Heavyweight Threading is a hybrid model, and is the way both CommYou and Wave worked. It attempts to provide the power of light-threading, while encouraging things to look relatively flat.

The idea of heavyweight threading is that the first reply to each comment is flat-threaded, and shows up at the same indentation level as its parent, while subsequent replies to that specific header get indented. This seems odd conceptually, but proves pretty natural in practice. Basically, the user is encouraged with cues to reply at the bottom of the thread (such as putting an easy comment-entry field at the end of the thread), so you get a back-and-forth conversation in the flat-threaded style, but also gets a "Reply To" button on each comment so that they *can* insert a side-thread.

Heavy-threading somewhat privileges the older threads, for the same reason as light-threading, but because the UI encourages you to comment at end-of-thread, this effect is lessened.

So basically, heavy-threading encourages simple flowing conversation, but provides a specific mechanism for similarly flowing tangents. This turns out to make for relatively natural, easier-to-follow conversations, where you aren't thinking in terms of many individual comments so much as several related discussions. It is the best model I've found for *purposeful* conversation, since you get the depth of light-threading but make it easier to understand.

Querki will probably start with a flat-threaded UI, but will have the concept of "in reply to" built into the architecture from the beginning. Once I have the time to deal with the UI programming, it will move to heavy-threading.

Next: okay, but what about my smartphone?

  • 1
Flat and Nested are sometimes used, as are Flat and Tree view. There's a lot of arguments in bulletin board circles about which is preferred. Some prefer nesting for the ability to follow the logic of a conversation, instead of having to directly quote the person you are replying to. Other prefer flat hierarchies with the argument that it keeps the conversation on topic and discourages side channels.

No one is right or wrong, and every approach has to figure out ho to handle things, and there will always be edge cases too. *sigh* The hybrid approach at least gives everyone the option they want, in some sense.

Yaas. The reason I adopted the light/heavy terminology was specifically because "nested" is unclear -- both of them are "nested", but in very different ways. Light-threaded means that each comment is a node unto itself, replying to its parent, whereas heavy-threaded means that you have true *threads* under the parent.

If there is demand for flat-threaded, that will be easy for me to add -- that's just adding a "no sub-Threads allowed" flag. I won't bother unless people care (and I'm not sure they will), but I'm willing to do it if it matters.

My contention is that heavy-threaded is just plain better than light-threaded -- it allows everything that light-threaded does and more. We'll if anybody advances a counter-argument in favor of light-threading. (Which in this case would be another flag, resulting in each "thread" being exactly one comment long...)

I presume I must have seen an example of heavy threading, but none leaps to mind. Can you link to one? I'm having trouble seeing quite how it works from that description.

Actually, I'm not sure of any currently in practice -- CommYou and Wave were the two good examples I know of. I *think* Rizzoma does heavy-threading (since it mostly follows Wave's lead), but I haven't looked at it carefully to be sure.

The easiest way to envision it is to ask what happens where two people get into a back-and-forth conversation in a thread. In LiveJournal (light-threading, where each comment is a full-scale node), that indents endlessly. In heavy-threading, it becomes a linear thread, straight down, until and unless somebody begins a tangent from one of the comments...

In other words -- look at this conversation, with us replying back and forth, and the way it's indenting. That's light-threaded. If we were heavy-threaded, each reply would be directly below the one above it.

The difference is subtle, and looks trivial at first glance, but it isn't. In light-threading, you are always responding to a *comment*, because there is nothing else. In heavy-threading, there are genuine threads of conversation, and you are usually responding at the bottom of a thread. The result is, like I said, a hybrid, with much of the same flow as flat-threading, but having the option to spin off a side or tangential thread...

Between this explanation, and your later posts about UI, I think I get it. The default comment type is to continue a current thread (no indenting), but you have the option of explicitly stating "I want to start a sub-thread, that is a fork off of the parent comment."

I've often wished in-person speech could work like that :-)

Correct. In a sense, I think of this as "true" threading, since it's the only one of the three that results in a Thread being a first-class object in the database...

  • 1

Log in

No account? Create an account