On Fri, 2013-10-11 at 11:18 +0100, Allan Day wrote:
The usage patterns for IRC are different from regular IM (passive presence in many "always on" channels vs. active participation in a smaller number of temporally specific conversations). You can't support both with the same UI (I know, I've tried to design such a thing).
I'm not so sure they're really different. I have a passive presence on my corporate IM system, always indicating my availability (available/busy/away/etc.). And it's very likely to be 'always on' these days, since I can also receive voice calls from the PSTN when I'm connected to it. And there are obviously the small number of temporally specific conversations that you mention. But all that *also* describes my IRC usage. Yeah, it's always on, and it can indicate my availability, and I'll have a number of short-lived conversations. To me, there isn't a clear distinction between one and the other. There's a broad *spectrum* of communication, and even 'group chat' can end up including "meetings", with audio conferencing, desktop sharing and all the other stuff that can bring. But then, so can 1:1 messaging. I worry about trying to draw clear lines between types of usage and design *different* clients for each. Because there's a lot that might then "fall through the cracks". OK, so it isn't necessarily that easy to do one tool to solve all use cases either — but at least if we take that approach there is no need for the user to learn how we've drawn our arbitrary¹ distinctions between use cases and which tool to use for which. And we'll *have* to bear in mind the fact that there is a *spectrum* of usage which we have to encompass, rather than each separate tool focusing on only a tiny part of it. -- dwmw2 ¹ to the user. Probably.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature