Braid – A team-chat app with a novel UI for better conversations
github.com
github.com
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).
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)
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?
Nope, the source code is full of of both ClojureScript and Clojure.
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.
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?
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).
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?
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.
Not convinced that tagging is better than channels for large teams. Seems like there would be an explosion of tags to keep track of.
Disclosure: I work at Microsoft but not on Teams.
I think a conversation-first comms platform is a brilliant idea (though not sure this fits Braid). Instead of channels that can languish and/or have multiple conversations all jumbled up, you get a new window for a new conversation, even if it's the same group of people. With easy searching and archiving I think it could be great. If it isn't a thing in Braid or wherever else maybe I should shut my mouth and start a product
Braid's search is certainly something that can be improved. In practice, it's actually pretty rare to have to fish for something in the archives, because you tend to keep relevant conversations open until you're done with them. (We also have "starring", like in Gmail, so that you can move conversations out of your inbox, but still keep them easily accessible).
On a day-to-day, a good "search" experience might actually be more relevant for slicing-and-dicing through your Inbox (ie. triaging the firehose of daily messages), rather than digging up old messages.
The way we use Slack at work, most conversations spin out to threads, and there is no jumbling up. If people in your organization aren't disciplined enough for Slack threads, I can't imagine that those people would be disciplined enough for keeping conversations separate either.
I feel that this functionality would be quite useful, but easily integrated into existing clients by doing "Saved Searches", "Smart Spaces" or whatever we want to call it.
That could lead to a feed with just the relevant tags / keywords as a stream. And clicking on them would lead one back to the context.
In the mean time, we can accomplish this with a bot. It's not as elegant but I think it would work. Not just in Webex Teams but the others as well. Will dig into that and see what I can do...
The design seems to think that'll you'll be closing chats to keep things uncluttered, but the chat just pops back up if someone else sends a message to it, so I imagine this would turn communication into a game of whack-a-mole and I'd guess that it would (d)evolve into a few relevant persistent conversations pretty quickly.
Honestly it reminds me of GChat in the GMail client, except I don't get to see my emails while chatting and conversations are cluttered with random hashtags.
My first thought exactly. Speaking from experience on our current chat platform, after one conversation on a topic ends (assuming it does definitively end, and doesn't overlap with other conversations), its not long before another begins.
In practise, I tend to go through conversations 1-by-1 and either reply and close them, close them without reply, or star them and close them (for review later).
Re: whack-a-mole, you control which tags you're subscribed to and you can mute message threads you're not interested in, similar to how you can mute channels in Slack.
I've been curious about Zulip (https://zulipchat.com/) for a while, but have yet to use it for anything.
The fact that Braid explicitly calls itself an "email/mailing-list/web-forum/chatroom hybrid" sounds promising to me. That's roughly what I'm wishing for, and is how I've described what I want before.
Does anyone here have hands-on experience with Braid?
More generally, are there other tools you've used or heard of that might fall into that category?
The founder is pretty present here on HN and I suspect he'll join this thread shortly. Aether is unreal at removing Slack distractions and chaos and bringing focus to messages that are important.
The two biggest challenges I have with Slack are battle between checking every notification (annoying) and ignoring notifications and ending up missing something important (also annoying). Aether solves that quite well in addition to other issues.
I have heard some people have difficulty getting people to use topics properly (i.e. not putting everything in one topic), although we didn't have that problem. Possibly its an uncanny valley issue - it's too close to Slack/WhatsApp and so people just slip into that habit. I could see that something like Braid which feels very different could force new behaviours to be created.
Call me prude, but this kind of copy turns me off to the product.
As teams scale, this becomes a process and enforcement issue. The video didn't convince me trading memes for the headache of telling Steve to use this tag hierarchy every time and to not snake case is a worthwhile investment.
Since the UI/UX is the biggest innovation here, I somewhat understand the decision but I'm sure it'll limit adoption by the majority of people that want to host their own chat platform.
The self hosted version of tools that offer a subscription service like mattermost are very limited in search and archiving, the ones integrated in hardware appliance like synology chat are very limited in admistration capabilities (moderation, permissions,...).
Did I miss an offering somewhere or is this a still open area?
Main needs 1-1 chats, channels, permission per user per channel, full logs and search, administrative view and archiving over all exchange
I think its a novel concept, that needs a lot of polish, but that video ouch that was rough.
It keeps the nuance and emotion present, can be async (think leaving voicemails) and is searchable.
Braid looks like it’s trying to solve a problem that doesn’t really exist. If anything it adds more problems than it solves. Instead of navigating to a general channel for “marketing”, now I have to remember some hashtag that an intern created to recall that exact conversation.
This is no different than message threads within a channel and just searching by keywords.
Otherwise the only thing discord has going for it is the network effect.
If image support and emoji are considered "peak innovation" then MSN Messenger beat them to it a decade ago.
I don't understand this, Discord is one of the most reliable voice chatting applications I've used. Honestly I wish MS Teams would implement voice channels similar to Discord. It would be so much nicer to just drop into a voice channel instead of sending out invites for a meeting.
Not that I've needed to do it, but have you tried disabling all of your unused audio input/output devices on your computer? If you don't use things like line or mic in on your motherboard, disable them. It gives Discord less things to try to bind to.
It's not just me, either.
Not really solving any problems I have with chat, seems it actually creates more chaos than slack