Comment by rafd | Hacker News Reader

Comment by rafd | Hacker News Reader

Hey HN! One of the creators of Braid here.

We started Braid internally in the pre-Slack days (we were using HipChat then), because we felt that "chatrooms" didn't promote good async team workflows. They would lead to a lot of FOMO and constant checking, because if you didn't participate in a conversation at the right time, the topic in a channel would have moved on to something else. We liked the async nature of email more, but, email has it's own baggage.

Our team has been using Braid internally for several years and we're very happy with it. But, compared to Slack, it's best thought of as a prototype / experiment / UI-proof-of-concept, because we don't have the polish and maturity of features that Slack has.

We've had interest from some individuals who "get it", but it's often been hard for those individuals to convert the rest of their teams. If any team here is interested in the Braid concept and wants to give it a serious go, I'm at your disposal, and I'd love to get your feedback so we can keep morphing the product.

The use of "hashtags" in our demos is a bit overdone compared to what happens in practice. It makes it seem like twitter #hastags, but, it's really more like Gmail labels. Braid tags serve the same purpose as Slack's channels, except a given thread can exist in multiple channels (ie. go to multiple teams / individuals) and tags can be added over time (ie. more people can be invited to the conversation).

In essence, this moving conversations from a “category” ontology (mutually exclusive, collectively exhaustive) to a “tags” ontology. In a sense this is rediscovering email/list addresses with cc ;-)

One can set up “tag subscriptions” (propagating hooks) for tags, such that at the lowest level, the messages you see are all the messages you’ve been tagged in. This can even be made declarative, so adding/removing tags can re-jig who will see which conversations.

There is an obvious niceness to this approach :-) What would you say are the problems/challenges with this modeling of the domain?

Very nice to see some innovation in this space, I wish there were more novelties like this !

Like someone said in the thread, I know that Zulip has a similar system (although I've never used it): you have predefined "rooms", and inside each "room" you can start a new thread, with its own topic, much like a new email thread. From what I can see the home view can directly show all snippets from all conversations directly, without having to jump from room to room. Also, since you're not interested in _all_ the discussions in the room, you can only follow some. I guess it's the same for Braid ?

Speaking of similarities, Google Chat (the one for GSuite accounts) still has a similar model: you have rooms, and in each rooms you must create (unnamed) threads and you can chooses which one to follow (and be notified for). Unfortunately the UI is not very well done, all threads are stacked vertically so you can't switch from one to the other easily and a lot of screen estate is lost. I think this is where Braid might do things better.

One thing that Braid does is it essentially hides all the conversations you're not interested in. However sometimes I had to search for something I didn't really remember, and I only could find it because I had a rough idea about what appeared before or after, or the time it was said. Is there a way to do the same with Braid ?

Lastly, thank you for making this open source, it's rare enough that it needs to be underlined. Oh and I see matrix integration is on the roadmap ? Would that mean that Braid would essentially become a glorified matrix client ? I don't mean to sound negative, I'd really wish to try it but I can't use it if I have no one to talk to, so I'm gonna follow Braid closely in the future.

> lead to a lot of FOMO and constant checking

An alternative view - you just let go those conversations - saves time :)

Btw, can you please say a couple of words about the tech? (this is HN after all) - I see it is Clojure (not ClojureScript) - so how do you use it for the front-end?

> I see it is Clojure (not ClojureScript)

Nope, the source code is full of of both ClojureScript and Clojure.

Re: letting them go... I guess it depends on how you use chat. For us, most conversations in Braid are bonafide work conversations that are important and can't be skipped (ex. we run our board meetings asynchronously via Braid, discuss major product decisions, etc.)

The way I see most Slack used most of the time, though -- as a digital watercooler -- I can see why it's fine to skip most conversations.

Re: tech; it's clojurescript front-end; clojure backend.

An you expand the width of the chat streams? That’s what really gets me on Slack: the fixed width of threads makes talking about code impossible. Also, slack doesn’t even try to highlight code.

Not at the moment, but it is a pull-request away. :P

I'll put adjustable-width-threads on our roadmap. ...but if anyone reading this wants to work on it, it would make a decent 'first PR', and I'm available to pair remotely to help you get started. (email in profile)

So much this. It seems to actively encourage NOT using threads. The mobile experience is somewhat better except it's a disorganized mess and I believe they force the auto rendering WYSIWYG. (Stopped updating after they told me they wouldn't support non auto rendering on mobile.)

> FOMO

I don't understand this aspect. In Slack/Mattermost/IRC I might regularly check the #dev channel, or I might not. In Braid I might regularly check conversations with the #dev tag, or I might not. Why do you think the UI encourages or discourages this behavior?

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).

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.

Hope you got a thumbs up from ol' Jon Blow on the name.

https://en.wikipedia.org/wiki/Braid_(video_game)

Reply on news.ycombinator.com