5 ms·

How is threading done right exactly as compared to Slack (I don't use threading)?

by pm 8y ago

donaldguy 8y ago
Very differently. Slack does threading on the basis of replies to a message and hides/collapses those under a thread, showing them only to people who expand and notifying only those who are already involved in the thread (by replying to it or being OP) Zulip's threading is based, more like email, on a Subject which all messages (can) have. Though Zulip subjects are more likely to be one or two words. In this way threading is tacked on to Slack whereas it is as at the heart of Zulip
- zAy0LfpBZLC8mAC 8y ago
  Threading in email works via message-ids and references to preceding messages, nothing to do with subjects. That is, except as a workaround for garbage email clients and services too incompetent to use email correctly.
  - donaldguy 8y ago
    I mean, depends on your MUA in practice. I think by standard for server side threading— https://tools.ietf.org/html/rfc5256 https://tools.ietf.org/html/rfc5256 — "base subject" is definitely a valid consideration. I only skimmed though. :-) feel free to extract a spec, I'm curious (but not enough to read 19 pages right now)
    - zAy0LfpBZLC8mAC 8y ago
      If I may quote: ORDEREDSUBJECT The ORDEREDSUBJECT threading algorithm is also referred to as "poor man's threading". The searched messages are sorted by In other words: as a workaround for garbage email clients and services too incompetent to use email correctly. Yes, the REFERENCES algorithm also uses the base subject--but never to override message-id based threading, only for merging together threads that couldn't be joined using message-ids ... or in other words: as a workaround for garbage email clients and services too incompetent to use email correctly. Well, and for merging together chunks of a thread where you have major gaps in your mailbox, so that reference headers don't overlap enough to make the connection, but the point remains that it's not really a threading mechanism, just a last-ditch attempt to recover a thread where proper threading information is missing, which is fine for corner cases like large gaps in which messages you have in your mailbox, and doesn't change that a sender that doesn't supply reference headers in the first place is incompetent.
usr1106 8y ago
In Slack threads are an annoyance. They lead to missed answers and discussions, because they are rarely used in average user groups. When they are they default to private only for the writer and appear out of the natural flow for the reader. In zulip every message belongs to a topic. (Well there is the "no topic" topic, but it shouldn't be used and even if it is it appears exactly like every other topic). So no surprises. I have used slack (and irc and xmpp) for a long time, and Zulip for 2 months. Zulip is certainly much better for the geek. Slack user experience is somewhat more straight forward for the naive user not caring about things done "right". For hacker news readers zulip is likely to be the preferred choice. Expect resistence from your non hacker news colleagues / managers / team members.
- pm 8y ago
  Appreciate the explanation. Is threading such a big deal that people can't live without it? I honestly never found it useful.
  - geofft 8y ago
    In busy channels in medium-sized companies, lack of threading is a huge pain: person A says "Hi, I'm trying to do X, how do I do this," person B says "Hi, I'm getting error message Y" 2 minutes later, someone shows up 5 minutes later and says "Have you tried installing this thing" and they were talking to B about solving Y but A tries to install it and use it for X and then everyone is confused and wastes time. Slack is positioning itself as an email replacement, and to some extent all of these tools are replacing at least some email. Imagine taking 20% of your email and not having subject lines, just authors. What's the "LGTM" for? (Or worse, the sender anticipates that and says "Re @pm at 00:10, agreed" and then you get to track that down.) Or imagine taking your in-person conversations, the ones that you'd eventually want to move to IM to support distributed or remote teammates, and having a rule that you couldn't go up to someone's desk, instead every in-person conversation had to take place at this one water cooler. If multiple people wanted to talk, well, either they can have multiple conversations in front of each other, or they can wait until one conversation is done. (Slack's implementation of threading, meanwhile, doesn't actually solve the problem that well because of the way it pushes threaded conversations to a side. Imagine email without a reply-all button - it solves some problems and creates so many others. You can and should live without Slack threading.) ... also, another argument that threading matters: you're using a threaded forum right now. Remember phpBB? Would HN be improved by switching to a phpBB-style UI? If you unindented all the comments on this page and sorted them by time, would it be a workable experience?

How is threading done right exactly as compared to Slack (I don't use threading)?

by pm 8y ago

How is threading done right exactly as compared to Slack (I don't use threading)?

Very differently. Slack does threading on the basis of replies to a message and hides/collapses those under a thread, showing them only to people who expand and notifying only those who are already involved in the thread (by replying to it or being OP) Zulip's threading is based, more like email, on a Subject which all messages (can) have. Though Zulip subjects are more likely to be one or two words. In this way threading is tacked on to Slack whereas it is as at the heart of Zulip

zAy0LfpBZLC8mAC 8y ago
Threading in email works via message-ids and references to preceding messages, nothing to do with subjects. That is, except as a workaround for garbage email clients and services too incompetent to use email correctly.
- donaldguy 8y ago
  I mean, depends on your MUA in practice. I think by standard for server side threading— https://tools.ietf.org/html/rfc5256 https://tools.ietf.org/html/rfc5256 — "base subject" is definitely a valid consideration. I only skimmed though. :-) feel free to extract a spec, I'm curious (but not enough to read 19 pages right now)
  - zAy0LfpBZLC8mAC 8y ago
    If I may quote: ORDEREDSUBJECT The ORDEREDSUBJECT threading algorithm is also referred to as "poor man's threading". The searched messages are sorted by In other words: as a workaround for garbage email clients and services too incompetent to use email correctly. Yes, the REFERENCES algorithm also uses the base subject--but never to override message-id based threading, only for merging together threads that couldn't be joined using message-ids ... or in other words: as a workaround for garbage email clients and services too incompetent to use email correctly. Well, and for merging together chunks of a thread where you have major gaps in your mailbox, so that reference headers don't overlap enough to make the connection, but the point remains that it's not really a threading mechanism, just a last-ditch attempt to recover a thread where proper threading information is missing, which is fine for corner cases like large gaps in which messages you have in your mailbox, and doesn't change that a sender that doesn't supply reference headers in the first place is incompetent.

usr1106 8y ago

In Slack threads are an annoyance. They lead to missed answers and discussions, because they are rarely used in average user groups. When they are they default to private only for the writer and appear out of the natural flow for the reader. In zulip every message belongs to a topic. (Well there is the "no topic" topic, but it shouldn't be used and even if it is it appears exactly like every other topic). So no surprises. I have used slack (and irc and xmpp) for a long time, and Zulip for 2 months. Zulip is certainly much better for the geek. Slack user experience is somewhat more straight forward for the naive user not caring about things done "right". For hacker news readers zulip is likely to be the preferred choice. Expect resistence from your non hacker news colleagues / managers / team members.

pm 8y ago
Appreciate the explanation. Is threading such a big deal that people can't live without it? I honestly never found it useful.
- geofft 8y ago
  In busy channels in medium-sized companies, lack of threading is a huge pain: person A says "Hi, I'm trying to do X, how do I do this," person B says "Hi, I'm getting error message Y" 2 minutes later, someone shows up 5 minutes later and says "Have you tried installing this thing" and they were talking to B about solving Y but A tries to install it and use it for X and then everyone is confused and wastes time. Slack is positioning itself as an email replacement, and to some extent all of these tools are replacing at least some email. Imagine taking 20% of your email and not having subject lines, just authors. What's the "LGTM" for? (Or worse, the sender anticipates that and says "Re @pm at 00:10, agreed" and then you get to track that down.) Or imagine taking your in-person conversations, the ones that you'd eventually want to move to IM to support distributed or remote teammates, and having a rule that you couldn't go up to someone's desk, instead every in-person conversation had to take place at this one water cooler. If multiple people wanted to talk, well, either they can have multiple conversations in front of each other, or they can wait until one conversation is done. (Slack's implementation of threading, meanwhile, doesn't actually solve the problem that well because of the way it pushes threaded conversations to a side. Imagine email without a reply-all button - it solves some problems and creates so many others. You can and should live without Slack threading.) ... also, another argument that threading matters: you're using a threaded forum right now. Remember phpBB? Would HN be improved by switching to a phpBB-style UI? If you unindented all the comments on this page and sorted them by time, would it be a workable experience?