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…

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…)

…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…

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…!)