
Threaded messaging comes to Slack - hswolff
https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd
======
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...](http://www.theverge.com/2017/1/18/14305528/slack-threads-
threaded-messages):

> "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](https://zulip.org) has some screenshots
(of an old visual design, sadly), or visit the developer community at
[https://chat.zulip.org](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](https://github.com/zulip/zulip/graphs/contributors)).

(Edited for clarity)

~~~
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](https://news.ycombinator.com/item?id=10281065)

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

~~~
maknz
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.

~~~
brazzledazzle
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.

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

~~~
okdana
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
Well good, at least the Shift upload thing isn't just me. That's been
frustrating.

~~~
nkantar
Now that I read up on what Shift+upload is supposed to do, I wish it worked.

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

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

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

~~~
myowncrapulence
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.

~~~
arnvald
Whenever someone compares Slack to IRC I try to imagine my company, where 70%
of people are non-technical, using some IRC client as our chat app. There's no
way this would happen.

Slack was never meant to replace IRC, it was meant to be used at work. Why
would you hide your email from your colleagues?

~~~
myowncrapulence

      Why would you hide your email from your colleagues?
    

..

    
    
      using some IRC client as our chat app
    

Try IRCCloud, it's extremely simple and much better than Slack in almost every
way.

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

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

~~~
bluetidepro
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_Cmpwn
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.

~~~
Kiro
I use Slack exactly like I'm using IRC. There is no universal culture.

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

------
jzl
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](https://twitter.com/slackthreadsyet)

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

~~~
brazzledazzle
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.

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

~~~
scrumper
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
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.

~~~
poink
I'm not the person you replied to, but I don't love this:
[http://imgur.com/a/P4TTE](http://imgur.com/a/P4TTE)

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

------
krn1p4n1c
IIRC mattermost added this in v3.3.0.

~~~
it33
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/](https://about.mattermost.com/mattermost-3-4-7/)

If anyone wants to try it out, you can join
[https://demo.mattermost.com/](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...](https://www.mattermost.org/what-slack-might-learn-
from-its-open-source-alternative/)

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

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

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

------
EGreg
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?

------
newman314
I would rather have subchannels than threads.

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

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

------
neximo64
Yet still no speed improvements, after all these years.

