I’ve started working at a company that uses Zulip and it’s by far the best thought out UX I’ve ever worked with in a communications app. Sure there’s some polish needed but the general structure just lets me get to where I want, gives me an overview of everything going on, and generally makes me happy. I wish for more keyboard shortcuts maybe, and the mobile app needs the recent conversations view, but I’m sure they’ll get there.
At my work after we were bought we went from Teams to Zullip.
All of us hate it. It's a joke compared to Teams.
But if it works for you then I guess...
I wish Zulip (and other apps) provided an inbox instead of just ephemeral notifications that disappear once a message is viewed. Lack of inbox means that I have to use unread messages as a way to manage my inbox -- because the moment I click on a notification / take a quick peek at a message there's no easy way to mark it for coming back to later.
----
+100 for Zulip though; by far the sanest messaging experience for this kind of context.
I just had a look. I can absolutely understand parent. I’d want an option to include read messages in the inbox, not avoid marking as read. I want a history of stuff in my inbox, the same way discord, my RSS reader, and my email client work. All those have a read and unread state, but I can still see the read ones.
(And administrators can set it to be the default for new users in their organization, if the way your organization communicates is such that it's a better default than inbox).
Another feature you can use in Zulip for this workflow is starred messages; just star messages that are not done, and then you can browse the starred messages view when you've got some time to follow up on things.
I heavily use Discord for fan works stuff (I run some major annual fan works projects, like a big bang, charity fundraiser, zine, etc.).
That's how I know Discord has this feature! Top right corner has an @ and it's the "mentions", which is a list of every notification. I couldn't do all the managerial/administrative work on these projects without it.
> The killer feature is everything is a stream/thread. I argue that is a better UX over Slack, but it takes some getting used
I personally can't stand it. _However_ I just learned today that it can actually be disabled, which I would do if I was deploying a zulip instance for my team. We are all very wired towards the crackhead energy of just.. a chronological chat and a competent search.
we want topics allowed in certain channels only (ie #announcements) so that's probably what we'll use this feature for which certainly was not there when we tested maybe a year ago or so
True, though even before this we just made a chatting topic with the name "general", that worked just fine while still letting people make other threads for long discussions.
Replying to myself because I'm sure someone from Zulip will read this thread: I also wish for a tiered channel system. Instead of muting some, I'd like to promote some to high priority, so my inbox can toggle between the ones I really care about and a general overview.
Thanks for the feedback! I think feature closest to what you're requesting is followed topics (https://zulip.com/help/follow-a-topic), which you can filter to in the inbox. Perhaps we could add an option to auto-follow topics in a specific channel to other ways of auto-following topics.
was just chattin zulip in another thread. news to me that there is a setting for disabling topics which puts thing in a normal "chat room" style chronological order though it looks like it still retains some sort of topic visual heading which looks kind of noisy.
zulip is the most solid of the open self hosted solutions so far imo. last my team tried it sometime a year ago maybe we were super turned off at the threaded topics. my entire team hates them and anyone trying to post important stuff in topics gets ignored lol we can't help it our brains just don't want them in our lives.
but now seeing that there's a way to disable that, it's possibly time to revisit zulip
Topics are otherwise incredibly useful even with a small number of people, if you want to carry out parallel & wide-ranging conversations on different timescales. Implicitly designing for a single topic per channel forces chats to be ephemeral and makes it very hard to have long timescale discussions.
Eg. If I'm discussing buying a house or a career change (personal) or a new business strategy for my company (work) I don't want all conversations dumped into a single river. Slack's model of threads within a channel feels too schizophrenic; Zulip's model of multiple conversations arranged loosely by theme (and accessible from the sidebar) is much better.
Catch-all topics are good for the ephemeral stream of chatter.
Some might say that chat should be only for ephemeral stuff, but then that is basically avoiding the essential complexity (of long term conversations) which must live somewhere to enforce some Procrustean simplicity on the chat platform.
My frustration with the flow, is that you’re forcing me to make a decision at a point where I don’t really know if a thought/idea/comment I want to share will rise to the level of warranting the organizational overhead of making it a “topic” vs just a little toe in the main stream.
I haven’t used Zulip in a while, but can’t you reorganize messages/topics after posting? I remember that as being one of the biggest advantages over Slack for exactly this reason (the Slack equivalent is “I wish I’d known to reply in a thread, because oops, this topic took over the channel”).
> my entire team hates them and anyone trying to post important stuff in topics gets ignored lol we can't help it our brains just don't want them in our lives.
I have a theory for why some people love Slack and others love Zulip (Completers -vs- cultivators) which I shared in a sibling thread.
As nice as zulips aspirations may be, every time i have to use it for a community i effectively stop interacting with them after a short while just because everything is janky, ugly and feels like a drag to interact with, just tried opening it on my phone to see if it improved but the header ui is just plain broken.
Are you using iOS? Safari 26 has several changes that break the mobile web app layout, and it's proven quite difficult to fix. I'd suggest using the actual mobile app on iOS if you've upgraded to Safari 26.
(My understanding is we are far from the only web app broken by Safari 26, and we're working on it).
I don’t use native apps as general principle, while i happened to be on ios safari when i tried and i am the first to criticize that browser, the bugs i am seeing do not happen in other apps and should be easily fixable in a proper build webapp. Also keep in mind that this was just a coincidence, every other browser and platform i had to use zulip in had a bad experience.
For what it's worth, essentially every main view surface was visually redesigned over the course of the last 2 years. So while I can't promise you'll like the new design, it certainly isn't the same as it was 2 years ago.
One of the other nice features of the new design implementation is there are handy settings for font size and line spacing. It turns out that different people have very different desires for how dense content is in chat apps, and empirically there's a significant portion of users with just about every combination.
I've spent a bit of time last year trying to convey my product instincts to the Zulip team and mostly stopped because I felt like they didn't care enough / weren't moving very fast. The basic problem is that the mobile app is, like it or not, the way most people will use the product, and it needs to be designed by an opinionated person who actually will say no to things.
In my view, the home page should be just like a proper messaging app: show every recent thread ("topic" in Zulip nomenclature) that I'm involved in, across all my channels, with unread ones indicated using a 'dot'. Or, if you really want to be like Slack, just copy Slack more directly. In either case, the other views (Inbox, Combined Feed, DMs, etc) should be under menus, not primary actions.
The other thing is that it's often hard to figure out how to reply to a topic. In the Combined Feed, which is my preferred view for consuming updates, the UX for replying sucks -- first you have to figure out to tap the headers; and even then, you can accidentally tap into a channel instead of a topic. It's extremely non obvious when you've done this and constantly causes people to reply in the wrong topic.
I vibecoded some improved Inbox UX using Claude Code and I think it would be a big step up, but it's hard to know what the steps would be to get it shipped, since I don't have time to spin up properly on the codebase and I doubt my changes are acceptable as-is. If Zulip team wants them I'd happily share though.
there are just so many issues, where do i start? its just apparent no designer or usability person ever used it or was involved in anything for this project. there is a weird search button with uncentered icon, scrolling makes some tooltip flicker and partially scroll on top of the header, the content of the page reappears on the top of the header when scrolling past it. everything just feels like one giant glitch. and when you scroll, there is a focus outline around whatever item you happened to drag the scroll area with. This is what i encountered in 5 seconds testing just opening and scrolling up and down.
I have looked at the rust Zulip forums, which are bulky. But with moderation and rules and having people on the autistic spectrum [citation needed], it perhaps is usable for large organizations. Just kidding.
We are using Zulip for 300+ members in a makerspace, and at 40 members, we were not happy. Scaling to 300 never broke not being happy, since we all hate the UI ever since.
I cannot re-open Zulip threads, which are also issues with an atomic "solved/unresolved" state, unless I have elevated access. It is not a true forum like PHP forums, where we ask people to name threads, and you might just skip reading more than the title, or locate interesting threads by activity and find stickies about important announcements in a pull, not push, way of doing things.
It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
If they wanted to re-invent forums, they should have cloned the "discourse" web app/forum. Still looks like shit on every platform, mobile or desktop, but at least does not break down on mobile.
> It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
Do you mean people are happy to post on a thousand different threads, but no one reads posts from anyone else?
Why do you even have so many different active threads? Why not just let "resolved" threads be, and funnel conversations into fewer threads? (esp if you want ephemerality i.e. conversations to expire with time)
> 300+ members in a makerspace
If you have 300+ people discussing a wide variety of things, how do you ever expect to maintain your sanity with only channels and without threads? Won't every channel be quickly flooded and really hard to resurface anything useful from past discussions?
> I cannot [...] unless I have elevated access
Is your complaint that your Zulip space is not moderated well and that it would be helpful to ad-hoc decentralize some of the maintenance work across more participants?
It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
I really wanted to like Zulip and use it as a personal chat service for a small group and it was exactly that feature that made it basically unsuitable. Forcing everything into titled threads did not make any sense for lots of user to user interactions that are ad-hoc in nature.
I didn't think it was terrible software by any stretch of the imagination - just not really suitable for informal communication.
UI and user ergonomics continues to be Zulip's biggest blocker to wider adoption. I understand that to many people not having E2EE and truly independent self hosting (e.g. push notification issues) is a deal breaker, but for many organizations the current level of openness from its values is enough.
I really wish Zulip could find someone to re-design the interface around the channels/threads model to make it easier to use and more friendly to beginners. I am personally never bothered by the design and got used to its interface quite quickly, but I know many many people who got turned away by its design or uses it in a Slack/Discord way by posting everything into "general chat".
I am one of these people. I remember liking the concept a lot, but just couldn’t stand wading through the UI (or telling anyone else that I expect them to).
We've been using Zulip for our company chat for 2 years now. It does what we need it to do — while letting us control where it's deployed and where the data is stored (!!). But the UI is dated and awkward. The general feeling I get is that everyone at our company is okay with Zulip, but no one loves it. It just has that air of mediocrity about it. It's "okay".
> UI and user ergonomics continues to be Zulip's biggest blocker to wider adoption [...] many people who got turned away by its design or uses it in a Slack/Discord way by posting everything into "general chat"
Having thought about this a bit, I propose there is an underlying dichotomy between "completers" and "cultivators"
## Completers
Prioritize "velocity" and closing open loops. Limiting context means that they can act with focus. Close tabs often. Communication appends to the task queue; each conversation is an open ticket to be closed. Anything that scrolls off screen is implicitly marked as done. The ephemerality of the stream allows them to "process" a conversation and move on. Zulip might cause anxiety because threads/discussions linger without closure.
## Cultivators
Communication as externalized cognition. Messages are nuggets to be filed / incorporated into a larger schema. Wants a "dashboard" to maintain sense of control; fears something falling through the cracks more than they fear clutter. Don't care to "finish" a chat; want to keep the context organized and accessible for deep work / future decisions.
## Problems
Zulip defaults to assuming that all chat is valuable and taxes every interaction with a little bit of up front effort. Slack assumes most chat is of ephemeral value and doesn't see the point of taxing 90% of the interactions for the 10% that might be valuable. Slack forces cultivators to become completers and Zulip nudges completors to act as cultivators.
Completers preferring who prefers Slack/Discord/etc are implicitly adopting the the fragmentation of multi-system setup -- chat for ephemeral communication, and anything longer term must move to docs/wikis/Jira/whatever (which now begs for dozens of "integrations"). Understanding the state of anything now requires forensic archeology. (cue [Charlie Pepe Silvia meme]) Complicated acrobatics in channel names such as `#team-proj-blah` are attempts at combating the fundamental entropy of treating everything ephemeral.
The challenge is that, ultimately organizing is also real work and ignoring it in a short-sighted drive for efficiency hinders longer term effectiveness.
## Potential solutions?
1. The chat platform could offer two different views: a triage flavored mode for completers, and a dashboard flavored mode for cultivators. Even one person could toggle back-and-forth between the two as necessary.
2. Better UX for organizing incrementally, eg. UX improvements for manual clustering, and AI-assisted clustering / topic naming. Wouldn't it be great if people could continue chatting in the stream but the same message would simultaneously get filed under a topic? Technology might now enable such a product experience.
3. Slack needs to stop pretending that search is an effective replacement for organization (esp when search is crappy). I haven't used Slack in a while (preferring Zulip with catchall topics as a good balance) but I get the impression that Slack [Canvas](https://slack.com/intl/en-in/features/canvas) is an attempt to combat this problem.
You could literally drop this into Claude Code or Codex and point it at a local fork of Zulip and have it build your bimodal version with triage and grazing styles.
This is super interesting framing. I’m definitely a completer, not that I like much about Slack. Probably useful to have this kind of discussion before/while making knowledge management decisions in startups.
Zulip being fully open-source and self-hostable helps this. It's what the Bluesky team have been calling "credible exit", and Zulip has it way more than Bluesky does.
On the other hand, I would love to see more tech companies being co-operatives, where their members get a say in governance. That'd be the ultimate hard-mode for a business that was dedicated to being rugpull-resistant.
Being a cooperative seems (having never run one) harder than being a regular private company. It seems like it would constrain a business from being able to do what it would otherwise want to do. So I think of it as doing business "on hard mode". I think it's socially worth doing, and I aspire to be part of one someday. But I don't think it comes for free, especially in a market where you'll compete with businesses that aren't also playing on hard mode.
I see, I agree with it too. I think that's why many tech projects prefer a "private company owned by a non-profit foundation" structure such as Mozilla and Signal as the examples off the top of my head.
Absolutely love Zulip. I think they are the #1 open source project out there for many reasons. Here are a few that come to mind:
1. Open source and the commitment to keep it there.
2. The continued technical excellence of the product.
3. Excellent and up-to-date documentation
4. Open to the public development effort that allows public participation (chat.zulip.org)
5. Availability of help from front line engineers and owners as well as the community.
6. Modern and organized UI with many options to tailor it to use case and environment.
7. Excellent choice of tech stack which has evolved to keep up with new technology.
8. An excellent place for aspiring developers to learn not only coding but other skills such as communication and relationship values.
There are a lot of comments not liking zulip. I wonder if the like/dislike feeling is tied to the size of the user/company of the poster. My experience is the zulip works very well in my small 3 person fully remote business. Maybe the UI workflow of Zulip breaks down with larger numbers of users?
I used it in a 3 person company and I hated it for many of the reasons stated here. The topic based UX is terrible in practice and the whole thing feels janky and ugly.
I've run the Carolina Code Conference since 2023 and we've setup Zulip as a chat system for conference attendees to network every year. It's a really cool platform and I wish it had more widespread adoption.
i love zulip for so many things, and in particular the topic-first paradigm.
and as long as it doesn't offer voice messages i keep going back to signal (or similar). for small groups i often find voice messages to be easiest (totally not for big groups, i agree!).
Needs significant UI polish IMO. Anyone from the Zulip team care to chime in if there's appetite for this? I could take a look at contributing if so. Just the project getting to this level of maturity without significant polish sort of triggers the "maybe maintained by people who just don't value it that much" alarms?
I wish Zulip (and other apps) provided an inbox instead of just ephemeral notifications that disappear once a message is viewed. Lack of inbox means that I have to use unread messages as a way to manage my inbox -- because the moment I click on a notification / take a quick peek at a message there's no easy way to mark it for coming back to later.
----
+100 for Zulip though; by far the sanest messaging experience for this kind of context.
(And administrators can set it to be the default for new users in their organization, if the way your organization communicates is such that it's a better default than inbox).
That's how I know Discord has this feature! Top right corner has an @ and it's the "mentions", which is a list of every notification. I couldn't do all the managerial/administrative work on these projects without it.
The killer feature is everything is a stream/thread. I argue that is a better UX over Slack, but it takes some getting used it.
As mentioned, Slack is way more polished.
I personally can't stand it. _However_ I just learned today that it can actually be disabled, which I would do if I was deploying a zulip instance for my team. We are all very wired towards the crackhead energy of just.. a chronological chat and a competent search.
I have a theory for why some people love Slack and others love Zulip (Completers -vs- cultivators) which I shared in a sibling thread.
https://news.ycombinator.com/item?id=46960569
Curious to hear what you think.
zulip is the most solid of the open self hosted solutions so far imo. last my team tried it sometime a year ago maybe we were super turned off at the threaded topics. my entire team hates them and anyone trying to post important stuff in topics gets ignored lol we can't help it our brains just don't want them in our lives.
but now seeing that there's a way to disable that, it's possibly time to revisit zulip
Topics are necessary when you start having a huge Zulip server, 100+ people. There's so much noise --- dividing things by channel is too coarse.
I participate in several open source Zulip servers and it reminds me of a better IRC. It's a lot more ergonomic that Gitter or Discord.
Eg. If I'm discussing buying a house or a career change (personal) or a new business strategy for my company (work) I don't want all conversations dumped into a single river. Slack's model of threads within a channel feels too schizophrenic; Zulip's model of multiple conversations arranged loosely by theme (and accessible from the sidebar) is much better.
Catch-all topics are good for the ephemeral stream of chatter.
Some might say that chat should be only for ephemeral stuff, but then that is basically avoiding the essential complexity (of long term conversations) which must live somewhere to enforce some Procrustean simplicity on the chat platform.
I have a theory for why some people love Slack and others love Zulip (Completers -vs- cultivators) which I shared in a sibling thread.
https://news.ycombinator.com/item?id=46960569
Curious to hear what you think.
Fascinating! Can you explain why?
(My understanding is we are far from the only web app broken by Safari 26, and we're working on it).
One of the other nice features of the new design implementation is there are handy settings for font size and line spacing. It turns out that different people have very different desires for how dense content is in chat apps, and empirically there's a significant portion of users with just about every combination.
In my view, the home page should be just like a proper messaging app: show every recent thread ("topic" in Zulip nomenclature) that I'm involved in, across all my channels, with unread ones indicated using a 'dot'. Or, if you really want to be like Slack, just copy Slack more directly. In either case, the other views (Inbox, Combined Feed, DMs, etc) should be under menus, not primary actions.
The other thing is that it's often hard to figure out how to reply to a topic. In the Combined Feed, which is my preferred view for consuming updates, the UX for replying sucks -- first you have to figure out to tap the headers; and even then, you can accidentally tap into a channel instead of a topic. It's extremely non obvious when you've done this and constantly causes people to reply in the wrong topic.
I vibecoded some improved Inbox UX using Claude Code and I think it would be a big step up, but it's hard to know what the steps would be to get it shipped, since I don't have time to spin up properly on the codebase and I doubt my changes are acceptable as-is. If Zulip team wants them I'd happily share though.
We were able to reproduce the search icon centering issue in mobile web, which is being fixed here:
https://chat.zulip.org/#narrow/channel/9-issues/topic/center...
I have looked at the rust Zulip forums, which are bulky. But with moderation and rules and having people on the autistic spectrum [citation needed], it perhaps is usable for large organizations. Just kidding.
We are using Zulip for 300+ members in a makerspace, and at 40 members, we were not happy. Scaling to 300 never broke not being happy, since we all hate the UI ever since.
I cannot re-open Zulip threads, which are also issues with an atomic "solved/unresolved" state, unless I have elevated access. It is not a true forum like PHP forums, where we ask people to name threads, and you might just skip reading more than the title, or locate interesting threads by activity and find stickies about important announcements in a pull, not push, way of doing things.
It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
If they wanted to re-invent forums, they should have cloned the "discourse" web app/forum. Still looks like shit on every platform, mobile or desktop, but at least does not break down on mobile.
Do you mean people are happy to post on a thousand different threads, but no one reads posts from anyone else?
Why do you even have so many different active threads? Why not just let "resolved" threads be, and funnel conversations into fewer threads? (esp if you want ephemerality i.e. conversations to expire with time)
> 300+ members in a makerspace
If you have 300+ people discussing a wide variety of things, how do you ever expect to maintain your sanity with only channels and without threads? Won't every channel be quickly flooded and really hard to resurface anything useful from past discussions?
> I cannot [...] unless I have elevated access
Is your complaint that your Zulip space is not moderated well and that it would be helpful to ad-hoc decentralize some of the maintenance work across more participants?
I didn't think it was terrible software by any stretch of the imagination - just not really suitable for informal communication.
Zulip was founded in 2012, Discourse was released in 2014.
I really wish Zulip could find someone to re-design the interface around the channels/threads model to make it easier to use and more friendly to beginners. I am personally never bothered by the design and got used to its interface quite quickly, but I know many many people who got turned away by its design or uses it in a Slack/Discord way by posting everything into "general chat".
Having thought about this a bit, I propose there is an underlying dichotomy between "completers" and "cultivators"
## Completers
Prioritize "velocity" and closing open loops. Limiting context means that they can act with focus. Close tabs often. Communication appends to the task queue; each conversation is an open ticket to be closed. Anything that scrolls off screen is implicitly marked as done. The ephemerality of the stream allows them to "process" a conversation and move on. Zulip might cause anxiety because threads/discussions linger without closure.
## Cultivators
Communication as externalized cognition. Messages are nuggets to be filed / incorporated into a larger schema. Wants a "dashboard" to maintain sense of control; fears something falling through the cracks more than they fear clutter. Don't care to "finish" a chat; want to keep the context organized and accessible for deep work / future decisions.
## Problems
Zulip defaults to assuming that all chat is valuable and taxes every interaction with a little bit of up front effort. Slack assumes most chat is of ephemeral value and doesn't see the point of taxing 90% of the interactions for the 10% that might be valuable. Slack forces cultivators to become completers and Zulip nudges completors to act as cultivators.
Completers preferring who prefers Slack/Discord/etc are implicitly adopting the the fragmentation of multi-system setup -- chat for ephemeral communication, and anything longer term must move to docs/wikis/Jira/whatever (which now begs for dozens of "integrations"). Understanding the state of anything now requires forensic archeology. (cue [Charlie Pepe Silvia meme]) Complicated acrobatics in channel names such as `#team-proj-blah` are attempts at combating the fundamental entropy of treating everything ephemeral.
The challenge is that, ultimately organizing is also real work and ignoring it in a short-sighted drive for efficiency hinders longer term effectiveness.
## Potential solutions?
1. The chat platform could offer two different views: a triage flavored mode for completers, and a dashboard flavored mode for cultivators. Even one person could toggle back-and-forth between the two as necessary.
2. Better UX for organizing incrementally, eg. UX improvements for manual clustering, and AI-assisted clustering / topic naming. Wouldn't it be great if people could continue chatting in the stream but the same message would simultaneously get filed under a topic? Technology might now enable such a product experience.
3. Slack needs to stop pretending that search is an effective replacement for organization (esp when search is crappy). I haven't used Slack in a while (preferring Zulip with catchall topics as a good balance) but I get the impression that Slack [Canvas](https://slack.com/intl/en-in/features/canvas) is an attempt to combat this problem.
----
[Charlie Pepe Silvia meme] https://knowyourmeme.com/memes/pepe-silvia
I wish there was a way to hold companies accountable for stuff like that.
On the other hand, I would love to see more tech companies being co-operatives, where their members get a say in governance. That'd be the ultimate hard-mode for a business that was dedicated to being rugpull-resistant.
> That'd be the ultimate hard-mode for a business that was dedicated to being rugpull-resistant.
1. Open source and the commitment to keep it there. 2. The continued technical excellence of the product. 3. Excellent and up-to-date documentation 4. Open to the public development effort that allows public participation (chat.zulip.org) 5. Availability of help from front line engineers and owners as well as the community. 6. Modern and organized UI with many options to tailor it to use case and environment. 7. Excellent choice of tech stack which has evolved to keep up with new technology. 8. An excellent place for aspiring developers to learn not only coding but other skills such as communication and relationship values.
I really want to like it…
and as long as it doesn't offer voice messages i keep going back to signal (or similar). for small groups i often find voice messages to be easiest (totally not for big groups, i agree!).
(EDIT: unless your reason for using Discord is PTT voice channels. Then it's not.)