You have to applaud someone taking on the Slack and Discords of the world, but isn’t the problem with Slack the total lack of discipline of the users?
This is a repeated pattern over the years, whether management or tech but when you get huge gains simply by not doing something invariably some group of people will gravitate towards exactly that problem and cause a net increase in BS for everyone. This tends to lead to technically imposed measures to attempt to insulate you from colleagues that themselves end up overstepping the mark.
We considered it as a replacement to Slack to decided to stay on Slack. The reason is that we were unable to configure any meaningful network/firewall policy for it. The app reports all your actions to a bunch of 3rd parties, which we obviously want to cut, but as I remember the main problem was that their backend API is also non static and changes its IP all the time so that was a total mess to track and configure properly.
I am surprised that Zulip is not mentioned in this thread yet. For people frustrated by slack's defaults of encouraging interruption and lack of structure and lack of long-term retention of knowledge, Zulip fixes many of these issues. For people that just need any sync/async messaging tool, Zulip also happens to be open source and easy to self host.
Really? I am very suprised to hear that. It looks very polished to me, and the UX has been much less frustrating for me (as someone who was on many slack teams over the last 4 years). My sample size is small, but fairly consistent in that evaluation.
> defaults of encouraging interruption and lack of structure and lack of long-term retention of knowledge
I guess the emphasis is on "defaults" because interruptions can be minimized by seeing notification levels and muting. Lack of structure? There are channels and threads, I'm not sure what else I'd need from a product like that. Retention is fixed by paying for it.
In slack (or discord), due to its lack of structure, if someone explained some piece of institutional knowledge, that explanation gets lost in the "slackhole". Other tools are at least marginally better at preserving institutional knowledge
in this tool (and others I've seen, maybe zulip does this), you can mark threads as "done", and mark messages as canonical.
with slack, it's easy to have a thread with 15 different answers which are all slightly different.
The "knowledge retention" features I'm looking for is being able to mark a thread as "this is the decision made", have that highlighted in metadata and archival, maybe be able to link off to a notion page, and have the thread closed to finalize the decision.
EDIT: the number of times I've had to kick people off a thread because they're adding bad info during a crisis reallllly drives my desire for marking canonical messages lol
Ah, highlighting specific messages would be a neat feature to have in Slack! It aligns with their official acronym: Searchable Log of All Conversation and Knowledge.
Any org will often have multiple users asking the same questions over and over again on slack. Apart from a search bar there isn’t a good way to archive or pin important conversations for everyone to see
In slack indeed there is no good way. But other tools provide better ways to do it (with examples among sibling comments). I am not saying zulip solves much of this, there is probably a better tool, but they are at least not at rock bottom like irc/discord/slack.
This landing page would lure a lot of people over from Slack if it just said "We won't keep breaking your workflows by constantly moving stuff around for no reason, or removing stuff you rely on, or forcing things into new windows that used to be integrated, or replacing perfectly fine features with really crappy versions."
Pricing is almost identical to what Slack charges. I like the idea and I know that not having meeting support here is a feature but Slack huddles are convenient for quick syncs and we lean on them a lot. The alternative is adding another tool like Teams or Zoom which I do not want to do so not having that feature would make this a deal breaker.
One note on pricing is that is it actually $/user/month/team rather than $/user/month.
With free accounts we had organized our account into different teams per site we run like Office Snapshots, Education Snapshots, etc with some people on multiple teams.
When we upgraded a couple users after they were really enjoying Twist, the upgrade only applied to a single team and not across all teams for the upgraded users. It would have cost $30/month/user to have a user get the Unlimited features on each of the 5 teams they were in.
I’m still not sure if we organized our teams in a weird way, but I still feel like it the pricing wasn’t presented in a way that made this clear.
Behavior is enabled by what the tool enables. The tyranny of the default means that an organization not prepared to rigidly apply certain best practices will live and die based on those defaults.
This may not be universally bad, but for some environments, it’s quite bad.
Twist looks like it focuses on many of the Slack issues that bite bigger teams. It’s one thing for me to better manage my use of slack, create focused topic channels, snooze notifications, etc. But none of this matters when there are 100 other teams all using the product haphazardly.
Better defaults won’t magically fix this, but there is a lot of value in defaults that encourage better habits.
The focus on async communication also seems interesting. My biggest issue with Slack was that people expect immediate answers, and that it’s easy to lose track of things if you don’t stay on top of the pings as they come in.
Again, this expectation doesn’t magically disappear with a new tool, but a new tool that focuses on this, and the introduction of which can be used as a catalyst for encouraging behavior change seems valuable.
Better tools won’t solve the whole problem, but I’m glad they’re putting these ideas out into the market. If nothing else, I hope it leads to more interest in deep work, true async communications, and awareness of the toxic and attention-destroying nature of many Slack instances.
It might make sense if you work at a company, but it's also used very inappropriately, I think, in the context of scientific research. The problem we have is that we collaborate between company units on Slack and so all of us have dozens to hundreds of Slack instances with separate logins. I don't know how people tolerate it.
Discord has a much better approach. It seems that slack may not be able to match it for historical, bureaucratic, and technical reasons.
I've moved anything I can to matrix and encourage everyone to do the same. A collaboration only necessitates invites to a channel. It matches the way we work and it's more flexible.
I agree, this is my main critique of Slack. Discord's approach to servers as only requiring one login for many makes way more sense. Compared with Slack's multiple logins for many, way more confusing.
I hate it as well, but here's my best guess as to why change it is unlikely: Most of their revenue probably comes from companies, which virtually always issue company emails for their employees. In that case, you'd still have the problem of multiple logins (admittedly fewer, though).
If you've ever used Discord with multiple logins, it's actually not seamless at all. You essentially switch accounts and are only able to see the chats associated with one account at a time.
Thus, not only would it probably be a non-trivial technical challenge, but they would also need to put in additional UI and UX work to make the experience better than what Discord offers. And all that effort probably isn't worth it when their money comes from customers who won't benefit from it.
Ultimately, I think if you want to run a chat but aren't providing the members with emails, you probably shouldn't use be using Slack.
I don't know about Discord that was given as an example earlier for a single login, but most tools allow you to have multiple emails with a single account (eg. think Github which most of the same companies use).
There is nothing stopping Slack from doing the same while still getting money from companies needing their service.
Why are those separate Slack instances? I've worked in environments with hundreds (<1k) users on the same Slack / Hipchat / whatever app, separated by channels, not instances. Are you talking about thousands of users, or are there some other constraints?
At the last company I worked at, Slack usage started as “shadow IT”. A team would need a better collaboration tool, but central IT was just a barrier. So the department head would agree to pay for it.
Over time, a few dozen or so Slack instances popped up.
These were eventually corralled by central IT and merged into a single enterprise instance, but this just magnified the messiness - overlap between channels/workspaces, vastly different usage habits by department, etc.
Most of this happened pre-Pandemic, at a time when collaboration tools were 2nd class citizens, and nobody cared too much about the sprawl.
I'm just answering the question about why there were multiple instances. I don't think starting with a single instance is magic either. I do think starting from many and then converging accelerates the mess a bit.
I didn't say this was the fault of Slack. I was answering the question about why multiple instances might exist.
On the subject of Teams, if you want to see something worse than dozens of Slack instances merged into one, it's what happens when those are subsequently migrated to Microsoft Teams, with one team created per Slack channel. Not recommended.
Also not Microsoft's fault. The effectiveness of these tools depends highly on the implementation.
We have slack and teams. Teams is awful, it’s silo based, separate discussions in tiny areas.
Slack means silo walls break down, channels are formed and disintegrate by people with stuff to contribute in an agile way, rather than a team structure which takes years to change.
I’ve always found it fast enough for what it needs to do. It’s not a game engine or trading platform so I’m not sure aggressive optimisation would add as much value for the average user, compared with e.g. development effort spent on things like better search or channel organisation, for example.
I'm not talking about "game engine speed". It's a chat program for orgs, so the absolute baseline is switching chats and loading messages and media fast - or at least not sluggishly slow.
Instead, slack keeps growing features that my org never uses.
Not realtime is fine. Waiting a minute or so for it after resuming from sleep to sync the state (where at some point it will show you new message notifications but prevent from switching to those channels) is not fine.
Slack seems to work around keeping people looking without context
A well designed and well run slack requires a thoughtful setup and we’ll trained users which itself can become a barrier to participating.
In the free slack world, far too much information is lost after 90days and those slack communities stagnant and die. Slack could offer tools free for non profits and join the other software tools who help support open source projects.
I have notifications on a couple of critics channels where time critical incidents are logged, they fire every month or two and that’s where I want to stop what I’m doing and look at those.
With teams however I can’t seem to find a way of muting corporate spam channels, so I have to keep the program closed when deep working.
I prefer teams to zoom now I’m afraid, the persistence of meeting chat windows for example, but for textual collaboration slack is orders of magnitude better. Maybe because we have managed to get our entire organisation at least federated and most channels are global or in large enough departments that you only need to be in one or at most two.
A few friends and I are doing some side consulting and decided to use a Google Space within our public Gmail accounts. It has worked great and I haven't missed a thing, especially with the Gmail app on the phone, but I can mute pretty easily if I want to.
It looks like you get only one month history as opposed to 3 months for Slack, and shortening the history was the reason for the recent uproar. So the creators of Twist mist be very confident regarding other features.
The only other Slack alternative I found was actually better than Slack and not just a "sidegrade with different pricing and less integrations" was Flowdock - unfortunatley, now defunct.
It was all down to how Flowdock implemented threads. They did it better and long before Slack ever did; Slack's threads frankly kinda suck.
I've heard Zulip threads work really well but I've never had the chance to use it with a team that was willing to try something else.
I’m not the biggest Slack fan … but does anyone else think Slack is massively underpriced? For most companies I know it’s the central communication hub and often the integration point for dozens of other tools. Yet it’s one of the cheapest per-seat SaaS apps I use.
I feel like Salesforce will wake up one day and triple the price and 95% of customers will just say OK.
Yeah I can turn off notifications in slack too. What are the defaults? If they’re all on by default it sets the expectation of online availability 24/7.
As they say, it's not the tool, it's how the tool is used.
After reading this, I cannot understand how this is better or even different from Slack. If people are disorganized, allow themselves to be distracted, distract others, store information in the wrong place - all of that remains unsolved by Twist, as far as I can tell.
As our company uses Zoho, we use Cliq. For a while we had 2 chat apps - engineers using Slack, rest of the company using Cliq. I reluctantly agreed to give up Slack. It's not bad, and even have a few unique features (remote work status, dev environment for extending it with Javascript, etc)
Using a few recipes to avoid having to break backwards compatibility every so often is pretty easy, as long as you know what they are (eg. you may need to live with your "referer" typo for a long time), and enforce them through coding standards and reviews and automated tests.
There's a company-public thread that 2 people participated in and nobody else has read it. Both have left the company. A new hire wants to read that thread. Where do you get the encryption keys from?
Because that's the front-page-advertised feature of this system. If you're happy to lose the context of older decisions, you can use a more private / e2e system.
What happens when a company has to undergo discovery in a civil case or needs to investigate am employee for sexual harassment or leaking trade secrets? E2e encryption is not a desired feature in the corporate setting at all.
The only problem with IRC and many of the open protocols (XMPP too) is that there is no "one true IRC": so while you can get all the same features as Slack, you've got to choose a particular server, a particular set of extensions (I am sure ChanServ/NickServ stuff eventually got "standardised" like DCC stuff did, but remember that DCC file sharing was direct-IP comms between clients), and on a specific client with the same set of features.
Slack and other tools are obviously inspired by IRC, but they do resolve a bunch of issues that IRC never got properly solved (or maybe did, but deploying it was too complex or it came too late).
This is a repeated pattern over the years, whether management or tech but when you get huge gains simply by not doing something invariably some group of people will gravitate towards exactly that problem and cause a net increase in BS for everyone. This tends to lead to technically imposed measures to attempt to insulate you from colleagues that themselves end up overstepping the mark.
Great to see serif fonts making a comeback too.