Fog Creek Software
Discussion Board




Any good design ideas for live chat?

I am impressed with Joel's write up on how the JOS forum works (
http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html) and I was wondering if anyone here would have something to say about how real time chats can be shaped to achieve specific goals.

In particular I am interested in real time voice or textual chats used to

1) support customers for troubleshooting or education. Or

2) to allow existing users to educate each other and ask questions with peers.

What do you think would keep a conversation on topic and easy to follow?

Some of the software-based design 'limitations" I have seen put to good use are:

Rule 1) Small rooms with population limitations. As many room as you want but definitely small rooms (5 people to 7). Vote kicks are possible. People who idle will be dropped.

Results) It's a bit of a privilage to make it in, so people chat instead of idling. Nothing's more irritating than empty or quiet rooms without a conversation. People have no difficulty following a train of thought because you don't have 30 people trying to start a topic all at the same time. It's easier to get the conch shell but then you are expected to perform.

Rule 2) It should cost something, assuming initial payment is brain-dead and subsequent payment is just as easy.

Results) Perhaps by having a license to a software you get 500 minutes of time, seeing it deplete will give people the idea not to waste time. They will either get to the point or not idle needlessly. They will hopefully research or use it only for questions that make sense to ask in such a chatroom. By not wasting time the signal to noise ratio will hopefully be better.

Li-fan Chen
Tuesday, May 18, 2004

Just to warn you with a section of your rule 1.  People will script themselves out of being dropped.  Even some old fashioned IRC rooms drop people that idle, but people get around the problem by scripting themselves into the room. . .

Elephant
Tuesday, May 18, 2004

When you combine the two rules, scripting idlers are basically denying other paying users of service, so I am assuming that to balance it you will have to basically not allow it (through whatever means is best).

Li-fan Chen
Tuesday, May 18, 2004

And obviously if you add the two rules together the idlers would run out of time pretty quickly, causing them to be locked out.

That's pretty much the way the JOS forum works, multiple design decisions are working as one to solve different aspects of the problems possible.

Li-fan Chen
Tuesday, May 18, 2004

Lol, I guess this is really off topic... no replies except for Elephant's.. sorry guys :-D

Li-fan Chen
Wednesday, May 19, 2004

> 1) support customers for troubleshooting or education.

Remote control (see and control the other person's desktop) is pretty useful when ou're trying to support/troubleshoot their using a computer.

> What do you think would keep a conversation on topic and easy to follow?

Google. Seriously, I posted here to say I would be starting to use .NET, and asking what forums I should use for support ... and someone told me that any question I could think of asking has been asked and answered already, and to rely on Google. So far, that advice has been accurate.

> Some of the software-based design 'limitations" I have seen put to good use are:

I know you're talking about real-time chat.

But for non-real-time conversations, it was hard to beat the Compuserve model:

- Users pay
- Users need to login (and, therefore, have an identity)
- Moderators can delete off-topics posts, and eventually even ban (identified) abusers from a forum

Christopher Wells
Wednesday, May 19, 2004

*  Recent Topics

*  Fog Creek Home