
Slack channels are a waste of time - tabbott
https://zulipchat.com/why-zulip/
======
whoisjuan
Ok. So their approach to solving this problem is to break down the concept of
single channels into a system of parent channels with sub-channels... Pardon
my cynicism, but that's not going to solve the problem. If this were an
information architecture problem, it would have been solved already by Slack
itself.

Slack's problem is noise and that's not something you can solve easily. Trying
to create new abstractions is only going to increase the cognitive load for
your users. Who wants to have a hundred notification bubbles begging for
attention? No one would ever catch up on anything relevant with this approach.

If you have a noise problem is because you have a system that pushes
information to its users faster than they can consume it. No amount of
information re-decoration or re-abstraction will solve this problem. This is
also the reason why all the social media platforms eventually move away from
chronological feeds and start using algorithmic feeds.

The solution is to narrow the scope of information that is useful or relevant
to the users, but the paradox here is that Slack success comes from creating a
product that is a solution for FOMO (Fear of Missing Out) and not a solution
for keeping people informed about what matters.

~~~
tabbott
(I lead the Zulip project.)

If you talk to people who use Zulip, they will tell you that a better
information architecture actually does make a big difference for communicating
effectively. See, for example:

* [https://twitter.com/b0rk/status/986444234365521920](https://twitter.com/b0rk/status/986444234365521920)

* [https://www.recurse.com/blog/112-how-rc-uses-zulip](https://www.recurse.com/blog/112-how-rc-uses-zulip)

* [https://news.ycombinator.com/item?id=17622987](https://news.ycombinator.com/item?id=17622987) (on the HN frontpage right now)

------
sekasi
Honestly, this read so much like desperate marketing. You're making baseless
claims. "Senior people rarely use Slack channels". Care to back that up with
some facts please?

It takes away from everything the product is trying to do by focusing so
intently on misguided flaws of the competitor product. It's like those Galaxy
vs iPhone ads.

Make the product better.

~~~
hluska
I don't understand why you're being downvoted as this is an excellent comment.

This article read like an advertisement. There's nothing wrong with
advertising, but this isn't even a particularly good ad.

I'd be more likely to try whatever the heck this service is called if they
talked about what they do, and focused less on calling out Slack.

The problem with ads that shoot down your competitors is that your readers are
busy thinking up counterpoints when they should be learning your points.

~~~
derefr
Some services are solutions to a problem people don’t realize they have. To
tell them about the solution, you first have to convince them that they have
the problem. And the problem, in this case, is something created by the UX
choices made by the ecosystem of their competitors.

The first car with seat-belts had to explain in its advertising just how
existing cars are dangerous, before it could explain how seatbelts fix that
problem. People would start off thinking that existing cars are just fine; the
ad needed first-and-foremost to make them believe that they weren’t; to foment
a state of irritation or even disgust at “the way things are.”

——

Not to say it’s always a _real_ problem, necessarily. You can convince people
they have a problem whether or not they would have agreed they have a problem
if they were just provided with some additional straight facts.

See: the invention of deodorant. First take something society doesn’t actually
care about, even if it’s pointed out—the fact that you smell sour after a hard
day’s labor—and make it into an etiquette faux pas for people to be able to
notice that about you in the public sphere. Then you can sell the solution.

Admittedly, even this manipulative version of the technique can still have
unintentional positive knock-on effects: public transit probably never would
have been bothered with as a concept without you and the sardines around you
on the train being deodorized first.

~~~
hluska
I don't think seat belts are a very good example of effective ads. The first
ads for seat belts started showing up in the late 1950s. By 1981, only 11% of
people regularly buckled up. 11% uptake on a device that will keep you from
being killed after ~ 25 years isn't particularly good. Seat belt use didn't
become a big deal until State Farm Insurance sued the NHTSA (and won) in 1983.

As for the rest of your post, you're right, though you can introduce a problem
without devoting hundreds of repetitive words to bashing a competitor. Talk
about how hard it is to use chat in remote teams, or talk about any of the
other problems with chat. That will at least get people to agree.

In this ad, greater than half the content was devoted to bashing Slack. At
best, that's unprofessional. At worst, it's a very poor strategy.

If I were Slack, I'd keep an eye on whatever the hell this company is called
and build the feature of it catches on.

------
pkaye
Actually Slack (and chat in general) has been a benefit for me. I'll slowly
losing my hearing as I age and this habit of communicating by text messages
throughout the day with my work team makes it easier for me to understand
things clearly.

------
evrydayhustling
Named threads is a cool idea, but if it makes a big difference I expect we
will see it in Slack soon enough... If you build a challenger SaaS based on
minor feature tweaks, you risk just doing product research for the better
staffed incumbent.

~~~
bachmeier
> you risk just doing product research for the better staffed incumbent

Zulip is older than Slack, and it's been owned by Dropbox for years, so it's
not accurate to think of them as a startup challenging Slack.

I wouldn't call it a "minor feature tweak" either...it's pretty easy to
implement, but it's a design choice that Slack has decided against.

~~~
price
(I work on the Zulip core team.)

> it's been owned by Dropbox for years

I want to correct this here, precisely because we haven't yet done a good job
of making it clear on the web: this statement is actually a couple of years
out of date.

Dropbox was very graciously helpful for the Zulip project in 2015-2016 (after
acquiring the original startup in 2014). Major things include open-sourcing
the code, obviously -- but then also helping those early users who'd been that
startup's private beta users, who'd determinedly hung on to it for that couple
of years despite the minimal support and uncertain future, migrate their data
seamlessly to the hosting company set up by tabbott, one of the original
startup's founders. (See
[https://news.ycombinator.com/item?id=17623701](https://news.ycombinator.com/item?id=17623701)
today for one such user's telling.)

Digression: That is a far nicer experience than what usually happens when a
startup you like using is acquired by a company that has no interest in the
product! I think they deserve a lot of credit for deciding to do that.

And then since 2016, Dropbox hasn't been involved. I actually used to work
there myself -- I left in order to start working on Zulip. The core team is
employed by that new company (Kandra Labs):
[https://zulipchat.com/team/](https://zulipchat.com/team/)

PS: > it's pretty easy to implement

I think making a threading experience like Zulip's really work well is harder
than you think. ;-) The original startup's team was stacked with engineers
with systems-heavy backgrounds -- most of them colleagues of mine from Ksplice
(rebootless kernel updates) and/or MIT -- and they put quite a bit of careful
engineering into the architecture.

But as you say, it's also a design choice, and moving from Slack's current UX
to a fully threaded one would be a radical product pivot (lots and lots of
details are shaped by that choice) that it's hard to see them making.

~~~
bachmeier
> this statement is actually a couple of years out of date

This is the first I've heard of it, guess there's a lot of outdated
information floating around.

> I think making a threading experience like Zulip's really work well is
> harder than you think.

Well this is HN, where you can build Dropbox yourself quite trivially by
getting an FTP account, mounting it locally with curlftpfs, and then using SVN
or CVS on the mounted filesystem.

~~~
evrydayhustling
For the record, my OP wasn't meant to dispariage hard work by the Zulip team.
When one company has 100x the employees of the other, there is a lot of room
for substantive work to be "easily" replicated.

My main issue is that HN loves to compare products based on UI features that
stand out to front line users, especially dev, and underestimate other aspects
(admin features, sales strategy, community development) that drive value for
users and success for products. Without attention to these things, you can do
good design and difficult engineering without the impact you're looking for.

------
kenhwang
Half my time in Slack is just banter and gifs, the other half is skimming
discussions that would've been a meeting otherwise. I think the time I waste
chit chatting about cancels out the time I've saved from emails, meetings,
briefings, and forced context switching from shoulder tapping. From a
productively standpoint, it's neither a gain or loss. But the real win for
Slack (but also shared with email and tickets) is the journaling aspect of
chat, which is typically leaps and bounds ahead of meetings without minutes or
hallway discussions.

I've also noticed that any channel that has more than ~10 active participants
quickly turns off topic or impossible to follow. That I can blame on Slack's
awful implementation of threading which Zulip seems to do better at.

~~~
grok2
The first problem is actually easy to fix -- make it a rule that anyone that
sends unrelated gifs/makes funny banter gets to buy lunch for the others ;-)
(or makes a charitable donation in proportion to the number of people -- if
the users are geographically dispersed). And enforce it strictly. You'll find
that your slack channel is automatically devoid of unnecessary
chatter...something about having to buy lunch for colleagues brings out the
miser in them :-).

------
nineteen999
Maybe Slack already has this feature (I haven't used it in a couple of years),
but it would be great if we could personally "downvote" users that have an
unsatisfactory signal:noise ratio, and their comments would fade into the
background colour of the page (like HN does with downvoted comments). Or use a
decreasing font size or something to show me that I consider their input less
important in general. This would only apply to messages shown to me, it
wouldn't impact what other users saw.

One of the problems I had with Slack was people with only a tangential
relationship with the channel filling it up with irrelevant noise. Something
like that would help me filter it out a bit.

~~~
krispbyte
Well Slack is typically used for work so it's probably not a widespread
problem but one thing you could do is open a #random channel so people can
post all the noise there.

~~~
nineteen999
This was in a work environment and we had over 50 department and team-specific
channels already, as well as a bunch of random noise channels. Funnily enough,
it was the application developers who were the problem in this instance since
they were being more of a hindrance than a help. Being able to mute them or
quiet them down while I fixed their mistakes and was documenting the
workarounds/solutions would have been very useful.

Perhaps it says more about that company than Slack in general though; it's the
only place I've worked where Slack was used let alone considered mandatory.

------
gouggoug
You do not need to read your entire slack channel history.

Personally, I simply scan for messages addressed to me with an @mention or
@channel.

If there's no @mention, I load the channel, press the escape key and go on
with my day.

~~~
squiggleblaz
yeah the way to use slack (for distributed teams) is the same as the way you
use the water cooler (for office-based teams). you only hear what you're there
to hear. if someone put an audio recorder at your office cooler you'd never
listen to the recording.

however, i think that's their entire point. it's actually not very useful for
actual topical discussions

~~~
ehnto
It depends on the work place, but for the agency I used to work at you would
be working on a particular client's project on any given day and therefore you
only needed to tune into one channel. But more than that, any decisions or
discussions particular to a task happened in the ticket for that task, not in
slack. Slack was used for short periods of quick deliberation and problem
solving environments or configuration, or general state of the project type
conversations. In other words if it didn't fit in a ticket it went into slack.

That worked really well for isolating slack communication to silos of
attention and it solved the problem of information important to a task living
in slack.

Ultimately it's not the tools fault for any of this though. It's just a bunch
of chat channels. It's up to you and your company to form good policies and
practices.

------
cntlzw
We adopted slack after a year of HipChat and a year of Teams. Different
products little value. Most of the talks is in DM and probably full of gifs or
memes. If things get complicated people talk face to face or use the phone.
Meetings are still done the usual way and the gist is send over email.

I think we adopted a chat product just because everyone else does.

Only thing I really like in slack are the integrations. You can have channels
for different kind of events happening in your company: sales, solved jira
tickets etc. So you feel in the loop about what is happening without actually
communication about it.

------
TranquilMarmot
We solve this with Slack where I work by just making one-off channels that are
for specific topics.

These are usually project-focused channels where we only talk about the
project that we're currently working on. The channels can last anywhere from a
few days to a few months, and once the project is done we close the channel.

We find this works really well to keep noise to a minimum since we still have
team-specific channels where the usual noise happens, but if we're just trying
to do work we only focus on the project channel.

------
remarkEon
Headline is a little click-baity, but I get their point. “Streams” seems like
just adding another layer of abstraction to your existing channels. For the
Slacks I’m on having multiple topic-specific channels is extremely useful, and
the easy way to get rid of the .gif wars is to just silo them in #random.
People generally only need a small nudge to change behavior like that.

------
KaiserPro
Sorry, but most of that is simply not true.

I worked for a large news company that moved from virtually nothing to slack.
There is now something like 800 channels.

Each channel has a purpose that is distinct from each other (for example
system-outage-44, or graphics-team, or aws-help)

Each team normally has a public and private channel, one to provide support,
the other brisk frank discourse. Seniors are expected to contribute(in fact
the members of the board are on there), and its the only way that remote
workers can get real time collaberation. In fact it allowed people to work at
home and feel included.

So to say its a waste of time sounds like either a marketing ploy, or an
organisational problem.

~~~
yellowapple
Having to sift through 800 channels to find the relevant topic sounds like a
nightmare.

~~~
unpythonic
Our company has a similar number of channels, if not more, and you don't scan
all of the channels for input. People typically subscribe to their team and
related team channels as well as any topics of interest. Slack makes it easy
to bring someone in just by mentioning them, so people get added to the places
they didn't know about as needed.

Once you start seeing that you're subscribed to too many channels, you just
leave them as they lose relevance to you. There's even a middle ground where
you can mute notifications from a channel, but can still watch what's going
on.

The main problem with slack is the poor search capability, and that's very
relevant to your comment.

~~~
yellowapple
I get that you can selectively subscribe to only certain channels. The problem
is that now you have 800+ channel names to read in order to determine the ones
to which you might want to subscribe. Sure, someone else could invite you to
some new topic-oriented channel if one remembers to actually do so. More often
than not, in my observation, that doesn't really happen in a timely manner (if
at all).

------
PakG1
They talk about threads and asynchronous flow as being key attributes that
make email better than Slack. I'm sorry, but those are both possible with
Slack. I've replied to old messages long after they were sent and they're
often in message threads. All the problems they claim Slack has, I think email
has them too. I'd rather have those problems in Slack than email. Actually,
I'd rather have them in Mattermost now these days. ;)

------
joselreyes
At work we started doing private project-specific channels for whatever
initiative we're working on that's cross functional. As soon as that project
is complete, we archive the channel and move on the next thing. It's worked
out really well surprisingly. Our public channels rarely get activity now
because their subject matter is so vague but the private channels are
incredibly active and productive.

~~~
jstandard
We also do this coupled with project specific Trello boards. Solved many of
the signal v noise issues we had.

------
mabynogy
Switch to IRC, you won't regret it. Two points concerning the post. IRC is
"senior-friendly" and you won't have that GIF problem as it's text-only.

~~~
spookthesunset
What planet are you living on where you can say with a straight face that IRC
is a senior-friendly thing to use?

Do people who advocate for IRC even understand what made Slack successful?
Seriously. Stay relevant or you are gonna get left in the dust when the world
moves on.

> GIF problem

GIFs are a feature, not a bug.

~~~
yellowapple
GIFs are a useless feature at best, and a distraction at worst.

Don't get me wrong, I love using them, but they ain't exactly a productivity
boost.

~~~
shlant
well lucky for you, Slack has a solution for that:

[https://twitter.com/slackhq/status/565314985405206529?lang=e...](https://twitter.com/slackhq/status/565314985405206529?lang=en)

------
bhouston
We tried Zulip but it is a lot more work to use than Slack/Flowdock. I really
like the Slack/Flowdock UI better. So we stopped using Zulip.

------
ryrobes
At the risk of sounding petty and nit-picky...

I hate it when companies start their marketing about how shitty their main
competitor is. Really? You couldn't muster an elegant elevator pitch without
throwing some shade first?

Granted this seems to be a 'alternative marketing' page ("Why Zulip?") that
calls out Slack directly... but, then again, so does the main page of the
site.

If you can't define what your product does without namedropping a popular
alternative first... C'mon man.

------
TokyoKid
> Remote workers can’t participate

Maybe not the correct headline at least, they mean folks in other time zones.
But a little sleep hacking fixes this, for me.

> Channels rapidly devolve into GIF posts

Sometimes I wish they would. I've found recent Slack orgs I'm in to be dead.
And you try start a topic and no one replies for hours or days, and I
sometimes delete posts out of embarrassment that I said something wrong or
just boring.

Last I looked at Zulip they were using the web-app in a "native" wrapper
approach to desktop clients. I wish them the best, but wish just _one_
enterprise chat competitor would take a different approach. I know the appeal
and I'm a JS developer myself, but even if you have to make a Mac-only
solution, there is a market for that cause nearly every small-to-medium office
seems to be all Mac.

