[rafd]

If you're using Slack/etc. primarily for "optional conversations", where not-reading or not-participating is no big deal, then Braid's design adds nothing for you.

But, if you are trying to have necessary conversations with your remote team, make decisions, etc., then I think Braid's approach helps.

Say in Slack, in your team's #dev channel, a conversation starts: "should we do X or Y for this feature?" with several replies. A few minutes later a new conversation starts "for this other thing...", more replies. And maybe a few other topics.

You happened to have been on a call for the last hour (or getting some focused coding done) and pop into the channel to see 50+ messages spanning 4+ conversations. Hmm... it looks like your colleagues overlooked something important about topic #1, but, the last 40 messages have been about topic #2, #3, #4, and they're currently talking about #5. You can try to restart the conversation about topic #1 (interrupting the current in-progress topic), or try to juggle multiple topics in the same room at the same time. It's doable, but it's a mess. The more active the channel, the harder this is to do well. Result: you train yourself to keep checking so you can participate at the right time.

If everyone was using Slack's threading ability, this would less of a problem, but, in practice, Slack's threading UX is an after-thought and I see Slack threads being used rarely.

Braid allows you to be a part of multiple separate simultaneous async conversations "in the same channel" (we call it a tag).

[tom_mellior]

Thanks for the detailed answer. Everybody in my team uses Slack threads properly, so I guess the difference for us would be minimal. Also, I think people who lack the discipline to use threads might also undermine Braid's system by just keeping one #dev tag open and posting everything in there.