[Standards] Threaded chats

Jay Carlson nop at mitre.org
Thu Feb 8 18:12:49 UTC 2007

On Thu, 2007-02-08 at 16:27 +0100, Ralph Meijer wrote:

> On Thu, 2007-02-08 at 16:22 +0100, Nicolas Vérité wrote:
> > Have you ever discussed about "threaded chats"?
> > * by "chats", I mean: one-to-one as long as group chats
> > * by "threaded", I mean: you can easily identify the relations between
> > discussion threads, keeping the timely nature of chats
> > 
> > It's becoming a growing need, because in an (over)crowded chatroom
> > or a multi-subject one-to-one chat, it gets uncomfortable to understand
> > who/what one is referring to.
> > 
> > Do you think it is XEPable?
> I'm not sure, it feels like micromanaging chat, with more effort than
> rewards. Maybe grow a bigger brain :-)

I've heard this stated as a strong requirement for groupware chat
systems several times in the last 7 years or so.  Many people feel
uncomfortable with the "chaos" of a fast-flowing chat room, and want
some structure to it. 

I've never been motivated to implement this in any of the systems I've
worked on because it seems like a clear violation of Grudin's Law:

"When those who benefit are not those who do the work, then the
technology is likely to fail, or at least be subverted"

In any threading system, you need to provide additional information any
time you post a message.  For email and discussion boards, this is not
all that onerous, partially because of the UI, but mostly because the
chunk size is high.  But we've just postulated up in the first paragraph
that this *is* a fast-flowing chat room, and it's likely the chunk size
is small.  And the primary beneficiaries of the threading information
are passive readers---not the  people conversing, because they're
probably paying a lot of attention to what's going on.  

What *does* seem to be useful enough is UI to indicate that a given
speech act is directed at a particular person.  In that case, the source
gets sufficient benefit out of getting the attention of the recipient
that the source is willing to take additional UI action.  For
bystanders, this also provides threading clues for free.

Sometimes the request for threading tools is associated with requests
for stronger moderation tools, and fine-grained control over who gets to
speak when.  In my opinion, the desire of some organizations to have
software enforce rules that "in real life" are handled by social
convention is very revealing.  But that's a different rant.

   "Having the most bells and whistles 
      doesn't make a project the best. 
   Not "clink clink" like jewels, 
      but "WHAM WHAM" like boulders. 

More information about the Standards mailing list