5 ms·

They are the primary reason to use Zulip. In this way, Zulip is more of a Teams competitor than it is a Slack competitor. I, frankly, cannot stand threads. I w

They are the primary reason to use Zulip. In this way, Zulip is more of a Teams competitor than it is a Slack competitor. I, frankly, cannot stand threads. I want a chat room, not a realtime forum. I understand why people would like that, but it still bothers the shit out of me. I work for MS so we have to use Teams, but I'd prefer opt-in to threads vs. threads by default. I fully understand and accept that my way isn't going to be the way for everyone, but when looking for a community chat option for friends, we uninstalled zulip in less than a day and ended up going with matrix. That didn't work super well for us at the time so we went with Mattermost, which much closer aligns to our chat preferences. The good news is there are tons of options for people to choose what fits best for them! That's super exciting!

chubot 6y ago
Of course you should use what you like, but I'm also puzzled because you can "ignore" threads if you want in Zulip by keeping your focus on the channel. For example I have a channel called #oil-discuss. It has a bunch of separate threads. If I put the focus on the left bar in #oil-discuss, then it shows me all the messages in chronological order, regardless of thread. If you click on a thread, then you see only the messages in that thread. So I think it's the best of both worlds. ---- Unfortunately it doesn't go the other way around in my experience -- Slack can't emulate Zulip. I joined Slack to discuss a nascent Python project. https://twitter.com/teoliphant/status/1217611221396082695?lang=en https://twitter.com/teoliphant/status/1217611221396082695?la... The creator of the channel encouraged everyone to use Slack threads to keep the conversation organized. But the threading was so awkward -- it felt felt like my replies were getting "lost" on the side, outside the main flow. Multiple people disliked the Slack threading and eventually we tried python-dev's nascent Zulip instance instead. Although I think the conversation died out in both places for other reasons.
- isbjorn16 6y ago
  I'd suspect it depends on what you're using it for - our instance of chat is primarily roughly themed chat rooms where we can talk about video games and bitch about python or rust or scala or home improvement projects or the news. It's very much so a modern day AOL chatroom experience, and that's by desire. We have discourse for things that make sense for deep threading, but for the most part everyone ignores it and just uses the chatrooms or the fairly effervescent threading in MM (that is basically the same as Slack's). If you're looking for a more real-time mailing list type behavior though, then Slack or MM would be a terrible, terrible, terrible choice imo.
StavrosK 6y ago
Can't you just make a single "general" room and talk in there? Have you ever used Zulip? Your objection puzzles me a bit because I can't see how it's a problem, since your use case is trivially supported.
- isbjorn16 6y ago
  Yes, I've used zulip - every single comment spawned a thread or responded to a thread. Users weren't used to responding to a thread, which meant we had threads of single comments constantly. I'm puzzled that you're puzzled. I thought this was the way Zulip worked. It was about 2 years ago, at any rate. Did it change since then? If so, that's exciting in its own right.
  - StavrosK 6y ago
    Hmm, that sounds like something was going wrong, threads don't just spawn, you have to create them, and a thread with a single comment kind of defeats the purpose. Oh, were you editing the subject every time you commented, maybe? That's not indicated, you only edit the subject when you want to create a new thread. In our use case, threads were relatively infrequent and specific to a topic, e.g. "middle name database migration", and that's where the discussion for that happened.
    - isbjorn16 6y ago
      Somehow we had like 15 users and not one of them managed to make a comment that wasn't a new thread - like I said though, it was like 2 years ago. Either there was a bug, or it was a design decision, or maybe even a misconfiguration on the server - regardless it got a hearty thumbs down by the community and we went on to try matrix. I was hoping for Zulip since it was a way easier install than matrix + riotweb was, especially since we wanted to self host everything. In the end all the bugs we had in riotweb and the phone apps were enough for us to jump for MM, which has its own problems but was most in line with what we wanted. Anyway, if Zulip isn't thread-first, then I guess it's less a competitor to Teams than I thought. The only way we found to make teams work for us and our very small team is to keep everything in a named joint chat and everyone utterly ignores the channels like the plague. It's always amusing when someone posts something to a channel for the first time in weeks/months and then people start responding thinking it's chat and every. single. response. becomes a new thread, because they didn't respond inside the original thread.
jlokier 6y ago
> The good news is there are tons of options for people to choose what fits best for them! That's super exciting! Personally I'm finding it a bit of a nightmare, as just about every community I'm interested in seems to require a different tool to be installed. Same for work clients. Worse than that, some communities are fragmented into different IM tool groups. The plethora of IM and other tools needed to stay vaguely involved in the leading edge conversation in multiple communities is a right pain for usability. What I really want is some way to see an overview of conversations in multiple communities I'm interested in and interact with them through that. A single tool would be nice, but some way of visually integrating similar tools would be ok as well. I was pretty happy with Pidgin for this many years ago, as it worked with almost everything. But even then I needed Skype separately. I don't think libpurple is quite as universal now. Matrix is an attempt, but by no means a solution.
- isbjorn16 6y ago
  I tend to use the web clients for everything for just this reason. Turning notifications on gives me the same toast behavior I'd have in a thick client and I'm not running 14 instances of electron at a time. I can see this being frustrating for you, though (just because I found something that works for me doesn't mean it'll work for everyone!)
  - jlokier 6y ago
    That's a good suggestion, and as it happens I use web clients when possible as well. That sucks in a different way, as the experience tends to be sub par, but at least it works (when on desktop - it's high friction when I've only got my phone to hand). It's still much like having a different application for every community or work client though - only it's become a different tab for each of them, with the tabs organised by application rather than by usefulness (or there are too many tabs), which is a poor way to organise. It also makes it difficult to organise information beyond the crude tools provided. Desktop notifications exist, yes, but I would find it so much more useful to be able to filter content and notify me of only relevant things, sort, pin, annotate, link and so on. And for this prioritisation and context management to mediate between different information sources globally, rather than having to use my own brain to do it manually, which I find to be a significant cognitive load.
eightysixfour 6y ago
I personally find threads better for actually getting work done while more focused chat like in Slack is better for “water cooler” talk. I know it isn’t the same for everyone, but I’ve found the orgs using Teams to be a bit more productive and a bit less chatty.
krisreddy 6y ago
We found the basic models in Slack, Teams and Zulip too rigid. In all such clones of the Slack design, the members of channels (and threads) are static. You are either a participant in the entire channel or you arent. But it doesnt work like that in the real world. For starters, a thread is a personal idea. (I think this is what you mean by opt-in). My idea of a thread is probably not your idea of a thread. So the concept of shared thread (channel) is hard to fathom. Second, my thread is made of activities I need to complete for the task at hand. In the process, I will interact with as many people or as few as I see fit, all in the pursuit of my goal. Not all the people I interact with (thread participants) are necessarily members of my team. This is where the rigidity is a real problem with the aforementioned products. I cannot know all the participants at the time of channel creation. And once involve a non-team-member user in the thread, they become unwitting recipients of noise, and they cant do a damn thing about it. There's gotta be a better way.

chubot 6y ago

Of course you should use what you like, but I'm also puzzled because you can "ignore" threads if you want in Zulip by keeping your focus on the channel. For example I have a channel called #oil-discuss. It has a bunch of separate threads. If I put the focus on the left bar in #oil-discuss, then it shows me all the messages in chronological order, regardless of thread. If you click on a thread, then you see only the messages in that thread. So I think it's the best of both worlds. ---- Unfortunately it doesn't go the other way around in my experience -- Slack can't emulate Zulip. I joined Slack to discuss a nascent Python project. https://twitter.com/teoliphant/status/1217611221396082695?lang=en https://twitter.com/teoliphant/status/1217611221396082695?la... The creator of the channel encouraged everyone to use Slack threads to keep the conversation organized. But the threading was so awkward -- it felt felt like my replies were getting "lost" on the side, outside the main flow. Multiple people disliked the Slack threading and eventually we tried python-dev's nascent Zulip instance instead. Although I think the conversation died out in both places for other reasons.

isbjorn16 6y ago
I'd suspect it depends on what you're using it for - our instance of chat is primarily roughly themed chat rooms where we can talk about video games and bitch about python or rust or scala or home improvement projects or the news. It's very much so a modern day AOL chatroom experience, and that's by desire. We have discourse for things that make sense for deep threading, but for the most part everyone ignores it and just uses the chatrooms or the fairly effervescent threading in MM (that is basically the same as Slack's). If you're looking for a more real-time mailing list type behavior though, then Slack or MM would be a terrible, terrible, terrible choice imo.

StavrosK 6y ago

Can't you just make a single "general" room and talk in there? Have you ever used Zulip? Your objection puzzles me a bit because I can't see how it's a problem, since your use case is trivially supported.

isbjorn16 6y ago
Yes, I've used zulip - every single comment spawned a thread or responded to a thread. Users weren't used to responding to a thread, which meant we had threads of single comments constantly. I'm puzzled that you're puzzled. I thought this was the way Zulip worked. It was about 2 years ago, at any rate. Did it change since then? If so, that's exciting in its own right.
- StavrosK 6y ago
  Hmm, that sounds like something was going wrong, threads don't just spawn, you have to create them, and a thread with a single comment kind of defeats the purpose. Oh, were you editing the subject every time you commented, maybe? That's not indicated, you only edit the subject when you want to create a new thread. In our use case, threads were relatively infrequent and specific to a topic, e.g. "middle name database migration", and that's where the discussion for that happened.
  - isbjorn16 6y ago
    Somehow we had like 15 users and not one of them managed to make a comment that wasn't a new thread - like I said though, it was like 2 years ago. Either there was a bug, or it was a design decision, or maybe even a misconfiguration on the server - regardless it got a hearty thumbs down by the community and we went on to try matrix. I was hoping for Zulip since it was a way easier install than matrix + riotweb was, especially since we wanted to self host everything. In the end all the bugs we had in riotweb and the phone apps were enough for us to jump for MM, which has its own problems but was most in line with what we wanted. Anyway, if Zulip isn't thread-first, then I guess it's less a competitor to Teams than I thought. The only way we found to make teams work for us and our very small team is to keep everything in a named joint chat and everyone utterly ignores the channels like the plague. It's always amusing when someone posts something to a channel for the first time in weeks/months and then people start responding thinking it's chat and every. single. response. becomes a new thread, because they didn't respond inside the original thread.

jlokier 6y ago

> The good news is there are tons of options for people to choose what fits best for them! That's super exciting! Personally I'm finding it a bit of a nightmare, as just about every community I'm interested in seems to require a different tool to be installed. Same for work clients. Worse than that, some communities are fragmented into different IM tool groups. The plethora of IM and other tools needed to stay vaguely involved in the leading edge conversation in multiple communities is a right pain for usability. What I really want is some way to see an overview of conversations in multiple communities I'm interested in and interact with them through that. A single tool would be nice, but some way of visually integrating similar tools would be ok as well. I was pretty happy with Pidgin for this many years ago, as it worked with almost everything. But even then I needed Skype separately. I don't think libpurple is quite as universal now. Matrix is an attempt, but by no means a solution.

isbjorn16 6y ago
I tend to use the web clients for everything for just this reason. Turning notifications on gives me the same toast behavior I'd have in a thick client and I'm not running 14 instances of electron at a time. I can see this being frustrating for you, though (just because I found something that works for me doesn't mean it'll work for everyone!)
- jlokier 6y ago
  That's a good suggestion, and as it happens I use web clients when possible as well. That sucks in a different way, as the experience tends to be sub par, but at least it works (when on desktop - it's high friction when I've only got my phone to hand). It's still much like having a different application for every community or work client though - only it's become a different tab for each of them, with the tabs organised by application rather than by usefulness (or there are too many tabs), which is a poor way to organise. It also makes it difficult to organise information beyond the crude tools provided. Desktop notifications exist, yes, but I would find it so much more useful to be able to filter content and notify me of only relevant things, sort, pin, annotate, link and so on. And for this prioritisation and context management to mediate between different information sources globally, rather than having to use my own brain to do it manually, which I find to be a significant cognitive load.

eightysixfour 6y ago

I personally find threads better for actually getting work done while more focused chat like in Slack is better for “water cooler” talk. I know it isn’t the same for everyone, but I’ve found the orgs using Teams to be a bit more productive and a bit less chatty.

krisreddy 6y ago

We found the basic models in Slack, Teams and Zulip too rigid. In all such clones of the Slack design, the members of channels (and threads) are static. You are either a participant in the entire channel or you arent. But it doesnt work like that in the real world. For starters, a thread is a personal idea. (I think this is what you mean by opt-in). My idea of a thread is probably not your idea of a thread. So the concept of shared thread (channel) is hard to fathom. Second, my thread is made of activities I need to complete for the task at hand. In the process, I will interact with as many people or as few as I see fit, all in the pursuit of my goal. Not all the people I interact with (thread participants) are necessarily members of my team. This is where the rigidity is a real problem with the aforementioned products. I cannot know all the participants at the time of channel creation. And once involve a non-team-member user in the thread, they become unwitting recipients of noise, and they cant do a damn thing about it. There's gotta be a better way.