Conversation Analysis and Multi-Threading

Some of you know rising_moon, some don’t, but I commend her to you as a generally smart and interesting person, and particularly this post from a few days ago.  It mostly asks questions, but presents a few interesting musings about the relationship of communities, knowledge management, and how to deal with the plethora of competing conversational threads that can arise around a topic.

In also reminds me of a point that I’ve thought about idly in the context of CommYou, but which could use a lot more thought.  Most people assume that deep asynchronous conversations should have threading, and it’s not too radical to have the ability to split threads — to promote a thread to being a top-level conversation unto itself.

But what about thread joining?  That is, it’s not unusual for multiple conversational threads to run in parallel, but they often really are running into each other and crossing over.  If you and I are both talking about X, it’s not unusual to hit a situation where really, what I want is to join your conversation with mine, so that we can cut down the redundancy.  At the moment, you do this by links and pointers, but there’s no real concept of unifying the conversations.

This might be particularly helpful in conversations that are mediated by social networks, where parallel conversations can easily arise, with some participants in one and some in the other — a bit of cross-pollination could sometimes provide some interesting insights.

Rising_moon’s post talks about nodes, and I suspect that’s the right way to think about this.  It’s not precisely that you would join two conversations into a single one, as that you could import a thread node from one conversation’s tree over into the other, and vice versa.  We normally think of a conversation as a tree; if we instead think of it as a directed graph inside a forest of conversations, we wind up with a lot of possibilities, some of which make sense and some of which probably don’t.

I’m just musing here — I don’t know if anyone has yet written a serious conversation tool that plays with this sort of thing.  (I haven’t seen one, but it wouldn’t surprise me to find academic work along these lines.)  But it’s a feature I am vaguely contemplating in the long term for CommYou, so I’d be interested in any thoughts about it…

5 Responses to “Conversation Analysis and Multi-Threading”

  1. dsr Says:

    If I weren’t committed to certain old-fashioned notions, I would say that the best way to effect a merge of two head nodes would be to display a split screen.

  2. metahacker Says:

    …how the heck did I miss that post? fixed. Thanks.

    As for merging topics — this is thorny, because conversations carry with them a lot of invisible (and some visible) context. The meaning of a conversation exists separately in the heads of each of the participants, though one hopes that they would agree on some fronts about what it is about. (Sometimes they do not. These times can be unpleasant. I’m reading a book all about such times.)

    The contexts may in fact have a lot of overlap, but finding that is even thornier. An example might be: in one conversation, participants agree on a definition of a word. In the other conversation, the word is used. Do you incorporate the discussion/negotiation of its meaning from thread #1? Or is it used in a different sense in #2? This is a very common situation; you can see the fallout all the time when new people join a community. But it would give a false impression if you read thread #2 expecting it to follow on the meaning built in #1.

    I think clustering them might be a good idea — or providing some way to link back and forth. (“This conversation is continued here –>”). This pattern occurs in some forums I participate in; in such cases the Mods will often lock the old thread and link to it from the new thread.

    It’s probably a good idea to provide richer linking across threads. It is sometimes done with LJ comment threads and hyperlinks (since you can link directly to a comment sub-tree, a feature of LJ’s that I adore). But then you have to flip or glance back and forth between windows. Some way of in-lining this — while leaving its context obvious and intact — could be cool.

    At this point, we’re talking about conversation items (‘utterances’) as first-class objects in the conversational medium, rather than restricting ourselves to seeing threads that way. People will need to point to utterances, name them (so I know what you mean when you say X, as in CommYou’s “#3.4”), collect them, possibly tag or cluster them, ….big can of worms to look into here.

    In summary, as with scm, I think merging is the really hard part.

    (I do find it amusing that at the bottom of this post, there appears a list of guesses for similar topics. It’s not a great list, and needs rising_moon’s tool…!)

  3. Justin Says:

    …how the heck did I miss that post? fixed. Thanks.

    Welcome — I thought of you immediately when I saw it.

    But then you have to flip or glance back and forth between windows. Some way of in-lining this — while leaving its context obvious and intact — could be cool.

    Yeah, that’s what I’m pondering here. Once we have real threading in some fashion, can you link a thread from Conversation A so that it shows up in a way similar (but not identical) to a subthread in Conversation B, with some sort of header that indicates where it’s from and why it’s being included? Can you, from B, “expand” into A, so you can see both contexts on a single page? What are the likely points of confusion, how do you alleviate them, and how the heck do you make a UI that makes sense of all this?

    At this point, we’re talking about conversation items (’utterances’) as first-class objects in the conversational medium, rather than restricting ourselves to seeing threads that way. People will need to point to utterances, name them (so I know what you mean when you say X, as in CommYou’s “#3.4″), collect them, possibly tag or cluster them, ….big can of worms to look into here.

    Oh, sure. But I’m already committed to that at the schema level anyway, so the idea of seeing where we can go with it in terms of UI is kind of exciting.

    I suspect this would need a lot of serious and hard experimentation in order to get something useful. But I hope to eventually have CommYou in a place where it can serve as that testing ground, and I have a suspicion that the end results could be rather powerful if we could get them right.

    It also helps that I’m starting to decouple the underlying conversational schema from the UI a bit, so we’ll have the ability to, eg, devise alternate UIs on top of the same fundamental data. The plan is that the DB schema will evolve as we learn more about the needs at the UI level, but they’re not bound quite as much at the hip as in some systems. So we should be able to experiment — indeed, I hope to eventually encourage folks to write interesting experimental UIs built on top of the CU servers…

  4. serakit Says:

    On a forum I frequent, they periodically merge topics into omnibus threads. This usually happens when someone looks around and realizes we have twenty topics about different facets of the same thing. The moderators just merge them on a case-by-case basis.

    By the way, I don’t reccomend this method. Everything merges by the date it was posted, so you can wind up rereading lots of stuff if it was a long conversation, as you look for the new posts which you now need to know to follow the thread. (And it confused the heck out of me the first time they did…)

  5. Justin Says:

    Everything merges by the date it was posted, so you can wind up rereading lots of stuff if it was a long conversation

    Ick. Yeah, that would drive me crazy. It misses a lot of the subtleties of conversation, and the way that messages interact with one another.

    Really, I think conversation merging is probably unwise if you’re not in a threaded environment. Unthreaded conversations (such as we have in this blog) are fairly linear in nature, so a raw merge is likely to mess up that linearity. And as you say, it messes up the “what have I read?” question, which is near and dear to my heart. (Making that easier was one of the primary motives behind CommYou.)

    So while I don’t necessarily have a problem with conversation merging in principle, I do think it requires mechanisms that let you see and understand the separate threads, rather than mushing them all together…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: