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.
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://news.ycombinator.com/item?id=17622987 (on the HN frontpage right now)
As these channels get bigger, they inevitably split into sub channels (#myteam becomes #myteam-status, #myteam-oncall, #myteam-eng, ...). But this is clunky and can lead to a lot of confusion as to what chats should go where. Furthermore information retrieval can be cumbersome as I’ve found myself flipping through 5 chats and searching them all for a conversation.
I don’t have any experience with zulip, but it’s strategy of partitioning conversations largely aligns with how I think when I look for things on Slack: First I recall who I was talking to (channel), then I drill down and look for the thread I’m thinking of.
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.
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.
If you have one of those voice-driven personal assistant gadgets (Echo, Google Home, etc.), try putting it between you and some other sound source (say, a TV) and give it a command. It'll probably hear you correctly, since it knows to listen in a particular direction and can differentiate between you and the TV. Now put yourself between the Echo and the TV and give the exact same command. The Echo probably won't even hear you, and if by some miracle it does, it'll get overwhelmed by all the noise coming at it. Same amount of data, but how that data is arranged matters significantly.
Same thing here. You're the Echo, the information you want is the user, and the information you don't want is the TV. Slack puts the user between the Echo and the TV, while Zulip claims to put the Echo between the user and the TV.
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...)
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.
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.
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.
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.
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.
> 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/
> 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.
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.
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.
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.
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.
I would love to get notifications for "DMs on this Slack from the following people" (who only Slack me to joke around or with nonurgent questions I don't need to know about in the supermarket or the gym) or "@all messages in these channels except from these users" (who I don't directly work with at all but sometimes post "@all who wants lunch from the sushi place").
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.
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.
however, i think that's their entire point. it's actually not very useful for actual topical discussions
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.
Maybe Zulip already does that. Haven't tried it yet.
Nope. But you sure as hell search it.... comes in handy to see if something has been discussed before.
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.
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.
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.
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.
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.
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.
Don't get me wrong, I love using them, but they ain't exactly a productivity boost.
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.
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.
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.