A small, closely-knit group would likely prefer Discord/IRC-style threading, because sub-discussions are more likely to be of interest to those not participating, and the added noise isn't too big of a deal if the group is small.Ī larger, but still closely-knit group would probably prefer Slack-style threading, because even though sub-discussions might still be interesting to more than the immediate participants, but a single message space starts to become unusable with more than a couple of sub-discussions going on.Ī large and loosely-knit group is is likely to prefer Reddit/HN style discussions (and in fact those are two examples of large and loosely-knit communities) because a sub-discussion is less likely to be of interest to a significant portion of the main discussion's participants. I suspect, although I'm not sure, that it comes down to two things: the size of the groups in which you normally participate, and how closely-knit they are. What's interesting to me is that the split between who prefers which style of threading is pretty close to even. I guess you could argue that Zulip-style threading is a fourth option, but IMO that's closer to a bulletin board than a group IM, because you can't have a message that isn't in a thread, so almost no discussion happens at the top level of a given channel. Discord/IRC-style replies (like you mentioned) where the responding message just quotes the original, possibly with a slight UI indication to make it easier to parse. Single-level nested threading, a la Slack (and maybe Facebook? I forget how much nesting they allow)ģ. Infinitely-nestable threading, a la Reddit and HN (and probably other sites first, but those are the ones I've used it the most)Ģ. A while back I was reading some of the discussions the Matrix people were having about implementing a threading model, where it became clear that there were three very distinct ideas of "good threading" floating around:ġ. Threading in group IM's seems to be one of the more polarizing UX discussions that I've come across. Now those are very basic things to get right in any messenger like application, but it is indicative, how bad these things work in Slack. In almost any programming language, one can find a markdown parser, that works better than what Slack cobbled together. It really shows no attention to the details. Basically I would never choose Slack over Discord, because of how crappy they implemented these things. Slack does not handle Markdown well at all, while in Discord it almost always does what you expect, including escaping of special characters and highlighting code blocks properly, which is a must have for programming languages. > For a big organization like a programming language or a company the Slack model is preferable.Īnd yet communities decide otherwise (examples: Pharo community, general progamming community servers and probably many more). Switch a channel in Slack? Merely takes a few seconds :D The comparison Slack vs Discord in terms of performance is like comparing 2 completely different things. We also don't even need to get started on performance. It's actually quite a poor solution and an artificial limitation. While Discord does not have threads, I would not at all call the Slack solution amazing. Wait, are we thinking about the same very limited concept of one additional layer down? It feels like they must have intentionally developed it badly, so that you cannot create a thread to reply to a message that is inside a thread. For a big organization like a programming language or a company the Slack model is preferable. There are probably caveats to these statements, but roughly speaking the default assumption on Slack is you don't belong to any channels in a server but can join what you want or what is configured for you, and on Discord the assumption is that you belong to everything and sometimes a Discord server will configure it so certain things are hidden. * Slack also has a different model for channels on a server. But now I would strongly oppose moving to Discord only because of this issue. It feels like an awfully hard new UI pattern to get used to after so many years of single-threaded conversation on e.g. I remember when Slack added this feature lots of people including me were a bit disdainful. One discussion or one person's question can become a thread and then the channel won't be continuously pinged by the ongoing discussion, plus multiple discussions can happen in tandem. * Slack threads are an amazing feature and frequently used on the Elm slack. When I asked why I found out that Discord's features are most certainly not a superset of Slack's. When I joined the Elm community I thought it was weird they use a Slack for real time discussion and not a Discord.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |