Skip to main content

Threaded chat article and demo

While nothing major, managing threaded conversations in chat has bothered me for quite a while. Yesterday I had an idea on how to improve matters:
  • Works using existing chat infrastructure. Needs only augmented clients.
  • Plays well even if other party uses a non-thread aware chat tool.
  • Separates threads automatically based on interaction patterns.
I've written an article and have created an online demo about it. Discussion welcome.

Comments

Peter Arrenbrecht said…
My friend Marco posted a lengthy response. Shall ponder this in detail later on.
06 February, 2008 14:39
Daniel LaLiberte said…
I worked on a threaded chat idea years ago: http://www.hypernews.org/~liberte/threaded-chat.html

Your idea is much simpler and probably easier for users to learn and use.

One issue that became apparent when I was trying the demo is that it is not clear what I might be merging, if the other user has typed more than one extra input, or if the other user has resumed an earlier thread. The transcript is also not clear about what has been merged.
25 September, 2009 17:14
Peter Arrenbrecht said…
Daniel, I saw your interesting work when I did a bit of research. But, as you said, it seemed a bit too complex. Your points are well taken, though. I do not yet see how to address them without complicating the model too much. I'm also still thinking about how to do this on IRC with lots of background threads flowing by.

Alas, the project is on hold at the moment. I'm waiting to see what Wave brings to the table on this front.
09 October, 2009 09:21
Anonymous said…
This comment has been removed by a blog administrator.
08 November, 2009 23:17
Post a Comment

Popular posts from this blog

Beyond TDD: Documentation Driven Development

There are quite a few articles extolling the virtues of test-driven development these days ( here's one ). And for good reason, too. Having done TDD for quite a while, I recently started combining it with documentation-driven design. This is what my open-source tool, JCite , is all about. With this approach, I sketch out the most important use cases, combine them into the index of a tutorial (links plus teasers summarizing the use-case), flesh out the tutorial topics (and thus use-cases) one by one, develop the use-case tests in parallel to each topic, cite the important parts of the tests as actual code samples into the topic, and only then start doing the implementation (this last step is accompanied by more tests, which are now more like unit-tests). In all, this is like literate programming, but of the use-case tests rather than the implementation code. TDD already helps to make you focus on the user during API design. DDD takes the effect further by making you tell consistent
Post a Comment
Read more

Access 2003 and the DCOM Server Process Launcher

Here's a hint: Don't disable the "DCOM Server Process Launcher" service on XP SP2. It may look like one heck of a vulnerability when you really don't use DCOM at all, but, unfortunately, Microsoft Access 2003 does. It will simply open an instant message box stating "A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX Control." if the service is not running.
3 comments
Read more