6 ms·

Without threads, I can't advocate the use of Element yet to the communities that want to leave Slack (usually they use free Slack, then grow, then get stuck wit

Without threads, I can't advocate the use of Element yet to the communities that want to leave Slack (usually they use free Slack, then grow, then get stuck with a chat software with no history because it's too expensive to go premium). Mattermost has no threads either. RocketChat just implemented them in v3.4. Zulip has its own concept of threads, but Zulip frightens non-dev users in my experience.

galgalesh 6y ago
Mattermost actually has threads, but their UI is a little bit more clunky than Slack. All the messages show up in the "main thread" like nornal but once you click on one of the threaded messages, you only see the messages of that thread.
- Shoue 6y ago
  In my opinion that's less clunky than Slack because it gives you a good overview of what conversations are taking place in a channel, instead of scrolling up and seeing a 100 reply thread you missed. It's also how Flowdock does it, which has some of the best threading I've experienced in chat software.
  - nemetroid 6y ago
    The downside is that if there’s one thread with active discussion, everything else gets buried.
  - jbister 6y ago
    I agree in principle that it's nice to be able to see the full conversations without clicking into a bunch of threads, but a problem that I have noticed when people use Mattermost is that they either forget or don't notice that people are using the thread feature and simply reply directly in the channel to an active thread. This makes it so that anyone who isn't looking at the channel loses track of the conversation. You could fix this by repeatedly telling anyone who does it wrong to do it right, but people simply can't make that mistake when the threads are collapsed by default. As things are now, the thread feature in Mattermost doesn't really help that much, because if you want to be really sure not to miss part of a conversation you need to keep a separate window with that channel open anyway instead of just having the thread open in the same window.
- jasonblais 6y ago
  Mattermost PM here, thank you for the feedback! We are exploring the ability for users to choose if they want to collapse threads. We’re very excited about it and are currently testing prototypes with the Mattermost community and some customers, with development starting soon after. We'd love for you to join the Folded Reply Threads channel (https://community.mattermost.com/core/channels/folded-reply-threads https://community.mattermost.com/core/channels/folded-reply-...) on our community server as we share progress updates and gather feedback.
- distances 6y ago
  This is the same way as pioneered by Flowdock ten years ago or so, right? I think that approach is way way better than what Slack has. I remember eagerly waiting for Slack to implement threading and the being dismayed how crippled design they chose.
diarrhea 6y ago
Took me a second to realise you are not talking about concurrency. I can also confirm Mattermost has threads, which are likeable but a bit confusing.
- jasonblais 6y ago
  Mattermost PM here - we are actively working on improving threads, would love to hear your feedback! Would you be open to sharing them in our feature proposal forum (https://mattermost.uservoice.com/forums/306457-general/suggestions/19572469-make-threads-collapsible https://mattermost.uservoice.com/forums/306457-general/sugge...) or join the Folded Reply Threads channel (https://community.mattermost.com/core/channels/folded-reply-threads https://community.mattermost.com/core/channels/folded-reply-...) on our community server?
nature 6y ago
There is an existing discussion to add threading to Element: https://github.com/vector-im/riot-web/issues/2349 https://github.com/vector-im/riot-web/issues/2349. To sum up, the backend already somewhat supports it by tagging a message with a `thread_id`. Then the UI can group messages by their `thread_id`s.
- Arathorn 6y ago
  Matrix already supports Zulip style threading via MSC2326 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc2326/proposals/2326-label-based-filtering.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc232...). We haven't hooked it up in Element yet though (and ideally would do much better UI).
  - maelito 6y ago
    I'm curious about the priorization of this feature. In my personal experience (7 slack groups), the majority of the channels use threads. It's a very important feature to avoid drowning people in a stream of messages irrelevant to them. I may be mistaken, but it doesn't look hard to add it to the UI if the back already supports it. Is the feature planned for a precise date ? Does the Element team lack money ? Can we pay for this feature, instead of paying Slack e.g. 30 000€/year ? Is the lack of developers the problem ?
  - Multicomp 6y ago
    Suggestion: offer multiple threads in the same window at once, since slack only offers 1 thread view at a time. IE where slack offers 1 sidebar for threads in 1 column, offer up to 6 threads in a window via 2 columns and up to 3 threads per column. What it look busy when fully used? Yes, but sometimes when you are working in an Enterprise environment, you need to follow something across multiple rooms or channels and this would save users a lot of clicking back and forth. while I'm sure there are oodles of feature requests already going, this would be one that would offer a genuine feature that slack does not.
    - Scottopherson 6y ago
nolok 6y ago
Zulip needs a couple UI/UX designer to work on it and get a facelift into the "cutesy and smiley interfaces" era. It's great, and it's the only one that's actually free to self host with all features.
- rhn_mk1 6y ago
  Zulip definitely needs more UX design work. I also wouldn't call it great either. Perhaps in comparison to the competition it would be, but it's awful compared to native chat applications. Invisible scroll bars keep making me miss new messages just because indicators were out of the viewport. Having the browser stall routinely causes full reloads (after a delay, making it more annoying), then the reload is invarialy interrupted by the server due to request overload. Not to mention that the reload is slow already. Long messages show up collapsed, and uncollapsing them often devours whatever text was in the input field, an especially useful feature when trying to write a thoughtful reply cross-referencing multiple posts. Email notifications send out the same message multiple times, and presents author's name the same way as the rest of the text. Constant hitting on the CPU. Confusing notion of threads and forums. I could go on - Zulip is not nice.
  - nolok 6y ago
    Yeah but if you want truly self hosted AND full feature set (notably search and archives) AND owning your data, there isn't much available putting Zulip far on top. IRC could do it, but IRC never got a clean and prettified client that bob from accounting knows how to use properly, and finding the proper server software sucks.
    - neiljohnson 6y ago
      Fwiw self hosting Element and a Matrix homeserver like Synapse provides a full Matrix feature set (including search, archiving and everything else). You don't lose out for self hosting.
  - tabbott 6y ago
    I'd be curious to hear more about these concerns, because they're largely not things others have reported. Would you be up for dropping by chat.zulip.org to provide more detail? A few initial thoughts: * Notification emails for PMs don't include the sender in the body at all. Those that do have the sender bolded on a line by itself. So I am not sure what you're referring to here. Maybe you're using a self-hosted server running an old version? We did a total redesign of missed-message emails in 2019. * When closing the compose area, Zulip saves message content in the "drafts" feature, so one never loses partially composed work: https://zulipchat.com/help/view-and-edit-your-message-drafts https://zulipchat.com/help/view-and-edit-your-message-drafts. * I was able to reproduce the uncollapsing bug as https://github.com/zulip/zulip/issues/15808 https://github.com/zulip/zulip/issues/15808, and fixed it a couple minutes later. Thanks for the report! * The issues around CPU load, reloading and server issues are probably best discussed interactively, since I'd like to see browser profiles for your situation and understand if you're using a self-hosted server that might be underprovisioned, which seems a bit much to work out on a HN thread :) -Zulip lead developer
imtringued 6y ago
Using a chat software for keeping history is the wrong use case. I've had to add some minor chat functionality to one of my side projects and honestly the only benefit of a chat history is that when you join a server/channel you get to see the last 20 min of the conversation instead of an empty screen. I automatically delete chat messages older than one hour. Different use cases might need completely different limits but it doesn't change the fact that you should pick a cut off point beyond which you start deleting messages.
darkwater 6y ago
Slack threads are the typical example of a feature that is added, raises a lot of noise from the (usually techie) vocal minority and then it is assumed as a fundamental feature by everybody else, like in "why didn't we think about this before?".
- agustif 6y ago
  Forums
  - layer8 6y ago
    Email and Usenet
    - darkwater 6y ago
      They are not chat systems.
- caymanjim 6y ago
  I still don't like Slack threads. Too many conversations in Slack turn into threads, removing the conversation from visibility without additional clicking, and fragmenting the flow of information. Real conversations rarely work this way. It's like being in a meeting where every time a new topic comes up, half the people leave the room to start a new meeting, and then come back when the topic changes again. If a topic truly requires enough time and space for that, then by all means take it to another channel or a group chat. Otherwise, keep it in the main space. It breaks the flow and invites premature fragmentation, and the UX is bad.
  - black_puppydog 6y ago
    > and the UX is bad. this. especially jailing threads into a tiny sidebar, with the bad "read status" handling going all over the place when that sidebar happens to be open. Slack threads suck. Just keep everything in one big thread, break out disposable channels when you need them, and build proper archiving features for those. Linking to an existing channel is already there so that shouldn't be a problem.
monadic2 6y ago
Ngl I view this as a straight up feature—anything intransient enough to go in a thread should go to a more persistent area like a forum. Otherwise it gets lost in slack and is extremely difficult to find later. Slack anxiety sucks; email and forums are highly searchable and linkable and there’s no shortage of cheap, open-source software providing this AND they don’t have built-in corporate incentives driving engagement in a chat platform like it’s a good thing in itself (hence why the notification and “unread count” settings are trash). Like how do you store a thread to find it later—loudly announce the subject in as much detail as possible with a “SUBJECT:” index prefix? Deep link to put in your wiki and hope slack actually honors those links in a year? Is slack search usable yet?

galgalesh 6y ago

Mattermost actually has threads, but their UI is a little bit more clunky than Slack. All the messages show up in the "main thread" like nornal but once you click on one of the threaded messages, you only see the messages of that thread.

Shoue 6y ago
In my opinion that's less clunky than Slack because it gives you a good overview of what conversations are taking place in a channel, instead of scrolling up and seeing a 100 reply thread you missed. It's also how Flowdock does it, which has some of the best threading I've experienced in chat software.
- nemetroid 6y ago
  The downside is that if there’s one thread with active discussion, everything else gets buried.
- jbister 6y ago
  I agree in principle that it's nice to be able to see the full conversations without clicking into a bunch of threads, but a problem that I have noticed when people use Mattermost is that they either forget or don't notice that people are using the thread feature and simply reply directly in the channel to an active thread. This makes it so that anyone who isn't looking at the channel loses track of the conversation. You could fix this by repeatedly telling anyone who does it wrong to do it right, but people simply can't make that mistake when the threads are collapsed by default. As things are now, the thread feature in Mattermost doesn't really help that much, because if you want to be really sure not to miss part of a conversation you need to keep a separate window with that channel open anyway instead of just having the thread open in the same window.
jasonblais 6y ago
Mattermost PM here, thank you for the feedback! We are exploring the ability for users to choose if they want to collapse threads. We’re very excited about it and are currently testing prototypes with the Mattermost community and some customers, with development starting soon after. We'd love for you to join the Folded Reply Threads channel (https://community.mattermost.com/core/channels/folded-reply-threads https://community.mattermost.com/core/channels/folded-reply-...) on our community server as we share progress updates and gather feedback.
distances 6y ago
This is the same way as pioneered by Flowdock ten years ago or so, right? I think that approach is way way better than what Slack has. I remember eagerly waiting for Slack to implement threading and the being dismayed how crippled design they chose.

diarrhea 6y ago

Took me a second to realise you are not talking about concurrency. I can also confirm Mattermost has threads, which are likeable but a bit confusing.

jasonblais 6y ago
Mattermost PM here - we are actively working on improving threads, would love to hear your feedback! Would you be open to sharing them in our feature proposal forum (https://mattermost.uservoice.com/forums/306457-general/suggestions/19572469-make-threads-collapsible https://mattermost.uservoice.com/forums/306457-general/sugge...) or join the Folded Reply Threads channel (https://community.mattermost.com/core/channels/folded-reply-threads https://community.mattermost.com/core/channels/folded-reply-...) on our community server?

nature 6y ago

There is an existing discussion to add threading to Element: https://github.com/vector-im/riot-web/issues/2349 https://github.com/vector-im/riot-web/issues/2349. To sum up, the backend already somewhat supports it by tagging a message with a `thread_id`. Then the UI can group messages by their `thread_id`s.

Arathorn 6y ago
Matrix already supports Zulip style threading via MSC2326 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc2326/proposals/2326-label-based-filtering.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc232...). We haven't hooked it up in Element yet though (and ideally would do much better UI).
- maelito 6y ago
  I'm curious about the priorization of this feature. In my personal experience (7 slack groups), the majority of the channels use threads. It's a very important feature to avoid drowning people in a stream of messages irrelevant to them. I may be mistaken, but it doesn't look hard to add it to the UI if the back already supports it. Is the feature planned for a precise date ? Does the Element team lack money ? Can we pay for this feature, instead of paying Slack e.g. 30 000€/year ? Is the lack of developers the problem ?
- Multicomp 6y ago
  Suggestion: offer multiple threads in the same window at once, since slack only offers 1 thread view at a time. IE where slack offers 1 sidebar for threads in 1 column, offer up to 6 threads in a window via 2 columns and up to 3 threads per column. What it look busy when fully used? Yes, but sometimes when you are working in an Enterprise environment, you need to follow something across multiple rooms or channels and this would save users a lot of clicking back and forth. while I'm sure there are oodles of feature requests already going, this would be one that would offer a genuine feature that slack does not.
  - Scottopherson 6y ago

nolok 6y ago

Zulip needs a couple UI/UX designer to work on it and get a facelift into the "cutesy and smiley interfaces" era. It's great, and it's the only one that's actually free to self host with all features.

rhn_mk1 6y ago
Zulip definitely needs more UX design work. I also wouldn't call it great either. Perhaps in comparison to the competition it would be, but it's awful compared to native chat applications. Invisible scroll bars keep making me miss new messages just because indicators were out of the viewport. Having the browser stall routinely causes full reloads (after a delay, making it more annoying), then the reload is invarialy interrupted by the server due to request overload. Not to mention that the reload is slow already. Long messages show up collapsed, and uncollapsing them often devours whatever text was in the input field, an especially useful feature when trying to write a thoughtful reply cross-referencing multiple posts. Email notifications send out the same message multiple times, and presents author's name the same way as the rest of the text. Constant hitting on the CPU. Confusing notion of threads and forums. I could go on - Zulip is not nice.
- nolok 6y ago
  Yeah but if you want truly self hosted AND full feature set (notably search and archives) AND owning your data, there isn't much available putting Zulip far on top. IRC could do it, but IRC never got a clean and prettified client that bob from accounting knows how to use properly, and finding the proper server software sucks.
  - neiljohnson 6y ago
    Fwiw self hosting Element and a Matrix homeserver like Synapse provides a full Matrix feature set (including search, archiving and everything else). You don't lose out for self hosting.
- tabbott 6y ago
  I'd be curious to hear more about these concerns, because they're largely not things others have reported. Would you be up for dropping by chat.zulip.org to provide more detail? A few initial thoughts: * Notification emails for PMs don't include the sender in the body at all. Those that do have the sender bolded on a line by itself. So I am not sure what you're referring to here. Maybe you're using a self-hosted server running an old version? We did a total redesign of missed-message emails in 2019. * When closing the compose area, Zulip saves message content in the "drafts" feature, so one never loses partially composed work: https://zulipchat.com/help/view-and-edit-your-message-drafts https://zulipchat.com/help/view-and-edit-your-message-drafts. * I was able to reproduce the uncollapsing bug as https://github.com/zulip/zulip/issues/15808 https://github.com/zulip/zulip/issues/15808, and fixed it a couple minutes later. Thanks for the report! * The issues around CPU load, reloading and server issues are probably best discussed interactively, since I'd like to see browser profiles for your situation and understand if you're using a self-hosted server that might be underprovisioned, which seems a bit much to work out on a HN thread :) -Zulip lead developer

imtringued 6y ago

Using a chat software for keeping history is the wrong use case. I've had to add some minor chat functionality to one of my side projects and honestly the only benefit of a chat history is that when you join a server/channel you get to see the last 20 min of the conversation instead of an empty screen. I automatically delete chat messages older than one hour. Different use cases might need completely different limits but it doesn't change the fact that you should pick a cut off point beyond which you start deleting messages.

darkwater 6y ago

Slack threads are the typical example of a feature that is added, raises a lot of noise from the (usually techie) vocal minority and then it is assumed as a fundamental feature by everybody else, like in "why didn't we think about this before?".

agustif 6y ago
Forums
- layer8 6y ago
  Email and Usenet
  - darkwater 6y ago
    They are not chat systems.
caymanjim 6y ago
I still don't like Slack threads. Too many conversations in Slack turn into threads, removing the conversation from visibility without additional clicking, and fragmenting the flow of information. Real conversations rarely work this way. It's like being in a meeting where every time a new topic comes up, half the people leave the room to start a new meeting, and then come back when the topic changes again. If a topic truly requires enough time and space for that, then by all means take it to another channel or a group chat. Otherwise, keep it in the main space. It breaks the flow and invites premature fragmentation, and the UX is bad.
- black_puppydog 6y ago
  > and the UX is bad. this. especially jailing threads into a tiny sidebar, with the bad "read status" handling going all over the place when that sidebar happens to be open. Slack threads suck. Just keep everything in one big thread, break out disposable channels when you need them, and build proper archiving features for those. Linking to an existing channel is already there so that shouldn't be a problem.

monadic2 6y ago

Ngl I view this as a straight up feature—anything intransient enough to go in a thread should go to a more persistent area like a forum. Otherwise it gets lost in slack and is extremely difficult to find later. Slack anxiety sucks; email and forums are highly searchable and linkable and there’s no shortage of cheap, open-source software providing this AND they don’t have built-in corporate incentives driving engagement in a chat platform like it’s a good thing in itself (hence why the notification and “unread count” settings are trash). Like how do you store a thread to find it later—loudly announce the subject in as much detail as possible with a “SUBJECT:” index prefix? Deep link to put in your wiki and hope slack actually honors those links in a year? Is slack search usable yet?