Slack and all its clones are based on the chat room model, which structurally has the problem described in this article (and many others for productivity, such as wasting attention). Fundamentally, the chatroom model pioneered by IRC is poor for asynchronous communication because you can't sustain temporally overlapping conversations in a channel.
However, you can't "just use email" -- Email's threading model is great for asynchronous work, but it is poor for synchronous communication and also doesn't support modern features that make it easier to communicate ideas efficiently (shared history, markdown formatting, image previews, emoji reactions, etc.). It's essential to be able to have (semi)synchronous written conversations with people you're working with, especially if you don't want to spend your days burning out on video calls.
This is why we created Zulip -- it's designed as a real-time communication tool with email's threading model and all the nice features of modern chat apps that email lacks. And the reading user experience is actually a lot better than email, because Zulip provides is designed with the goal of saving time when prioritizing, skimming, reading, and replying to conversations. It's also 100% open source software (not open core!).
I get that you're just trying to get your software out there, but your modern features that email doesn't support are just wrong.
>shared history
Not if you have a mailing list, and then going off the record is as easy as removing the mailing list from the CC field.
>markdown formatting
This is an implementation failure, not really a fundamental problem with email. There is no reason that email clients don't support markdown, except that nobody has ever wanted it. There was someone who made a utility to switch markdown to regular MIME email, but just as a proof of concept. It works.
>Image previews
I assume what you mean by this is an inline thumbnail that expands when you click on it? Again, there's nothing about email that prevents it, it's just the way email clients are. That could be fixed
>emoji reactions
Okay, that's fair, there's no way to do this in email, short of sending a single emoji back. On the other hand, I think everyone would agree that this is more of a nice to have feature, than a necessary one, and one that really only makes sense in the world of quick, back and forth chat programs.
This. I mean I get that there are various different chat or chat/email hybrid solutions nowadays that are competing with each other.
Personally though I have nothing to complain about with slack. It has threading. It only has one level threading but that might actually be a good thing because we slack with non tech people too. One thread is sometimes hard for them to grasp. Make that a regular threading model and they will utterly get lost. You can see how that completely breaks down with emails in most places.
We use slack both for synchronous and asynchronous communication. It's all about the culture and what people expect. Not really different from email. Remember the people that send you another email if you didn't answer their first one after 5 minutes?
Group chats you can just link to in a ticket instead of having to paste and reformat from a large email conversation? Priceless!
Markdown is not necessarily required. Most good email clients supported something like it, like actually displaying something like _this_ as italics or * bolded *. It's like saying "but your app doesn't do XML". Yeah well but it does JSON.
> It only has one level threading but that might actually be a good thing because we slack with non tech people too. One thread is sometimes hard for them to grasp. Make that a regular threading model and they will utterly get lost
Off topic, but this astounds me.
Not trying to be elitist (I'm genuinely curious), but what is it about threads that throws them off?
They seem unrelated to software. I would have thought "non-tech" people would also understand them.
Just because they're unrelated to software does not mean that everyone will understand. I can't really tell you what makes them hard for people, I can only guess.
One guess is that there's the mental effort in keeping track of these threads (even when they're literally right in front of you in the interface.
Maybe it's the fact that they're just so used to the whole email chain with 15 levels of quoting old emails that is so common in many companies. Many many people are mentally immobile and unprepared to switch to anything else, once they're used to something. Lifelong learning is not something that is common in every job, like it is in software development.
Again you can't really ask me because I find threading totally awesome.
We've been using self-hosted Zulip for about 18 months now, and it's exactly what our company needs.
I have been recommending it right and left to people who don't need federation in their chat system. If there was a clear gateway to federation -- enabling a Matrix room as a Zulip Stream, for instance -- I would enthusiastically recommend it for everyone.
Zulip really hits the sweet spot for a communication tool. Especially with large amounts of users communicating across many different threads. The FHIR community "chatroom"[0] is a Zulip server and is indispensable for communication and knowledge building across thousands of users.
I signed up for that to see what Zulip is like, but there are only 19 messages visible if you do that, so I shouldn't have bothered. It seems nice, I guess.
From looking at the tour slides, a list of threads in the current chatroom (which Zulip calls "topics") does seem nice. I have often wished I could get Slack's all-new-thread-messages view filtered by channel.
However, you can't "just use email" -- Email's threading model is great for asynchronous work, but it is poor for synchronous communication and also doesn't support modern features that make it easier to communicate ideas efficiently (shared history, markdown formatting, image previews, emoji reactions, etc.). It's essential to be able to have (semi)synchronous written conversations with people you're working with, especially if you don't want to spend your days burning out on video calls.
This is why we created Zulip -- it's designed as a real-time communication tool with email's threading model and all the nice features of modern chat apps that email lacks. And the reading user experience is actually a lot better than email, because Zulip provides is designed with the goal of saving time when prioritizing, skimming, reading, and replying to conversations. It's also 100% open source software (not open core!).