Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack channels are a waste of time

zulipchat.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Slack channels are a waste of time

#41

Post by KaiserPro »

yellowapple wrote: post #27
KaiserPro wrote: post #24

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…

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

You don't, because slack is ephemeral.

You join/are joined to a channel because its relevant to what or who you are working _now_. If you want help, then you go to #department or #thing those are the default public channels.

For example I was in a "SRE/devop/sysadmin" role, and I would be embedded in a production/feature team. So I would be part of sre-private and sre. I would also be part of #widget #widget-private and any sub feature teams.

This means that noise is neatly compartmentalised. I don't have to sift because its already in a labelled bucket.

Re: Slack channels are a waste of time

#42

Post by 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.

Re: Slack channels are a waste of time

#43

Post by mabynogy »

spookthesunset wrote: post #22
mabynogy wrote: post #19

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.

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.

You're aggressive and vehement.

It's not me. The post uses those terms. It seems you didn't read the post.

I'm not part of your "world". Some people complain about Slack. I say IRC is better.

Re: Slack channels are a waste of time

#44

Post by bachmeier »

evrydayhustling wrote: post #13

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.

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

Re: Slack channels are a waste of time

#45

Post by Bailin »

whoisjuan wrote: post #7

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…

| If this were an information architecture problem, it would have been solved already by Slack itself.

That is a strange/dangerous position to take. You seem to be saying that this one company's current implementation of mostly text chat is the best possible way to communicate.

| If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it

I also disagree slightly here. Users don't need to consume all information that they have access to. It's okay to dismiss notifications without reading their content, if you can determine it's noise for you. But the problem with channels/room-focused chat services is that they tend to have a few fixed number of channels, and users have to scan/read through content to determine if there's any signal in there.

To me, that seems to be the core differentiator of Zulip. For example if I've been gone for a few hours or few days, I can quickly see that I can dismiss conversations in streams like Dev/lunch-ideas, but I might choose to read up on Dev/prod-outages. In most/current chat services, all that conversation would be mixed up in the same room/chat history.

EDIT: Another way to think about it is that people have conversations, but most chat services only gives you rooms. People generally only care about some of the conversations that takes place in some of the rooms, so low signal to noise ratio. Most chat services leaves it to the user to deal with that, eg make a new room per new conversation. Zulip offers another, perhaps more user-friendly way.

Re: Slack channels are a waste of time

#46

Post by price »

bachmeier wrote: post #44
evrydayhustling wrote: post #13

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.

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

(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 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/

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.

Re: Slack channels are a waste of time

#47

Post by bachmeier »

price wrote: post #46
bachmeier wrote: post #44

Earlier quoted context omitted.

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

(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…

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

Re: Slack channels are a waste of time

#48

Post by evrydayhustling »

bachmeier wrote: post #47
price wrote: post #46

Earlier quoted context omitted.

(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…

> 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 mo…

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.

Re: Slack channels are a waste of time

#49

Post by hluska »

derefr wrote: post #35
hluska wrote: post #23

Earlier quoted context omitted.

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…

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…

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.

Re: Slack channels are a waste of time

#50

Post by anotheryou »

whoisjuan wrote: post #7

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…

They simply force threads with a short topic and provide a subchannel-like view for them.

Threads in Slack are hard to enforce (please don't write 20 "get well soon" replies in the main channel). They are hard to parse (you have to scroll past all the threads, including the "get well soon" chain). And impossible to mute without leaving a whole channel behind.

I can imagine this approach to help (but we use slack at work...)

Post reply on HN