Threaded messaging comes to Slack

https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd

by hswolff • 10 years ago

258 89 10 years ago

I'm actually a bit sad about this. To me the whole thread thing is the biggest issue with Microsoft Teams. In my opinion it really makes the channel hard to read and keep track of. I like the first part of the Slack implementation where the thread opens up in a new pane on the right but where it falls apart (for me) is how it displays in the main channel.

Navarr• 10 years ago

I feel the same way. I think the way its burried is good for the product.

You don't want EVERYTHING to be a thread, but sometimes - rarely, you do want something to be a thread for the sake of the flow of the particular channel.

tabbott5• 10 years 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-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)

bluetidepro2• 10 years ago

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

tabbott5• 10 years 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.

tedmiston• 10 years 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• 10 years 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.

coldtea• 10 years ago

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

shawndumas• 10 years ago

iOS client not avail in US?

tabbott5• 10 years 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.

jc4p• 10 years 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-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.

lima3• 10 years 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.

jasode• 10 years ago

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• 10 years 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.

tabbott5• 10 years 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.

madarco• 10 years 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• 10 years 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• 10 years 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.

abalone• 10 years 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.

ryanbrunner2• 10 years ago

I really think one of the things that Flowdock nailed was their threading implementation - it took a little bit of getting used to, but not much, and allowed contextual conversation without feeling like the conversation was buried in a thread somewhere (as this implementation does). For people interested in the thread, you could focus on just that, but for everyone else, it just acted like a normal chat room.

Considering how long Slack has been promising threading, this seems really half baked and poorly thought out.

rasjani• 10 years ago

Came to mention Flowdock and ask for comparison. On busy channels 'flows' where really good feature. Too bad the product is not that known.

arjie• 10 years ago

FlowDock's threading is vastly superior, in my opinion. Everyone can see progress along threads, and conversations can stay separate.

truebosko• 10 years ago

Never heard of Flowdock but it sounds very compelling. We're currently looking to get our enterprise on Slack and the costs seem .. unreasonable, and I feel that's because Slack is the top player in the game and can ask for such pricing.

Hmm.

ryanbrunner2• 10 years ago

Don't choose Flowdock. It was an amazing tool, but since they were acquired, development has completely halted and it's unfortunately stagnating.

I still think it beats Slack in many ways, but it doesn't appear to have much of a future.

graphememes• 10 years ago

Yep, flowdocks implementation of this feature blows the slack variant out of the water and into space. I seriously wish companies would go back to flowdock.

maknz• 10 years ago

Flowdock was great until CA bought it. Now it's pretty much on life support. No support (it's all 'community' now, whatever that means), buggy as heck, no updates in years, the Twitter account is dead.

brazzledazzle2• 10 years ago

CA makes me wonder if they have a strategy in mind for acquisitions or if the plan is to put them on life support collecting fees from customers too invested to switch.

Sir_Cmpwn3• 10 years ago

On IRC you just take the discussion to another channel, which can be created ad-hoc and trivially disposed of when no longer necessary. Or you just become good at reading around multiple conversations at once. There's also no expectation that you need to read everything to catch up when you come back after a while - take that to email if you need to.

Much better real time chat culture, imo.

netcraft• 10 years ago

I think for me the problem is that the answer to a question may come much later than the question and other conversation might have taken place since. Certainly is the case with our remote team. (that said, I can't get the post to load, so I have no idea if this will help or hurt)

Sir_Cmpwn3• 10 years ago

Happens all the time, not a problem. On IRC most people direct mentions somewhere - mention them and it'll show up in their notifications when they come online. They'll mention you in their response and show up in your notifications, too. No one having any other conversations is generally bothered by another conversation happening a few lines at a time every few hours.

bluetidepro2• 10 years ago

To be fair, that same trivial disposed chat concept you mentioned lives in Slack, as well. It's incredibly easy to quickly make a group DM chat from a channel.

"There's also no expectation that you need to read everything to catch up when you come back after a while - take that to email if you need to."

Slack doesn't require that expectation, either. You can easily change settings of Slack to just ignore messages that you were not there for, just like you are describing.

While I actually do like IRC also, your two points are pretty weak considering Slack does both of those well, too.

Sir_Cmpwn3• 10 years ago

I'm not saying Slack doesn't have the features to support this. I think that the addition of threads are a response to a lack of this culture.

colept2• 10 years ago

Isn't the whole point of Slack to reduce friction and make teamwork easier? The name is Slack after all :)

IRC in it's heyday was alright but I think Discord has replaced it's function. The last few encounters I have had with IRC have been negative because of the "in-group" being unwelcoming.

PascLeRasc• 10 years ago

Their site seems to be down, but I really hope Slack doesn't make this permanent. I really like the single discussion stack and the rest of my group I use Slack with isn't techy enough to switch to IRC.

obiefernandez• 10 years ago

This is annoying. I know people use Slack in different ways, but as a fan and long-time user in a variety of different contexts (from a few users to hundreds) I've never, ever said to myself... "man, I wish Slack had threaded messaging."

I worry that they're gonna start messing with what made them special in the first place.

scrollaway• 10 years ago

We've been using Discord at my company. Granted we're in gaming and it's very gamer-oriented, but it fits really well. And it doesn't have threaded messaging :)

hug• 10 years ago

Discord is by far and away the best Electron app I have ever used. I don't know what their secret sauce is, but it's the first time I haven't run back into the arms of a functionally-inferior competitor product written in literally anything else. It's responsive to input at all times, doesn't eat all of the RAM in sight, and doesn't consume unnecessarily large amounts of CPU cycles.

VS Code is second best and somehow manages to best Atom in every way, but is still painfully sluggish at times (on a i7 6500u, no less) and isn't exactly RAM friendly.

Slack desktop is basically a dumpster fire, and from what I can tell Slack's attempt at mitigating that are to piss on it.

mi100hael• 10 years ago

All that made them special in the first place was offline history and mobile apps for IRC. If anything, their shitty Electron desktop client is a downgrade.

scrumper2• 10 years ago

Yep, fairly heavy user here and it's basically fine for me, probably because I'm used to it. Simplicity works. Only thing I really wish for is a proper, first class, not-electron desktop app.

duderific• 10 years ago

Can you elaborate on what you find lacking/problematic in the Electron app? I find very little difference between it and any other proper desktop app. I'm on a 2013 MacBook Pro and I find it works very well.

STRML• 10 years ago

That hit me pretty acutely today when upgrading. Restarting slack took 15 seconds and pegged all 4 (8 logical!) cores. Why should a chat app ever do that?

I get that a billion dollars doesn't buy what it used to, but it really ought to buy native apps on at least all the major platforms.

mileycyrusXOXO• 10 years ago

I also wish it had a native application. For my previous job I had to work on an 8GB Mac. Using Slack with 8 or so teams ate just short of 2GB. The solution was to start opening 1 or 2 teams in the browser at a time. One of the nice things about chat is being able to rapidly and immediately communicate, not being able to have my teams open all the time defeated that. I ended up running a ZNC server on AWS for persistent IRC connections to the Slack channels. This allowed me to have 8 teams open and be connected to a dozen IRC channels for under 2MB of RAM.

rcarmo• 10 years ago

I completely gave up on Slack's desktop app and just use a browser. On the Mac, wrapping three teams in a Fluid custom browser saves me nearly a gigabyte of RAM...

colept2• 10 years ago

For mixed teams, where tech and non-tech types interact - this is brilliant.

Each channel has a purpose, but threads allow more efficient cross-talk. For example I work with another team in a different channel because our projects use the same language. Sometimes our work collides as we work with the same libraries. We lose track of details between repos and channels frequently because we operate parallel but separate.

Threads will allow us to cross-talk about issues that affect both projects without having to create a new channel for each issue. This also helps one off discussions where two or three people use a public channel when the topic should be private. Ultimately, features like these matter mostly in use and I think this implementation is great for my teams.

VA3FXP• 10 years ago

So what do you get when you put IRC and Usenet into a blender?

A mess.

If my memory serves me correctly, isn't this part of what Google Wave was offering?

My company uses slack. I despised it at first, I tolerate it now. I suspect that we are not using it to it's full potential either.

allover2• 10 years ago

Despise/tolerate/mess? The basic offering is a simple chat client with 'channels' and an easy signup/invite flow afaict.

myowncrapulence2• 10 years ago

Slack is the poor mans IRC. The Dropbox of messaging apps. It's easy but if you want to hide your email from public view or customize anything good luck. Slack is notoriously ignorant to customer requests.

viraptor• 10 years ago

To some extent, yes, it was. I used it for uni projects and remember enjoying the idea a lot. It's the the implementation that was terrible. (Mainly due to performance)

nkantar5• 10 years ago

Is this really more important than some rather basic messaging principles Slack is still ignoring?

- No way to ignore/mute users. Yes, I sometimes need to do that even on my team.

- Group DMs inherit notification preferences of channels instead of DMs.

- No visual distinction between "/me says hi" and "_says hi_". (OK, may be minor, but as a long-time IRC user it's quite annoying.)

I can't wait for this threading to introduce the headaches inherent to some users using them and others not.

nkantar5• 10 years ago

Another thing I completely forgot about: no mention of keyboard shortcuts for threads...

okdana• 10 years ago

Some other basic issues i have with Slack:

* Spell-checking is semi-broken on macOS when you have more than one system language specified.

* A few months ago they broke the holding-Shift thing when uploading files.

* The fake Markdown is awful. Aside from the fact that the syntax is just close enough to actual Markdown to be confusing — and i realise that's probably not something they'll ever fix, due to inertia if nothing else — the parser is extremely naïve (maybe based on regular expressions?). Notably, it doesn't support escaping, and it has weird issues with certain special characters (for example, it can't render the string `a|b` as in-line code because it contains a pipe).

* The cost for the paid version is really steep if your project/organisation is on a limited budget. I wish they would introduce a lower-priced tier.

* Maybe they aren't interested in this demographic, but a lot of people really want to use Slack for non-business-related purposes, and they've done nothing really to make that easy in terms of administration/management. Many people with this use case are moving to Discord, which is a shame in my opinion because the Slack client, despite its problems, is still (for now, at least) vastly superior for text-based communication.

* I know it's kind of petty, but they haven't updated the client to support the emoji added since Unicode 8.0 in summer of 2015.

baddox• 10 years ago

Well good, at least the Shift upload thing isn't just me. That's been frustrating.

nkantar5• 10 years ago

Oh, the fake Markdown is indeed awful, I've almost gotten used to that. It's incredible how often I type "something" only to have to press "Up", edit to "something", and "Return". So close, yet so far away...

chaostheory• 10 years ago

Not sure if it's just me but Slack's notifications just aren't good enough. I want something stickier like pretty much every other native IM client that existed before Slack

DoofusOfDeath• 10 years ago

The fake Markdown is awful.

+1 on this. I'd be much happier with Slack if they supported Github style markdown, including syntax-highlighting.

I don't understand objections to this based on inertia. The markdown style could be specified on a per-channel basis: traditional or Github-like.

If my team ever moves away from Slack, it would most likely be because of this issue.

tupshin• 10 years ago

Given that none of those things are important to me, and that threaded messaging is important to me, I suspect we have very different answers to that question.

nkantar5• 10 years ago

That's fair. My question was fairly rhetorical, and a bit flippant.

We all have different requirements. I can understand that threading may be important to some, but feel that ignoring users and consistent notification defaults are on the same level.

In fact, seeing as how notifications are already implemented, I see the inconsistency (which has caused me to miss important messages on multiple occasions) as a bug, which should take precedence over a new feature.

But still, clearly many feel differently, and that's OK. :)

chx• 10 years ago

The footer is broken, the "multiple people typing" leads to the front page.

tdburn• 10 years ago

Last year they announced this was coming and I've been looking forward to it. I originally liked the implementation in flow dock. Maybe they'll put this out there for experiment and refine it to something that works. And maybe they should make it a feature that can be enabled or disabled as a team

jzl• 10 years ago

Funniest part of all this? This twitter account devoted entirely to the question of threads on Slack and the shout-out to them by Slack's twitter account today:

https://twitter.com/slackthreadsyet

krn1p4n1c2• 10 years ago

IIRC mattermost added this in v3.3.0.

it33• 10 years ago

Mattermost team here, thanks for the mention!

Mattermost had threaded messaging since 2015, it used to be called "Replies" and we renamed it "Threaded messages" in April 2016: https://about.mattermost.com/mattermost-3-4-7/

If anyone wants to try it out, you can join https://demo.mattermost.com/

Mattermost is an open source, private cloud Slack-alternative.

We're "Slack-compatible, not Slack limited" and you'll find all the core features of Slack plus many benefits added by the open source community--like markdown support, translation into 11 languages, multi-team accounts, searchable hashtags and much more: https://www.mattermost.org/what-slack-might-learn-from-its-o...

dwndwn• 10 years ago

hey, can you guys write a native android app? web-embedded is unacceptably slow.

this is a core feature of slack.

krn1p4n1c2• 10 years ago

No problem, I'm a fan of the product. Been using it since v2.1.

pfarnsworth• 10 years ago

What I want more is columns in Slack so I can see conversations in multiple rooms without having to click back and forth on them whenever a new message pops up. It's annoying that I can only see one at one time when I have so much screen space.

brazzledazzle2• 10 years ago

They used to have scaling issues (maybe still do for certain userbase sizes) so it might not be feasible for them to effectively double the amount of real-ish time updates.

It would be really handy for informational channels where generally you're just interested in reading updates, not replying. Something like that could reasonably live in the right-hand sidebar. Taken a step further, it would be really cool to be able to specify an official informational/status sidebar channel to be paired with your channel. For example: a team channel with a build status channel linked to it by default.

ak217• 10 years ago

Came here to mention Flowdock. IMO Flowdock nailed the chat UI layout for modern chat systems with API-driven integrations. It's too bad it hasn't seen wider adoption, since its bigger competitors, especially Slack, still have no clue how to fix the noise and focus problems.

Flowdock introduced three killer features that I still haven't seen properly matched by anyone else:

- It introduced threading. (Why we're here)

- It introduced a seamless, intuitive way to switch between the unfiltered channel and a single thread (or to start a thread), by clicking on the colored bubbles next to each message.

- It separated bots from humans (inbox vs chat), making it very easy to have or follow a high value conversation without being interrupted or distracted by a stream of bot announcements.

I think Slack has a lot to learn from Flowdock. I miss Flowdock dearly now that Slack is the de facto standard that everyone uses.

newman314• 10 years ago

I would rather have subchannels than threads.

spilk• 10 years ago

Maybe I'm just overly paranoid but I've never understood the appeal of Slack - I personally don't want to ship all of my internal proprietary business communications offsite to a third party.

wapz• 10 years ago

I think it really depends on what your team needs to discuss, but from my slack chats we don't discuss any business-breaking proprietary intel. If there's something important a face-to-face meeting is used or video chat (but that's also through hangouts)

maxekman• 10 years ago

I think threads are a great addition but the way they seem to hide the discussion makes it so much less useful. It would be better to just indent the messages and keep the normal flow around it.

neximo64• 10 years ago

Yet still no speed improvements, after all these years.

disordinary• 10 years ago

It's a welcome addition. I work remotely and virtually all our correspondence goes through slack, it's quite easy to lose important information and the search isn't that great.

However the problem is if you use Slack for anything other than transient information then you increase the problem with information sitting in silos, already we've got transient information in slack, information in the project management software, information in the kanban type software, information in issues on github, etc. You add Slack into the mix and it really gets hard to remember what is where.

A service to pull together all the information is probably the next killer product.

EGreg• 10 years ago

Why not simply have threads be channels that are children of other channels?

This way you discourage branching but allow an unlimited amount of it. And each thread has the same properties and rules as a channel.

All you have to do then is solve the problem of listing the channels in the sidebar, which the user is participating in, in a hierarchical way. A user should be able to leave a thread and it would disappear from their sidebar. Simple.

What's wrong with this model?

Threaded messaging comes to Slack

Related Stories