3 ms·

I didn't get why everyone was getting hyped over a product without threads when they were the most useful part of Flowdock, so I'm glad you're trying to think a

I didn't get why everyone was getting hyped over a product without threads when they were the most useful part of Flowdock, so I'm glad you're trying to think about it further. But the flat thread model is still limited, particularly for complicated topics even a thread starts having the same problem as a channel where there is too much going on; have you thought about tree-structured threads, or some way of branching threads when there is a bunch of discussion happening on different topics? I haven't really used Slack much, but one of the other places with lots of space for improvement in Flowdock was search, and Slack does seem to be investing there significantly, and I hope Zulip is as well.

tabbott 8y ago
We've thought about a tree-based model, but our current thinking is that a feature of that form would add a lot of UI complexity, for fairly limited benefit. One of the key things we'd lose with a tree-based model is the ability for someone catching up on a conversation to efficiently read it without a lot of jumping around between different views (or having to read a tree, rather than a linear history). With Zulip's existing model, you can always fork off a side discussion by just starting a new topic, if appropriate adding links in one or both directions (and people pretty naturally do that when it makes sense to). Some Zulip users are fans of a convention to name a topic "original_topic.d" for a "digression" off a topic, but I think it's a much better approach to choose a topic that more directly suggests what the forked conversation is about. (And I agree search is really important! If you're having lots of high-value conversations in a tool, it needs to be easy to find them later. Zulip's powerful full-text search has been praised as a lot better than Slack's since our very first prototype version of it. I think a big part of the reason is that the threads provide the context to make it easy to find the rest of a conversation. But we're always working on making it better).

tabbott 8y ago

We've thought about a tree-based model, but our current thinking is that a feature of that form would add a lot of UI complexity, for fairly limited benefit. One of the key things we'd lose with a tree-based model is the ability for someone catching up on a conversation to efficiently read it without a lot of jumping around between different views (or having to read a tree, rather than a linear history). With Zulip's existing model, you can always fork off a side discussion by just starting a new topic, if appropriate adding links in one or both directions (and people pretty naturally do that when it makes sense to). Some Zulip users are fans of a convention to name a topic "original_topic.d" for a "digression" off a topic, but I think it's a much better approach to choose a topic that more directly suggests what the forked conversation is about. (And I agree search is really important! If you're having lots of high-value conversations in a tool, it needs to be easy to find them later. Zulip's powerful full-text search has been praised as a lot better than Slack's since our very first prototype version of it. I think a big part of the reason is that the threads provide the context to make it easy to find the rest of a conversation. But we're always working on making it better).