Today a live chat module for DotNetNuke was released. This module can be inserted into a page and then any logged-in users can participate in a simple, live chat.
I think this is an excellent step towards live service and interaction on DNN websites. However, there are a few things that definitely will need to be addressed in order to make this a viable option for live website support. I recognize that this is currently a generic and simple module, but feedback was called for, and this would be the primary reason for which I would implement live chat on a DNN installation.
- In todays, multi-task computing, its likely that users are going to be working in many different windows at once. With the current module, new messages do not "alert" us if the browser window with the message is not visible on screen (minimized, behind another window, etc.). At minimum, an incoming message needs to be able to get our attention. Whether this is a beep, a notification popup (like googletalk, Live Messenger, etc.), or simply a flashing of the browser task in the taskbar.
- If you are the only person in a page-based chat, you are chatting with yourself. If this is just a casual chat system, then you are conversing only with the people that happen to have loaded that page in the same timeframe as yourself. For more purpose-driven communication such as live support, this means that support agent has to have this page up and visible 24-7 to even know if someone wants to chat. A live support chat system needs to be able to get the notice of the support agent when a customer comes online, and it has to be fairly quick. Perhaps a client side application is needed that can poll the chat module on a certain page and provide this "chat awareness". At minimum, an email (to any interested parties) could go out that an empty chat room has become occupied.
- Free-for-all chat can be fun. However, there are many cases in which this is inappropriate. If this is support chat, or private chat, then the fact that anyone on the page can see whats typed makes this an unsuitable place to share any non-public information. A live support chat system needs to be able to spawn chat "instances" that are private and secure. It also needs to be able to queue these instances across a limited support staff. Perhaps if there is a public "waiting room" similar to the current implementation, but then the support agent can invite persons to private chat instances from ther.