How much is Zulip different from other thread-based productivity tools in the way it works? Examples are Spectrum, Discourse or even GitHub.
All of the examples uses the concept of thread as the basis of the conversation, but in the order I mentioned they are more focused on longer and persistent messages, like the main topic body. Is it a reason Zulip is preferable to those tools?
Well one response is that maybe we don't want to optimize for persistence as much as those platforms do
but its not a very strong argument
Are any of those platforms optimized for live chat?
For example, I'm not aware of any one using Discourse or Github for live interaction in practice. (Maybe I'm missing out on something.) And I had not heard of Spectrum before you mentioned it, so I cannot comment on it.
but in any case, skimming over a sample dialogue on spectrum.chat, and based on my own use of discourse, my most immediate reaction of why I prefer Zulip for live chat is that it encourages short messages
Encouraging short messages is what enables, hopefully, interruption from others (when necessary/relevant; no one wants to just invite noise)
which is necessary for true dialogue.
Conversely, when the UI encourages a person to spell out an email sized chunk of text, that is going to introduce latency on each step of both writing and reading
seconded, i like zulip because it has the immediacy of a chat program while the threading often avoids new messages drowning out unrelated older ones
Last updated: Oct 11 2021 at 22:34 UTC