One thing that frequently happens on IRC, Slack, Discord and other group chat systems is that a conversation will be happening in a channel and someone else will want to start a separate conversation. That separate conversation can easily get drowned out, or drown out the other one. There are various existing cultural and technical solutions to this.
- On IRC, people will often just wait for the other conversation
to end, but other times will interleave the conversations with heavy
use of nick-prefixing (
20:45 <alice> bob: Tell me more about the retroencabulator). Sometimes long-running conversations between two people will just move to direct-message, by request of either one of the participants of the conversation or another member of the channel. This all involves little to no protocol support, and is largely cultural. However, it can be frustrating to wait, and nick-prefixing only really works with at most two or three participants.
- On Slack, people will commonly use threads. Threads are a single-level branch-off within a channel, rooted in a top-level message. People can continue the conversation in a thread, and will often move to a thread if the conversation goes on too long. In some servers, people have a cultural convention of having all conversations in threads. Slack's threads can be unpleasant to have long-running conversations in, since the UI makes the thread horizontally narrow, but this works well for "support" channels. (If Slack were a protocol, rather than a proprietary client, this wouldn't be an issue; someone would simply make a client that made threads more pleasant.) In Google Chat, I believe there is additional technical support for this pattern, such that this thread-centric behavior is the default.
- Discord has recently introduced its own version of threads, where threads are a little more heavy-weight in that they have to be given a name (but also an expiration), and subsequently create a sort of subchannel that shows up in the channels sidebar under the parent channel. These are much more pleasant to use than Slack's threads (since they have the full UI) and can be navigated between more easily, and have an additional benefit of being more discoverable for someone who missed the original "root" message -- threads show up in the sidebar for everyone, not just the participants. However, in a social context, conversations naturally wander and the thread name becomes less and less relevant. The heavyweight operation of creating and naming a thread feels unnatural, and abandoning a thread for a new one as the topic changes feels a bit ridiculous.
- On Heim (a little-known chat startup that never quite got off the ground, but still has a couple of pretty active rooms) each room has true threading support, the way you'd see in threaded comments: Any message can have new messages nested under it, and those messages display a subthread within the main UI, in a tree-like fashion. Subthreads that grow beyond a few messages collapse by default, and are therefore unobtrusive if you're not interested in them. This is fantastic for branching and wandering conversations, although there's a tendency for conversations to slowly nest deeper and deeper. People have occasionally expressed an interest in being able to elevate a subthread into a room of its own. It can also be difficult to understand the flow of a conversation you were not part of, since people tend to jump around. On the whole, though, it is very natural and pleasant, and I'd like to see this concept fully developed. (There are still some usability bugs, as development was halted a few years back.)
The usefulness of these approaches depends on the context. For support forums, thread-by-default makes a great deal of sense. But for a social context where things should feel more free-flowing and topics tend to wander, other solutions seem more appropriate. The ability to split the channel into multiple streams is a good match for dynamics at a party, where a few people can drift off from a cluster and strike up a separate conversation, and people can wander over as they desire. There are some major differences, of course: In an in-person setting, it's hard to be in two conversations at once, and you can only start a conversation if someone is already paying attention to you! So text still has some major benefits, but I think the user experience could be enhanced to include this natural splitting/grouping behavior.
One approach on a social server would simply be to have a bunch of vague thematically named rooms like "living room", "dining room", "kitchen", "den", "bedroom", "hallway", "porch", "basement", and "yard". People could strike up a conversation wherever, and in a Discord-like UI where all channels are visible to users by default, people could wander over to channels that are interesting at the time, and wander away (or set an expiring mute on the channel) if the conversation becomes uninteresting. If a conversation goes in one direction and I'd like to take it in another, I could simply go to another channel and say "speaking of..." and branch the topic that way. (This is more or less how some pandemic video chat social spaces work: A set of "tables" with a video chat at each, and you can wander between the tables.) I think this could work well in a "general social" server, where there's no notion of topic channels. However, it's really common to have topic channels, and topic channels are just as susceptible to this phenomenon as any. Having a set of "tables" for every topic would lead to a huge amount of clutter.
So another approach I've been considering is something Discord-like, with subchannels, but no naming and no expiration, just a gentle nudge back to the main channel: If you split a conversation off of #pets, it puts you into #pets-2, links to it from the main channel, and shows up in the channel selector. A subchannel would disappear from the sidebar after X hours of inactivity, but could be revived for reuse at any time if someone needs a parallel stream of conversation. I think people are good enough at remembering "oh, #pets-2 is where they're talking about cat harnesses right now" over the short term that this could work just fine. Navigation gestures would land you by default in the main #pets, but search would cover all of the subchannels. If #pets, #pets-2, and #pets-3 were all active, you could always split to #pets-4 (up to some reasonable limit, I suppose).
I'm curious to hear what other solutions people have encountered and how they shaped usage, as well as people's reactions to this semi-automated channel-splitting idea. (I don't have commenting set up here again yet, but I've crossposted to the social-media-design Dreamwidth community, so you can also discuss there if you have or create an account.)