7 ms·

I've spent a lot of time thinking about the problem of how to make threading work as the lead developer of Zulip, an open source group chat application where ev

by tabbott 10y ago

I've spent a lot of time thinking about the problem of how to make threading work as the lead developer of Zulip, an open source group chat application where every conversation is threaded, and I think adding Facebook-style comment threads to messages is the wrong approach. Fundamentally, what you want is to be able to read and participate in multiple conversations with a given group of people (a channel) at the same time, with as little overhead as possible, and when catching up later, you want to be able to read one conversation at a time, not all of them mixed together. And you don't want to have to go into some special mode to do so; you want it to feel like the default thing to do. I don't expect this to get a lot of use. The data Slack mentioned to the press shows that even Slack employees hardly use the feature; from http://www.theverge.com/2017/1/18/14305528/slack-threads-threaded-messages http://www.theverge.com/2017/1/18/14305528/slack-threads-thr...: > "But employees at Slack, who have been testing threads for months, say they are meant to complement public channels — not replace them. Joshua Goldenberg, the company's head of design, told me that only 7 or 8 percent of his time in Slack has moved to threads." If the people at Slack's who designed this feature hardly use it, I doubt it's going to solve the big problems with Slack/Hipchat/Campfire/IRC, namely that their chat room model doesn't work once a channel gets beyond a few dozen actually active participants. If you're interested in a good solution to this problem, check out how Zulip does threading (https://zulip.org https://zulip.org has some screenshots (of an old visual design, sadly), or visit the developer community at https://chat.zulip.org https://chat.zulip.org to see it in action). Zulip's threading is the main reason why it's become the open source group chat application project with the most active development community (see e.g. https://github.com/zulip/zulip/graphs/contributors https://github.com/zulip/zulip/graphs/contributors). (Edited for clarity)

bigiain 10y ago
Say, that's an interesting new wheel you're inventing there! ;-) https://www.jwz.org/doc/threading.html https://www.jwz.org/doc/threading.html (And I doubt jwz was the first smart guy to devote time to that particular problem too...)
- lowglow 10y ago
  His redirect is hilarious.
  - bigiain 10y ago
    Oh yeah - I'd forgotten about that. Maybe copy/paste that url instead of clicking it... ;-)
bluetidepro 10y ago
Your comment seemed pretty genuine, until you had the 3 paragraph plug for your Zulip product that competes with Slack.
- tabbott 10y ago
  I've spent a lot of time thinking about all the possible solutions to the problems associated with chat rooms. The issue that it's hard to talk about multiple things at the same time in a channel is common to Slack, IRC, Jabber, and just about everything else. So have spent a long time designing and building a better solution to those problems. It's hard to talk about Slack's threading solution without also talking about what I think is the best way to solve that problem.
  - lima 10y ago
    Zulip is great. After using it for a while, I no longer want to use anything else. The light-weight topics make a lot of sense. You can quickly discuss a topic and then forget about it. With Slack, you'll need to create a new channel, invite people into it, it's just much more overhead so you end up discussing in the main channel. A huge issue with Slack, for me, is catching up with busy channels. You have to read all of it since you miss discussions on topics you're interested in. Zulip has a great solution to this issue. I'm also impressed with how high-quality it is. They even have Nagios checks and everything. It has many features you miss in other products like Rocket Chat (full text search. administrative tools, ...). Edit: relevant comment from another thread. https://news.ycombinator.com/item?id=10281065 https://news.ycombinator.com/item?id=10281065
- tedmiston 10y ago
  I found it tasteful and relevant and didn't feel spammy because of the discussion contrasting a feature many people want that Slack doesn't have (or didn't until today and may not still be exactly what we want).
- bjterry 10y ago
  Zulip is an open source project with no way to purchase it from what the home page shows, so doesn't seem like that big a deal to me.
shawndumas 10y ago
iOS client not avail in US?
- tabbott 10y ago
  Not available in general. It's a long story, but the original iOS app was pretty alpha, had an obsolete codebase, and wasn't working well. We unpublished it from the app store a few weeks ago, since it was worse than just using the website on mobile. The development community has been rewriting the iOS app in React Native over the last couple months, and the new version is working really well! It'll be in the app store in a few weeks. See https://github.com/zulip/zulip-mobile https://github.com/zulip/zulip-mobile.
jc4p 10y ago
I agree wth this comment a lot. I work at Stack Overflow, where our company chat is split between Slack and an internal chat product we made ourselves years ago. I think the "comments as threads" concept helps solve some specific use cases (like room clutter) but not the use cases I personally care about the most. The "in-line method" mentioned in this other article about the change is my preferred method: https://www.fastcompany.com/3067246/innovation-agents/the-unexpected-design-challenge-behind-slacks-new-threaded-conversations https://www.fastcompany.com/3067246/innovation-agents/the-un... My gripe doesn't stem from rooms being too cluttered, it stems from if there are 4 people talking at once and I'm in two different conversations chains with them, I'd like to explicitly reply to a specific message and carry on the convo. not hide it in a comment thread. On our homebuilt chat product this is the difference between starting a message with `@Name` or hitting "reply" on a specific message and having `@:{Message Id}` as the beginning of your message. It shows the same to the users, they seen `@Name`, but if it's a specific message reply when they hover over the message the one it's in response to gets highlighted (and there's a button to scroll to it if it's off-screen). I think this Slack feature, like most features, is targeted at helping people using chat sitting in the same room or office together. I work at a very remote company where with some people I share less than 2 hours of a work day. I want better chat tools centered around making our async communication flow better. Not out-of-room comment threads.
- lima 10y ago
  > I want better chat tools centered around making our async communication flow better. Try Zulip, actually. We use it and it does that exact thing very well.
  - sfeeney 10y ago
    Any ldap or ad integration?
    - catern 10y ago
      It would be quite amusing if it couldn't work with AD, considering Zulip is based on Zephyr which is a very old chat protocol/application heavily dependent on Kerberos.
Eridrus 10y ago
Have you tried Flowdock? You've described pretty much their exact approach to threading, which I think is the right one. The biggest downside I've found is some people always forget to use the threading feature and comments fall out of the thread. [EDIT]: I just had a look at Slack's implementation and I think it has some pretty cool ideas. I think being able to follow an individual thread at a high level is useful. Being able to have a conversation without bothering the whole channel is useful. I think the idea that threads are private by default is not; I think a good alternative would be to disable notifications for messages in threads you don't care about, but have them remain public.
- tabbott 10y ago
  Yep, I have. It's pretty different from Zulip. Zulip's threading model is much more like a lightweight version of email threading -- when you start a new thread, you pick a short topic for it, and then after that people just reply to the thread.
  - Mtinie 10y ago
    Not exactly the same, but you may find a product I worked on a few years back, www.kona.com, to be of academic interest as someone who is looking at different communication methods. We used a similar "topic" method and allowed users to fork conversations to have the best of both worlds -- linear chat for most cases and topical chat when a breakout was needed.
- madarco 10y ago
  That's why we initially preferred Flowdock over Slack (but I think now we have a clear winner, and I use mostly Slack)
kodablah 10y ago
I too have spent a lot of time thinking about this problem space. I find that there is not a big problem in context switching from one conversation to the next, but rather in the UI and appearance of the switch. The ultimate key is unread message support. By using a single key/approach to jump from one unread message to the next (or mark all messages in a thread as read) in order of oldest unread message, then the rest of messages in that thread, then next oldest unread message, etc, you can make conversation switching easy. It just needs to be clear when you have switched conversations. I hate manually navigating from one channel/room/whatever to the next myself. Also, I think chat and threading essentially conflict. Threading encourages more thought about who you are replying to and how and is less of a stream of consciousness like chat. In threaded conversational modes, I think the chat-like mode should be reduced (e.g. "X is typing", update exactly when completed, auto scroll the screen) and semi-live-update forum-like mode should be enhanced (e.g. a post is fixed in space, no auto scroll, live updates are batched/debounced over at least 2 seconds, etc). Of course, the real answer might be extreme configurability. Any communication system can be like any other with enough configuration options. While default sets may be preferred for chat, forum, microblogging, etc, many people configure "rooms" more than they configure lots of other types of software so there is little "option overload".
- codinghorror 10y ago
  I agree with this. Chat and threading are oil and water to some degree. To me it is the difference between short term and long term memory; in short term memory, forgetting is a feature -- not a design problem to be solved.
tmail21 10y ago
I also agree that adding Facebook-style commenting is not the best approach. It has the virtue however of reducing clutter in a Slack channel (a laudable goal), but represents a missed opportunity in my opinion. Organizing work around a thread-first approach opens the door to many interesting possibilities. Zulip is cool and does a better job than Slack at threading. However, it just scratches the tip of the iceberg as to what can be done with a Thread-first approach. This blog article captures my thoughts on Slack threads: https://tmail21.com/blog/slack-threads-a-missed-opportunity/ https://tmail21.com/blog/slack-threads-a-missed-opportunity/ Disclaimer: I am the CEO of the TMail21
abalone 10y ago
Slack's approach could be very good and the "7 or 8 percent" figure is not necessarily a bad thing. That figure could mean that most of the time, regular Slack channels work well for them. This feature helps address the 7-8% of the time where it's worth splitting off a thread. Contrast that with a tool like Zulip where every message requires a topic, and you have a much more structured paradigm. Percentages mean nothing because it's simply mandatory. That forces more organization, but perhaps part of the appeal of Slack is that it doesn't have to be so organized. You just engage with your team, and the only structure you have to think about ahead of time is which channel to use. So I can see the case for "spot-threading" like Slack is rolling out, while keeping the core organizational structure very simple.

by tabbott 10y ago

bigiain 10y ago

Say, that's an interesting new wheel you're inventing there! ;-) https://www.jwz.org/doc/threading.html https://www.jwz.org/doc/threading.html (And I doubt jwz was the first smart guy to devote time to that particular problem too...)

lowglow 10y ago
His redirect is hilarious.
- bigiain 10y ago
  Oh yeah - I'd forgotten about that. Maybe copy/paste that url instead of clicking it... ;-)

bluetidepro 10y ago

Your comment seemed pretty genuine, until you had the 3 paragraph plug for your Zulip product that competes with Slack.

tabbott 10y ago
I've spent a lot of time thinking about all the possible solutions to the problems associated with chat rooms. The issue that it's hard to talk about multiple things at the same time in a channel is common to Slack, IRC, Jabber, and just about everything else. So have spent a long time designing and building a better solution to those problems. It's hard to talk about Slack's threading solution without also talking about what I think is the best way to solve that problem.
- lima 10y ago
  Zulip is great. After using it for a while, I no longer want to use anything else. The light-weight topics make a lot of sense. You can quickly discuss a topic and then forget about it. With Slack, you'll need to create a new channel, invite people into it, it's just much more overhead so you end up discussing in the main channel. A huge issue with Slack, for me, is catching up with busy channels. You have to read all of it since you miss discussions on topics you're interested in. Zulip has a great solution to this issue. I'm also impressed with how high-quality it is. They even have Nagios checks and everything. It has many features you miss in other products like Rocket Chat (full text search. administrative tools, ...). Edit: relevant comment from another thread. https://news.ycombinator.com/item?id=10281065 https://news.ycombinator.com/item?id=10281065
tedmiston 10y ago
I found it tasteful and relevant and didn't feel spammy because of the discussion contrasting a feature many people want that Slack doesn't have (or didn't until today and may not still be exactly what we want).
bjterry 10y ago
Zulip is an open source project with no way to purchase it from what the home page shows, so doesn't seem like that big a deal to me.

shawndumas 10y ago

iOS client not avail in US?

tabbott 10y ago
Not available in general. It's a long story, but the original iOS app was pretty alpha, had an obsolete codebase, and wasn't working well. We unpublished it from the app store a few weeks ago, since it was worse than just using the website on mobile. The development community has been rewriting the iOS app in React Native over the last couple months, and the new version is working really well! It'll be in the app store in a few weeks. See https://github.com/zulip/zulip-mobile https://github.com/zulip/zulip-mobile.

jc4p 10y ago

I agree wth this comment a lot. I work at Stack Overflow, where our company chat is split between Slack and an internal chat product we made ourselves years ago. I think the "comments as threads" concept helps solve some specific use cases (like room clutter) but not the use cases I personally care about the most. The "in-line method" mentioned in this other article about the change is my preferred method: https://www.fastcompany.com/3067246/innovation-agents/the-unexpected-design-challenge-behind-slacks-new-threaded-conversations https://www.fastcompany.com/3067246/innovation-agents/the-un... My gripe doesn't stem from rooms being too cluttered, it stems from if there are 4 people talking at once and I'm in two different conversations chains with them, I'd like to explicitly reply to a specific message and carry on the convo. not hide it in a comment thread. On our homebuilt chat product this is the difference between starting a message with `@Name` or hitting "reply" on a specific message and having `@:{Message Id}` as the beginning of your message. It shows the same to the users, they seen `@Name`, but if it's a specific message reply when they hover over the message the one it's in response to gets highlighted (and there's a button to scroll to it if it's off-screen). I think this Slack feature, like most features, is targeted at helping people using chat sitting in the same room or office together. I work at a very remote company where with some people I share less than 2 hours of a work day. I want better chat tools centered around making our async communication flow better. Not out-of-room comment threads.

lima 10y ago
> I want better chat tools centered around making our async communication flow better. Try Zulip, actually. We use it and it does that exact thing very well.
- sfeeney 10y ago
  Any ldap or ad integration?
  - catern 10y ago
    It would be quite amusing if it couldn't work with AD, considering Zulip is based on Zephyr which is a very old chat protocol/application heavily dependent on Kerberos.

Eridrus 10y ago

Have you tried Flowdock? You've described pretty much their exact approach to threading, which I think is the right one. The biggest downside I've found is some people always forget to use the threading feature and comments fall out of the thread. [EDIT]: I just had a look at Slack's implementation and I think it has some pretty cool ideas. I think being able to follow an individual thread at a high level is useful. Being able to have a conversation without bothering the whole channel is useful. I think the idea that threads are private by default is not; I think a good alternative would be to disable notifications for messages in threads you don't care about, but have them remain public.

tabbott 10y ago
Yep, I have. It's pretty different from Zulip. Zulip's threading model is much more like a lightweight version of email threading -- when you start a new thread, you pick a short topic for it, and then after that people just reply to the thread.
- Mtinie 10y ago
  Not exactly the same, but you may find a product I worked on a few years back, www.kona.com, to be of academic interest as someone who is looking at different communication methods. We used a similar "topic" method and allowed users to fork conversations to have the best of both worlds -- linear chat for most cases and topical chat when a breakout was needed.
madarco 10y ago
That's why we initially preferred Flowdock over Slack (but I think now we have a clear winner, and I use mostly Slack)

kodablah 10y ago

I too have spent a lot of time thinking about this problem space. I find that there is not a big problem in context switching from one conversation to the next, but rather in the UI and appearance of the switch. The ultimate key is unread message support. By using a single key/approach to jump from one unread message to the next (or mark all messages in a thread as read) in order of oldest unread message, then the rest of messages in that thread, then next oldest unread message, etc, you can make conversation switching easy. It just needs to be clear when you have switched conversations. I hate manually navigating from one channel/room/whatever to the next myself. Also, I think chat and threading essentially conflict. Threading encourages more thought about who you are replying to and how and is less of a stream of consciousness like chat. In threaded conversational modes, I think the chat-like mode should be reduced (e.g. "X is typing", update exactly when completed, auto scroll the screen) and semi-live-update forum-like mode should be enhanced (e.g. a post is fixed in space, no auto scroll, live updates are batched/debounced over at least 2 seconds, etc). Of course, the real answer might be extreme configurability. Any communication system can be like any other with enough configuration options. While default sets may be preferred for chat, forum, microblogging, etc, many people configure "rooms" more than they configure lots of other types of software so there is little "option overload".

codinghorror 10y ago
I agree with this. Chat and threading are oil and water to some degree. To me it is the difference between short term and long term memory; in short term memory, forgetting is a feature -- not a design problem to be solved.

tmail21 10y ago

I also agree that adding Facebook-style commenting is not the best approach. It has the virtue however of reducing clutter in a Slack channel (a laudable goal), but represents a missed opportunity in my opinion. Organizing work around a thread-first approach opens the door to many interesting possibilities. Zulip is cool and does a better job than Slack at threading. However, it just scratches the tip of the iceberg as to what can be done with a Thread-first approach. This blog article captures my thoughts on Slack threads: https://tmail21.com/blog/slack-threads-a-missed-opportunity/ https://tmail21.com/blog/slack-threads-a-missed-opportunity/ Disclaimer: I am the CEO of the TMail21

abalone 10y ago

Slack's approach could be very good and the "7 or 8 percent" figure is not necessarily a bad thing. That figure could mean that most of the time, regular Slack channels work well for them. This feature helps address the 7-8% of the time where it's worth splitting off a thread. Contrast that with a tool like Zulip where every message requires a topic, and you have a much more structured paradigm. Percentages mean nothing because it's simply mandatory. That forces more organization, but perhaps part of the appeal of Slack is that it doesn't have to be so organized. You just engage with your team, and the only structure you have to think about ahead of time is which channel to use. So I can see the case for "spot-threading" like Slack is rolling out, while keeping the core organizational structure very simple.