[tabbott]

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-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 has some screenshots (of an old visual design, sadly), or visit the developer community at 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).

(Edited for clarity)

[jc4p]

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-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]

> 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]

Any ldap or ad integration?

[tabbott]

Yep, see http://zulip.readthedocs.io/en/latest/prod-authentication-me...

[catern]

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.

[lwf]

Just FYI, Zulip uses a similar UI model to Zephyr, but doesn't use the Zephyr protocol internally. (For example, Zephyr doesn't really work when one user is behind a NAT)

(I worked for Zulip, and have contributed to the open-source project)

[jasode]

>The "in-line method" mentioned in this [FastCompany] article about the change is my preferred method: 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.

It's fascinating that the preferences for "flat view vs thread view" get revisited in newer software. Fyi, Jeff Atwood blogged about this 10 years ago in 2006.[1]

Thank you for linking that FastCompany article because it emphasizes that Slack's distinguishing rationale was to visually place threads in a different area of the screen. Whether that proves to be the best tradeoff between flat-vs-thread remains to be seen in the marketplace of ideas.

[1] https://blog.codinghorror.com/discussions-flat-or-threaded/

[Eridrus]

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.

[madarco]

That's why we initially preferred Flowdock over Slack (but I think now we have a clear winner, and I use mostly Slack)

[tabbott]

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]

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.

[abalone]

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.

[kodablah]

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]

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.

[shawndumas]

iOS client not avail in US?

[tabbott]

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.

[bluetidepro]

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

[tabbott]

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]

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

[tedmiston]

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]

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.

[lima]

It's 100% open source.

Zulip used to be a company until they got bought by Dropbox (who were after the team, not the product).

Dropbox decided to open source Zulip and tabbott invested and continues to invest lots of (what I assume to be his free) time to make it happen.

The community around Zulip is extremely active and there's lots of high-quality development happening.

https://github.com/zulip/zulip

[coldtea]

Isn't TFA an actual marketing post from Slack for their new feature?