3 ms·

Ok. So their approach to solving this problem is to break down the concept of single channels into a system of parent channels with sub-channels... Pardon my cy

Ok. So their approach to solving this problem is to break down the concept of single channels into a system of parent channels with sub-channels... Pardon my cynicism, but that's not going to solve the problem. If this were an information architecture problem, it would have been solved already by Slack itself. Slack's problem is noise and that's not something you can solve easily. Trying to create new abstractions is only going to increase the cognitive load for your users. Who wants to have a hundred notification bubbles begging for attention? No one would ever catch up on anything relevant with this approach. If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it. No amount of information re-decoration or re-abstraction will solve this problem. This is also the reason why all the social media platforms eventually move away from chronological feeds and start using algorithmic feeds. The solution is to narrow the scope of information that is useful or relevant to the users, but the paradox here is that Slack success comes from creating a product that is a solution for FOMO (Fear of Missing Out) and not a solution for keeping people informed about what matters.

yellowapple 8y ago
The reason why Slack ends up being prone to "noise" is because there's no sense of what each "sound" is about or its origin. Given the same number of messages, a Zulip-like model of putting messages in topics in channels makes it (hopefully) at least somewhat eaiser to differentiate between the sound for which you're listening and the other sounds about which you couldn't really care less. If you have one of those voice-driven personal assistant gadgets (Echo, Google Home, etc.), try putting it between you and some other sound source (say, a TV) and give it a command. It'll probably hear you correctly, since it knows to listen in a particular direction and can differentiate between you and the TV. Now put yourself between the Echo and the TV and give the exact same command. The Echo probably won't even hear you, and if by some miracle it does, it'll get overwhelmed by all the noise coming at it. Same amount of data, but how that data is arranged matters significantly. Same thing here. You're the Echo, the information you want is the user, and the information you don't want is the TV. Slack puts the user between the Echo and the TV, while Zulip claims to put the Echo between the user and the TV.
flafla2 8y ago
Slack channels are largely defined by _membership_, not necessarily by _topic_. At least in my organization (we use Slack), there is generally a channel (or channels) for each team and larger channels for the whole company. As these channels get bigger, they inevitably split into sub channels (#myteam becomes #myteam-status, #myteam-oncall, #myteam-eng, ...). But this is clunky and can lead to a lot of confusion as to what chats should go where. Furthermore information retrieval can be cumbersome as I’ve found myself flipping through 5 chats and searching them all for a conversation. I don’t have any experience with zulip, but it’s strategy of partitioning conversations largely aligns with how I think when I look for things on Slack: First I recall who I was talking to (channel), then I drill down and look for the thread I’m thinking of.
tabbott 8y ago
(I lead the Zulip project.) If you talk to people who use Zulip, they will tell you that a better information architecture actually does make a big difference for communicating effectively. See, for example: * https://twitter.com/b0rk/status/986444234365521920 https://twitter.com/b0rk/status/986444234365521920 * https://www.recurse.com/blog/112-how-rc-uses-zulip https://www.recurse.com/blog/112-how-rc-uses-zulip * https://news.ycombinator.com/item?id=17622987 https://news.ycombinator.com/item?id=17622987 (on the HN frontpage right now)
Bailin 8y ago
| If this were an information architecture problem, it would have been solved already by Slack itself. That is a strange/dangerous position to take. You seem to be saying that this one company's current implementation of mostly text chat is the best possible way to communicate. | If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it I also disagree slightly here. Users don't need to consume all information that they have access to. It's okay to dismiss notifications without reading their content, if you can determine it's noise for you. But the problem with channels/room-focused chat services is that they tend to have a few fixed number of channels, and users have to scan/read through content to determine if there's any signal in there. To me, that seems to be the core differentiator of Zulip. For example if I've been gone for a few hours or few days, I can quickly see that I can dismiss conversations in streams like Dev/lunch-ideas, but I might choose to read up on Dev/prod-outages. In most/current chat services, all that conversation would be mixed up in the same room/chat history. EDIT: Another way to think about it is that people have conversations, but most chat services only gives you rooms. People generally only care about some of the conversations that takes place in some of the rooms, so low signal to noise ratio. Most chat services leaves it to the user to deal with that, eg make a new room per new conversation. Zulip offers another, perhaps more user-friendly way.
anotheryou 8y ago
They simply force threads with a short topic and provide a subchannel-like view for them. Threads in Slack are hard to enforce (please don't write 20 "get well soon" replies in the main channel). They are hard to parse (you have to scroll past all the threads, including the "get well soon" chain). And impossible to mute without leaving a whole channel behind. I can imagine this approach to help (but we use slack at work...)

yellowapple 8y ago

The reason why Slack ends up being prone to "noise" is because there's no sense of what each "sound" is about or its origin. Given the same number of messages, a Zulip-like model of putting messages in topics in channels makes it (hopefully) at least somewhat eaiser to differentiate between the sound for which you're listening and the other sounds about which you couldn't really care less. If you have one of those voice-driven personal assistant gadgets (Echo, Google Home, etc.), try putting it between you and some other sound source (say, a TV) and give it a command. It'll probably hear you correctly, since it knows to listen in a particular direction and can differentiate between you and the TV. Now put yourself between the Echo and the TV and give the exact same command. The Echo probably won't even hear you, and if by some miracle it does, it'll get overwhelmed by all the noise coming at it. Same amount of data, but how that data is arranged matters significantly. Same thing here. You're the Echo, the information you want is the user, and the information you don't want is the TV. Slack puts the user between the Echo and the TV, while Zulip claims to put the Echo between the user and the TV.

flafla2 8y ago

Slack channels are largely defined by _membership_, not necessarily by _topic_. At least in my organization (we use Slack), there is generally a channel (or channels) for each team and larger channels for the whole company. As these channels get bigger, they inevitably split into sub channels (#myteam becomes #myteam-status, #myteam-oncall, #myteam-eng, ...). But this is clunky and can lead to a lot of confusion as to what chats should go where. Furthermore information retrieval can be cumbersome as I’ve found myself flipping through 5 chats and searching them all for a conversation. I don’t have any experience with zulip, but it’s strategy of partitioning conversations largely aligns with how I think when I look for things on Slack: First I recall who I was talking to (channel), then I drill down and look for the thread I’m thinking of.

tabbott 8y ago

(I lead the Zulip project.) If you talk to people who use Zulip, they will tell you that a better information architecture actually does make a big difference for communicating effectively. See, for example: * https://twitter.com/b0rk/status/986444234365521920 https://twitter.com/b0rk/status/986444234365521920 * https://www.recurse.com/blog/112-how-rc-uses-zulip https://www.recurse.com/blog/112-how-rc-uses-zulip * https://news.ycombinator.com/item?id=17622987 https://news.ycombinator.com/item?id=17622987 (on the HN frontpage right now)

Bailin 8y ago

| If this were an information architecture problem, it would have been solved already by Slack itself. That is a strange/dangerous position to take. You seem to be saying that this one company's current implementation of mostly text chat is the best possible way to communicate. | If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it I also disagree slightly here. Users don't need to consume all information that they have access to. It's okay to dismiss notifications without reading their content, if you can determine it's noise for you. But the problem with channels/room-focused chat services is that they tend to have a few fixed number of channels, and users have to scan/read through content to determine if there's any signal in there. To me, that seems to be the core differentiator of Zulip. For example if I've been gone for a few hours or few days, I can quickly see that I can dismiss conversations in streams like Dev/lunch-ideas, but I might choose to read up on Dev/prod-outages. In most/current chat services, all that conversation would be mixed up in the same room/chat history. EDIT: Another way to think about it is that people have conversations, but most chat services only gives you rooms. People generally only care about some of the conversations that takes place in some of the rooms, so low signal to noise ratio. Most chat services leaves it to the user to deal with that, eg make a new room per new conversation. Zulip offers another, perhaps more user-friendly way.

anotheryou 8y ago

They simply force threads with a short topic and provide a subchannel-like view for them. Threads in Slack are hard to enforce (please don't write 20 "get well soon" replies in the main channel). They are hard to parse (you have to scroll past all the threads, including the "get well soon" chain). And impossible to mute without leaving a whole channel behind. I can imagine this approach to help (but we use slack at work...)