[HN Gopher] Zulip 4.0: Threaded open source team chat
___________________________________________________________________
Zulip 4.0: Threaded open source team chat
Author : karlicoss
Score : 575 points
Date : 2021-05-14 00:11 UTC (22 hours ago)
(HTM) web link (blog.zulip.com)
(TXT) w3m dump (blog.zulip.com)
| alex-a-soto wrote:
| Previously at EI2030, we were using Discord, and it wasn't easy
| to find and keep track of information as we were growing. We've
| transitioned to Zulip and couldn't be happier.
|
| The article from monadical describes it best: "...[Zulip] creates
| an organized repository of knowledge as a side effect"
|
| Thank you to the Zulip team!
|
| https://monadical.com/posts/how-to-make-remote-work-part-two...
|
| https://ei2030.zulipchat.com/
| alberth wrote:
| I really love Discord light theme
|
| https://miro.medium.com/max/7168/1*iwfLW4rnn6U-mlUQpmBAfg.pn...
|
| If Zulip had a similar theme, I really believe they'd covert way
| more non-tech individuals.
|
| Longer post on discord light theme
| https://blog.discord.com/light-theme-redeemed-c541b7ab13e9
| eis wrote:
| We gave Zulip (and Mattermost, Element/Matrix, Rocket Chat etc) a
| try when our company was looking for self hosted alternatives to
| Slack. Zulip seemed like technically the most polished product.
| Smooth and easy get-running experience (Element was the polar
| opposite). Lightweight UI that doesn't feel buggy. I'd have liked
| to see a bit bigger font but what ended up being the showstopper
| was that new users were very confused about how to write in a
| channel (or stream how they call it). Everything needs to be in a
| second level "topic". In pretty much every other chat app one can
| just select a channel on the left and get a text input field
| where you can write your message. In Zulip though you don't get
| the text input. You have to either create a completely new topic
| which new users really don't understand or click on any of the
| past messages in the stream to create a reply to that topic (but
| not that specific message). I suppose it works well after you
| understand the messaging model but it represents such a high
| initial point of friction that we had to give up on it. Non-
| technical users had a really hard time and the switch from Slack
| was not high enough on the priority list to push through with it.
|
| tabbot: if you happen to see this, please please consider some
| kind of easy-mode which: - by default always
| shows the text input no matter if you clicked on a stream or
| topic - doesn't put the cursor in the "topic" input but the
| actual message input - allows sending a message by pressing
| enter - scrolls the window down when sending a message
| - scrolls the window all the way down when clicking on a stream
| - has a slightly bigger font size - maybe also some
| simplification of the UI. You don't need the name of the stream
| above every message (see https://i.imgur.com/oeBY5yk.png )
|
| I'm convinced with a bit of work to make it easier for new users
| you'll have a big boost in growth.
| jdiez17 wrote:
| I had a similar experience with Zulip when I tried to set up a
| chat tool for our research group. I liked the ideas of topics
| and such, but other people weren't so enthusiastic to learn
| about a whole new chat paradigm. In the end we switched to
| Mattermost and we are quite happy with it.
| mekster wrote:
| Mattermost doesn't seem to be improving at all for years.
|
| I just don't get how it's difficult to reply or quote
| someone's message when it's such a basic chat feature.
|
| Instead they invent weird code like "shrug" thinking it's
| funny during business chat.
|
| Also I often get logged out of mobile app and notifications
| stop reaching which makes it very unreliable as a business
| tool.
|
| They need to fix where it matters.
| it33 wrote:
| Mattermost CEO here, highly appreciate the feedback,
|
| On logging out of mobile apps, often that's from an IT
| security policy to have sessions last only a fixed number
| of days from the last login.
|
| We added a feature to automatically extend the session
| length based on the last login of a user--so inactive users
| get their sessions expired for security, and active users
| don't.
|
| If you're a long time user of Mattermost you might need
| your IT admin to switch on the setting:
| https://mattermost.com/blog/session-expiry-experience/
|
| It was set to be on by default in Mattermost v5.24.
|
| Regarding replying, we've been working with our community
| on adding different options for threading:
| https://mattermost.com/blog/dev-sneak-peek-collapsed-
| reply-t...
|
| From the blog post you can join the discussion on the topic
| if you like as well. We're very open to your feedback,
| eis wrote:
| That is also the impression we got when we tried
| Mattermost. It came as a big surprise because we are using
| a selfhosted Gitlab instance and Mattermost is supposed to
| have great integration with Gitlab but it really didn't
| work well. Maybe it is due to us having set up Gitlab
| within Docker, I don't know. In the end we got it working
| but it still didn't recognize a user from Gitlab. It really
| felt like they had some good start and ideas but then
| something changed and came to a halt.
| it33 wrote:
| Mattermost CEO here, thanks for the mention and the
| feedback!
|
| Just curious, have you enabled the GitLab-Mattermost
| plugin? https://github.com/mattermost/mattermost-plugin-
| gitlab#confi...
|
| If it wasn't easy to find, that's on us, and we need to
| do a better job in making things more discoverable.
| it33 wrote:
| Mattermost CEO here, thanks @jdiez17! Very glad to hear!
| fragileone wrote:
| All it really needs is default topics for each stream when you
| click on the stream. Like Discord's #general
| tabbott wrote:
| Thanks for the feedback! It's much appreciated.
|
| We are actively working on several ideas in this space. (One of
| the most important that was released in 4.0 is the redesign of
| the Reply button to make starting a reply feel like it does in
| other chat tools).
|
| I expect we'll be able to get into a really nice place with a
| combination of new settings with some mixture of "Easy mode"
| defaults, design changes, and onboarding adjustments. (We will
| do this while carefully preserving model/paradigm, in case
| anyone's worried). Feel free to stop by chat.zulip.org if you
| want to discuss specifics.
|
| FWIW, we regularly hear from large organizations, including
| some with thousands of nontechnical users, about their having
| great luck migrating to Zulip. Usually they tell us they did a
| 30-minute training and then things went smoothly from there, or
| they didn't and it took a couple weeks for some users to get
| the hang of it.
|
| In the scheme of things, doing a training is a pretty minimal
| investment to be able to use a better product for hundreds of
| hours a year. But of course Zulip would grow a lot faster if
| nobody worried whether their nontechnical users will thrive on
| it, so this area is a priority for us.
| cloogshicer wrote:
| The fact that Zulip is threaded (and this threading is
| enforced) is what makes it so valuable, at least to me.
|
| Your proposals would get rid of its main feature and go
| completely against one of its core ideas.
| eis wrote:
| I kinda agree. Actually what I wanted to say is I see where
| you are coming from but I disagree that my proposal would get
| rid of its main feature. I just want some way to have easy
| defaults for new users. I wouldn't propose to remove any
| features. You should still be able to do whatever is possible
| right now and for the advanced users nothing would change. I
| suggested an additional easy mode to help new users. This
| could be set as default by the organization admin or just
| make it opt-in. Nobody should be forced of course. I am
| confident that it would be still possible to push users into
| using threads/topics but without the considerable friction
| that currently exists. The fact that Zulip has to include
| these little tutorial bubbles for new users to show them how
| to write a message and other chat apps don't need it shows
| that Zulip is more complicated to understand and use as a
| newbie.
| cloogshicer wrote:
| Right, I can see that, thanks for clarifying.
| rkangel wrote:
| I don't think the paradigm needs to change, I think the UI does
| (although I'm admittedly not clear what should be different).
|
| To me the proof that the paradigm is good and it's a 'just' a
| UI problem is MS Teams. Teams has basically the same thread
| system - every message in a Teams channel is in a
| 'conversation'. When a whole org adopts Teams sometimes it
| takes some people a little time to learn not to create a
| conversation for every reply (my partner's company is non-
| technical and had this for a couple of people) but once you're
| going the system is clear to a new joiner. At my company (an
| engineering org) the thread system is universally used, works
| extremely well, and I've never encountered anyone who wasn't
| clear how it worked.
|
| The big difference is that in Teams you don't have to name your
| 'conversation'. You can optionally give it a title if you want,
| but it's not necessary and that "what do I call it" step was
| always a bit of a mental speedbump in Zulip for my team.
| eis wrote:
| Yes I agree that is pretty much purely UI issues. I don't
| want the paradigm to change. I guess I could have made that a
| bit more clear in my initial post.
| benhurmarcel wrote:
| On a similar note, my company switched to Google Chat which has
| threaded rooms (not commenting on the implementation here). A
| lot of new users, probably a majority even, always post
| messages in the latest thread, instead of creating a new one.
| They just find the only text field there is and type there.
| ChrisRR wrote:
| It's nice to see a quick description of what the project is in
| the title
|
| There's too many projects (even on the front page right now
| "Scala 3.0.0") for which I have no idea what they are, and I
| completely skim over.
| dathinab wrote:
| I have some experience with Zulip through the rust zulip server
| and I have to say as far as I can tell Zulip is the best choice
| for this kind of communities.
|
| The threading model might not be the best choice for all use-
| cases, but for a open-source project related community its superb
| (IMHO).
| ipsum2 wrote:
| Sort of off topic, but does anyone know why Dropbox acquired
| Zulip and preceded to do nothing with it?
| uyt wrote:
| It seems to be an acquihire and they didn't care for the
| product. This happens fairly often in general.
|
| Glad they at least got to opensource it instead of just killing
| it.
| bredren wrote:
| I can't speak to decision making, but I can add one viewpoint.
|
| My understanding is that Zulip was called Chime internally.
|
| Management pushed teams to use the tool, and it was tried but
| the interface was not polished.
|
| Slack was already out and despite how it is seen today, slack
| far more appealing.
|
| Slack's interface, single sign-on and mobile app availability
| made it hard for Chime to compete.
| tabbott wrote:
| > My understanding is that Zulip was called Chime internally.
|
| I don't think this is accurate. At least, I'm aware of a chat
| project called Chime at Dropbox circa 2015 that was not based
| on Zulip and at least at the time did not materially involve
| anyone from the original Zulip team.
|
| (I suppose some of those things could have changed since I
| last heard anything on the topic).
| bredren wrote:
| Okay, I was not there, so if you know you know.
|
| It seems additionally strange that after buying Zulip in
| March 2014 a wholly separate chat application would be in
| use. But stranger things happen.
| JaggerJo wrote:
| We recently switched to it for work. The electron app is okay -
| but a real mac app would be nice..
| bdcravens wrote:
| Is there a chat app that is native anymore? I know Hipchat was
| back in the day, but the 2 I've used in recent years (Slack and
| Cliq) are both Electron as well. (As is Mattermost, but I
| haven't used it)
| pritambaral wrote:
| As someone who always has a terminal open, I consider Zulip
| Terminal[1] a native app.
|
| 1: https://github.com/zulip/zulip-terminal
| usr1106 wrote:
| Why would you need an app on the desktop? Honest question. I
| have used zulip in the browser for 3 years and I don't know
| what I would be missing.
| JaggerJo wrote:
| Good question indeed, I'd say it comes down to: - apps fit my
| workflow better - even if its just a different icon in the
| dock.
|
| - having an actual non web tech based app would be great
| because web apps always behave slightly different than real
| native apps..
|
| (It's really hundreds of small things that are just weird -
| always feels like you use a app in a portal..)
| hahamrfunnyguy wrote:
| I took a quick look at the website, but couldn't answer my
| question quickly. Is Zulip suitable for integrating into an
| existing application where everything happens within the app?
|
| I am working on an application that needs chat and user-to-user
| messaging and it needs to happen in the app. Options like Slack,
| Discord, Mattermost aren't suitable.
|
| This really isn't something I want to write from scratch. .NET
| Core based App FWIW.
| jasonblais wrote:
| Mattermost PM here, thanks for the mention and the feedback!
|
| We have seen some users integrate Mattermost into an existing
| application. I'm not sure if these resources may be helpful? -
| docs.mattermost.com/integrations/embedding.html -
| https://forum.mattermost.org/t/recipe-embedding-mattermost-i...
|
| If you have any questions or feedback, would love to hear as
| well.
| encryptluks2 wrote:
| Hope to see more open source projects migrate to something like
| this. It is crazy the amount of fundamental open source projects
| I see investing heavily in Slack and other paid services.
| mdaniel wrote:
| Or, worse (IMHO) when they tie themselves to Slack but _don 't_
| pay for it, thus having messages thrown into the trash
|
| I hold out high hopes that eventually Zulip will gain enough
| mental marketshare that folks will switch, since Zulip offers
| free hosting for open source projects, unlike ~~Slack~~
| Salesforce with their bazilliontrillion dollars that they can't
| afford to spend to "sponsor" workspaces
| telesilla wrote:
| A project I work on uses free slack and once a month exports
| the chat and saves them on github, ensuring the conversations
| are maintained in case we need to go back and review any
| critical decisions.
| sgt wrote:
| We do this and see it as a benefit. If something is important
| enough not to take out of a chat, is it really that
| important? I have been hesitating paying for Slack because I
| feel the usage patterns of Slack will change if we do. I
| think power users of Slack tend to use email less, and that's
| precisely what I don't want. I want to continue using e-mail
| for more important things and keep chat as a non critical
| service.
| corytheboyd wrote:
| Wow I didn't even know this project existed, and you're telling
| me it's FOSS?!
| dsr_ wrote:
| And they tag issues with labels like "good first project". It's
| very welcoming.
| karlicoss wrote:
| Apart from the threading model, I love Zulip for its openness.
| It's quite sad Slack and Discord are often the first choice for
| open communities. They are siloed and unless you are deliberately
| searching in a specific workspace, you'll never run into the
| information in a search engine.
|
| In comparison, Zulip:
|
| - provides HTML export functionality
| https://github.com/zulip/zulip-archive#zulip-html-archive
| (example https://leanprover-community.github.io/archive )
|
| - URLs are nice and encode meaning (e.g.
| https://memex.zulipchat.com/#narrow/stream/279601-hpi/topic/...)
| ... compare with Slack/Discord meaningless character sequences
|
| - I'm excited about https://github.com/zulip/zulip/issues/4817 ,
| which would allow viewing workspaces in 'guest' mode, without
| registering at all
| StavrosK wrote:
| Zulip is amazing. I'm of the opinion that Slack is actively bad
| for work, because it encourages ephemeral, disjointed chats
| that you can't easily find again later.
|
| Zulip is fast, light, and is a much more natural way to chat.
| The "river" of messages that you can zoom in and out of is just
| fantastic.
| sgt wrote:
| Start treating it as async as possible, and the situation
| will improve. If team members get the impression you will
| always respond immediately, it will lead to a lot of wasted
| time and lack of concentration.
| StavrosK wrote:
| The thing is Slack's UX is geared against that. We can
| treat it as async, but the moment someone sends a second
| message about the same topic to the room, you're done, the
| conversation starts diverging.
|
| It's also dog-slow, I have to wait for it _all the time_.
| Editing a message is an exercise in futility.
| ClumsyPilot wrote:
| I recently had to take screenshots of some 2 Year old
| messages in Telegram, WhatsApp and MS Teams. In Telegram
| it took 3 minutes to scroll through thousands of messages
| and load all that data, in What's app it took 25 minutes,
| and in Teams I never succeeded
|
| This is on an 8-core machine with a gigabit connection in
| 2021.
| pdimitar wrote:
| On my 2017 Xeon workstation and in Telegram, I can just
| press the Find shortcut, type a keyword and get results
| from back in 2015 in a manner of 1-2 seconds. It's
| amazing.
| ClumsyPilot wrote:
| Almost like software should actually work
| pdimitar wrote:
| Of course. That's what I was saying. It boggles my mind
| how something that basic is so hard in other apps.
| adimitrov wrote:
| On my 6 year old mobile phone, I can do the same thing in
| Signal. Takes seconds to find arbitrary strings in years
| long very active conversations.
|
| Honestly, I've no idea how we can accept bad performance
| in Teams and Slack. I can grep hundreds of megabytes of
| text in seconds on a raspberry pi. You have to actively
| try to make your software shitty to not be able to do
| that on a modern desktop.
| pdimitar wrote:
| I am with you but I don't think anybody deliberately
| makes software shitty per se. It's more like "not my
| damned problem" and everybody picks a framework or a
| library for basic stuff and piles them on top of one
| another.
| spuz wrote:
| I'm not quite sure I understand why you would need to
| scroll for 25 minutes to find an old message in WhatsApp
| when search is available.
| ClumsyPilot wrote:
| I needed evidence that 2 years ago I was in touch with
| that person - what was sent didnt matter, nor did i
| remember contents of the message at all.
|
| If what's app was not crap you could search by date, but
| I had to scroll.
| spuz wrote:
| Ok that makes sense - I think the best solution in that
| case is to try to think of a word that you may have used
| around that time and search for that - then if you get
| the right year you can at least scroll from there.
|
| Even so, I think WhatsApp's scroll is pretty fast
| especially compared to Teams. Teams only seems to be able
| to store 1 page worth of content in memory at any one
| time which makes scrolling for anything even an hour back
| excruciating.
| ClumsyPilot wrote:
| You scroll whatsapp for a bit, and then it takes 30s to
| load messages. Telegram scroll is _Instant_ , and trully
| endless, like a native app loading text should be
| stjohnswarts wrote:
| You'd think they would use the scroll bar like text
| editors do on huge documents. Just jump back to that
| point and keep +/- several screens rather than the entire
| freaking buffer. I wrote that for a basic text editor
| that I wrote for fun and it wasn't actually hard and
| would open gigabyte size documents almost instantly
| because I was only ever loading about a megabyte of info
| rather than the whole stinking file.
| pessimizer wrote:
| My first guess would be because what you're looking for
| isn't tagged with unique keywords (maybe just a vague
| idea of a date), or because pulling up a single message
| may not pull in it's context "grep -A/B/C" style.
| dathinab wrote:
| > you can't easily find again later.
|
| I sometimes have problems to find the new message I know I
| just got a few seconds ago due to how "non read messages
| marker" and "threads" (or however they call it) interact.
|
| I never understood why people where so hyped about slack
| while there most times where better alternatives.
|
| And let's not even get started about slacks audio/video chat
| function which is by far the worst I had used in recent
| times. Even the unliked MS Teams is miles better for voice or
| video chat. (Just to be clear I never used MS Teams for
| anything but voice/video chat.)
| IshKebab wrote:
| Not sure what you mean about Slack encouraging disjointed
| chats. It supports threading too and people use it almost all
| the time at my work.
|
| I agree it is hard to find things again, but that's mostly
| because Slack's search is pretty bad, not because of any
| inherent properties. It's no easier to find old emails or old
| IRC messages or even wiki pages.
| windexh8er wrote:
| A lot of people don't get threading. I'm in a small but
| active channel for our work team. It's roughly 15 people in
| a large company so it works well for us to engage and
| share. The problem is two others thread correctly, the rest
| just SPAM the main thread and when they do get the inkling
| to thread a reply it's often a new divergent thread off of
| a small conversation that someone threaded out earlier to
| be polite to the main.
|
| But the worst... The worst offender on our team thinks all
| of their replies must be seen by everyone. So they use the
| "Also send to #mainthread..." for _every_ message they
| send. It 's almost as if training on async chat is required
| for some as there's a total disregard for etiquette from
| some.
| ezluckyfree wrote:
| Yeah I think that if your team doesn't understand
| threading, Zulip will be even worse. Zulip's threading
| model takes many people a few hours to get accustomed to,
| even if those people are comfortable with threading in
| other clients.
| youppindsr wrote:
| You realize all this thread etiquette you say your
| teammate doesn't "get" are preferences you have that
| you've built up?
|
| The problem is Slack, not your coworker. Slack's threads
| are conversation killers. Your coworker doesn't want to
| get siloed into a discussion in a thread with only the
| people who saw the first message, but Slack encourages
| that.
|
| Sorry you're mad. Zulip does solve this problem one way.
| windexh8er wrote:
| If there's a thread that someone needs to be in our team
| is very inclusive. We just @ them into it and it's not an
| issue.
|
| I'm not mad. And there is an etiquette. I'm not blaming
| Slack - if you use it with some constructs in mind for
| how to keep conversations succinct and in their own
| places for others to easily find and use later - it works
| out better for all involved. There is value in using a
| tool in an efficient and repeatable manner that benefits
| all. This isn't a matter of being right or wrong. There
| are values in a user base being consistent in how they
| use a, mostly, unstructured tool - especially in the case
| of this example.
|
| Unfortunately abusing a feature that's meant for other
| use cases and is not there to always be used ("Also send
| to #...") _can_ be used incorrectly, and in this case it
| is. Everyone who needs to be in the thread is already
| there. It 's just broadcasting to everyone who doesn't
| need to be the statement they've made.
|
| I don't actually believe Zulip solves this problem, but
| it does look interesting for a number of other reasons.
| IshKebab wrote:
| You just have to tell them. It might feel rude but you
| can do it nicely. Our work has a :please_use_threads:
| emoji (a needle and thread) which is a nice polite hint.
| bartvk wrote:
| Gmail search is pretty great.
| darkwater wrote:
| I don't concur. If there is - and it's extremely ironic -
| a badly implemented feature in GMail, that's manual
| searching and especially filtering.
| stjohnswarts wrote:
| Please tell me what I'm doing wrong because it works just
| fine for me?
| IshKebab wrote:
| True, but I can't use Gmail at work so that doesn't
| really help.
| slimsag wrote:
| I think once Zulip gets a "guest mode", it will be a huge boon
| in its adoption for OSS communities. I love Zulip!
| tabbott wrote:
| > I think once Zulip gets a "guest mode", it will be a huge
| boon in its adoption for OSS communities
|
| Agreed!
|
| To clarify the terminology, "guests" in Zulip (and other team
| chat products, e.g. Slack) generally refers to users with an
| account but with limited access.
| https://zulip.com/help/roles-and-permissions has more detail
| on that.
|
| We've been tentatively planning to use the term "web-public
| streams" for streams that an open community has configured to
| be accessible without creating a Zulip account. The project
| is quite far along; the latest PR is here:
|
| https://github.com/zulip/zulip/pull/16728
|
| (The PR looks stale, but that's only because we paused
| integrating it to focus on finishing 4.0; I would be sad if
| we don't have it at least in beta this summer.)
| [deleted]
| fnord123 wrote:
| >It's quite sad Slack and Discord are often the first choice
| for open communities.
|
| Slack is particularly bad as you need to make a new account for
| each instance (i.e. project). And you need to log in to each
| instance separately on each device where you have Slack.
| tchock23 wrote:
| This is why I struggle to understand how Slack has been
| adopted so broadly for building online communities.
|
| The need to have separate accounts per instance is such a
| hassle. I spent twenty minutes yesterday trying to find which
| account I used to sign in to a dev-related Slack on a new
| laptop that had yet to login.
| kungito wrote:
| I don't like Slack but Discord is a great piece of engineering.
| They hit all the right spots for many types of communities.
| Personally for searching I actually with people used chat
| groups less and opened stackoverflow questions more. I hate
| having to search through unstructured chat to find if someone
| asked my question previously or if no one answers your question
| right away it gets buried under new questions. What zulip needs
| to compete against Discord is voice chats. I feel like many
| communities feel the need to exist on voice and chat channels
| at the same time and not having that forces people to have 2
| disconnected services
| Operyl wrote:
| To be fair, the Discord URIs are passed around in chat, etc.
| They're not that opaque, for a guild message it's just
| serverid/channelid/messageid. The numbers are snowflakes.
| pyaamb wrote:
| not seeing any mention of encryption
| anderskaseorg wrote:
| Zulip uses standard HTTPS encryption for traffic and Argon2 for
| passwords. See https://zulip.readthedocs.io/en/latest/productio
| n/security-m....
| switch007 wrote:
| The Zulip Django source code (the "zerver" subdirectory) is a
| great read too. It's Python 3 with a lot of typing hinting (has
| no mypy errors).
|
| Unlike a lot of Django code bases it heavily uses function-based
| views. It also uses relatively few third-party django apps.
| hardwaresofton wrote:
| Zulip's an awesome F/OSS chat option, consider contributing to
| it, even if it's only translations in your native language.
|
| The project seems healthy, and is growing at a good pace and
| adding more features and people aren't burning out, seems to be
| doing a lot of things right as far as F/OSS project management
| goes. Tim is also a joy to interact with.
| the_duke wrote:
| I was skeptical about Zulip when I first tried it. What is it
| supposed to be? A chat? A forum? Why is the UI so ugly?
|
| But after using it a while I now really dislike Slack et al, both
| in professional teams and for open source communities.
|
| Zulip can give you the best of both worlds. It's a regular chat.
| But the threading model also encourages long-form, more forum or
| email like discussions.
|
| Threads are easily discoverable and it's trivial to catch up on
| all the relevant discussions that you missed, while skipping
| everything that doesn't concern you.
|
| You can still have some regular chat channels for typical
| ephemeral discussion that no-one is expected to read. It's really
| a great tool.
|
| The only downside is the very subpar UX when compared to Discord
| or even Slack.
| StavrosK wrote:
| I think you mean "UI", as in "visuals", because the UX is the
| best, bar none.
| mushufasa wrote:
| I have heard a few people complain about the UI but I like it,
| and it seems comparable to other chat apps. What about
| Slack/Discord is better? Genuinely trying to understand.
|
| As for UX, I think Zulip has a strong advantage w/r/t the
| threading model, which you seem to be saying as well.
| robotbikes wrote:
| I think zulipchat has a usable UI but it's not as visually
| inviting as slack. Less brightness, colors, emoji and the
| like. It might actually have support for this stuff now as
| I've not tested the latest version. I'm not saying this stuff
| should be added but that's my takeaway on the differences.
| wtarreau wrote:
| Funny that you enumerated all the crap that I absolutely
| detest in slack. I think there are really two populations,
| those who should be considered definitely lost by having
| had their brain washed by UI vendors ruining user
| experience, and those who are still trying to get their
| work done through this ocean of horrors.
| nelsonlok wrote:
| Zulip is uglier in every aspect, like colors, icons, spacing
| and content organization. They should hire or recruit an UI
| designer.
| slimsag wrote:
| I have heard complaints where I work that less-technical foks
| find the UI unpleasant/confusing. I think it is due to a
| combination of the keyboard shortcuts being front-and-center
| and the threading model seeming "complex" (really, just
| logically structured)
|
| I'm not sure there is a strong/good argument against it,
| though. e.g. word processors are "more complex" than text
| files for sure, but people have learned the benefits of
| those.
|
| I think the education / user-onboarding flow could be
| improved perhaps.
| gvurrdon wrote:
| The usual complaints I get (as an admin of an instance)
| are: 1. "Hard to search"/"Can't find anything". 2. Off-
| topic responses because people post in whatever the most
| recent thread they used happens to be (results in (1)). I
| like it, though, due to having some similarities to a
| forum.
| abhigyank wrote:
| I had created this extension for my personal use, that
| "modernizes" the Zulip UI. Most people seem to have a better
| UI experience using it from the feedback I have received.
| Feel free to try it out . https://addons.mozilla.org/en-
| US/firefox/addon/prettier-zuli...
| tabbott wrote:
| Past experience suggests that many folks who are unhappy with
| Zulip's visuals are satisfied if they do the following
| things:
|
| * Using the night theme, which some folks strongly prefer to
| day theme.
|
| * Zooming to 110%, which makes Zulip's font size similar to
| Slack and its clones.
|
| With any luck, this summer we'll migrate our default font
| size to match other modern webapps, ideally with a "Dense
| mode" that preserves the current size for folks who want to
| fit more content on their screen.
|
| I've thought about changing the default theme to the day
| theme, but it seems a little sad to remove our current defaut
| (of automatically detecting the browser configuration via
| `prefers-color-scheme`).
| wikibob wrote:
| I STRONGLY recommend optimizing for the average non
| technical user and mass adoption. Basically, copy Slack's
| visual design as much as you can while retaining what makes
| Zulip great.
|
| Branding and visual design matters. Far more than most
| folks think.
| jacobolus wrote:
| > _Basically, copy Slack's visual design as much as you
| can_
|
| There are a ton of unpleasant / user hostile features of
| Slack's visual design. It is full of stuff blinking,
| flashing, popping in and out of view, etc. Trying to chat
| feels like having a conversation in the middle of a
| casino.
|
| So please don't do this.
| whoknowswhat11 wrote:
| Please do this - I deployed slack in a business
| environment - staff love it. Trying to get them to use
| alternatives with what they call "weird" interfaces is a
| no go.
|
| Slack nailed it - and adoption numbers are proving that
| out over and over.
|
| I got complaints even on teams font size being too small!
| Don't underestimate these issues.
| [deleted]
| wikibob wrote:
| And yet the average non tech user took to it like a fish
| to water compared to all alternatives that came before
| it.
| tabbott wrote:
| > I STRONGLY recommend optimizing for the average non
| technical user and mass adoption.
|
| I agree with that, and I hope my comment above didn't
| mean to sound dismissive of concerns about visual design!
|
| Visual work to mean these workarounds are not required is
| one of our main priorities for the next few months, and I
| mentioned the above mainly because many folks have found
| them helpful when using the Zulip that exists today.
|
| (As a sidenote, we have an open position for a designer).
| rattray wrote:
| I tried Zulip a few years ago and found it too "ugly" to
| recommend to non-technical peers (I also didn't grok the
| threads model).
|
| I checked the website now to see if I'd like the night mode
| better, and I can't find any screenshots with it!
|
| If people tend to vastly prefer zulips UI with the settings
| you mention, your product adoption will probably be much
| higher if your website screenshots show the dark mode with
| 110% zoom.
|
| While it'd be nice to improve the defaults, I know that can
| be disruptive - the quickest quickfix would be to mention
| those settings in the installation instructions.
|
| Failing the change mentioned above, it would at least be
| nice to include some screenshots on the help article about
| turning on night mode (ideally with some good alt text so
| google images picks it up).
|
| Disclaimer that I only looked at the top two DDG results
| for "Zulip night mode"
| mushufasa wrote:
| I strongly prefer the dark theme. My 2 cents is that using
| that as a default will be a good idea.
|
| FWIW I find the browser configuration check to be flakey in
| other contexts. Especially with non-technical people, who
| may never know to toggle dark mode.
| rattray wrote:
| Automatically detecting prefers-color-scheme is the right
| thing to do in general - maybe the day theme needs some
| improvements (based purely on this thread).
| IshKebab wrote:
| The thing that puts me off is that you have to choose a subject
| for every message. Bit of a pain. And I can't see how it's
| threading is significantly better than Slack's.
| xx789 wrote:
| Looks good but how does it compare to matrix/element?
| usr1106 wrote:
| At FOSDEM (I believe) earlier this year it was mentioned that
| zulip interoperabily with Matrix is actively being worked on.
| Unfortunately the release announcement does not mention it, so
| probably not yet ready for public release?
|
| As a regular zulip user it's a shock to me every time I have to
| use the element client. I have the feeling the latter is very
| slack-like in tis look and feel. I could be wrong on this,
| luckily I haven't had to use Slack for 3 years. Unfortunately
| with people used to Slack, it will be a shock to them to use
| zulip.
| brunoqc wrote:
| The thread feature is fucking awesome. I hope matrix implements
| something similar.
| vlmutolo wrote:
| I have very little experience with Zulip, so take this with a
| grain of salt. Just like Matrix, Zulip is open source and can
| be self-hosted. They both target instant-messaging use cases.
|
| Zulip has a far more advanced threading model than Matrix.
| Currently, Matrix only has basic replies in the spec. In
| practice, everything in a Matrix room is in a single thread. It
| definitely makes it hard to follow conversations that are long-
| lived or in busy rooms or both.
|
| Matrix is federated and Zulip isn't. You can run your own
| Matrix server and communicate with all the other Matrix servers
| that already exist. Rooms live on multiple servers and are
| resilient to the failure of any participating servers as long
| as one remains.
|
| Matrix is far more general than Zulip. It acts as a store for
| arbitrary, eventually-consistent, ordered JSON data. Most of
| the time this is used to create an instant messaging service,
| but it can be used for much more.
|
| Zulip subjectively has a nicer default client than Matrix
| (Element). Zulip's is special-built to handle its unique
| threading model.
|
| It's also worth noting that Matrix is adding support for
| arbitrary threading [0]. I'm really looking forward to this. It
| should allow us to build a Zulip clone fully in Matrix with all
| of the benefits that come with the Matrix ecosystem.
|
| [0]: https://github.com/matrix-org/matrix-
| doc/blob/kegan/msc/thre...
| tabbott wrote:
| On the federation front, if your goal is to connect different
| chat services running different chat protocols, that's been
| possible for years with tools like Matterbridge
| (https://github.com/42wim/matterbridge). Zulip also has
| direct bridge integrations with IRC and a handful of other
| protocols, e.g. https://zulip.com/integrations/doc/irc.
|
| These integrations are a bit ugly and certainly not the ideal
| design, but they work and help a lot of communities that are
| 90% on Zulip but still want an IRC presence for whatever
| reason. (A fun historical note: Zulip's had a really nice
| puppet-powered bridge with Zephyr since 2012, because that
| was how we got enough usage during its early development to
| design the product and its data model with real users).
|
| Longer term, we're planning to build a native Zulip
| federation feature. For us the technical strategy has been to
| first make a Zulip world-class user experience, and do native
| federation later.
|
| Our strategy is motivated by XMPP, which like Matrix is
| extremely general (E.g. I talked to people who used XMPP as
| message bus for their backend infrastructure 10 years ago).
| XMPP is dying as a chat protocol because nobody can build a
| modern world-class chat application using it as the
| client/server protocol.
|
| E.g. multiple people who'd worked as engineers on now-dead
| chat products complained that because their mobile apps
| talked XMPP to their server, it was impossible for them to
| make the apps start quickly in medium-size organizations,
| because of all the round-trips required.
|
| In contrast, Zulip's client/server protocol both on web and
| mobile returns all metadata in a single HTTP request:
| https://zulip.com/api/register-queue, and then after that,
| another to fetch whatever messages you're going to look at.
| MattJ100 wrote:
| As someone who worked on an XMPP web client that set up a
| whole session in a single HTTP request and response, I can
| say it's definitely possible to do this.
|
| XMPP also has optimisations so you can resume a session
| across network disconnects etc. so that session
| initialization is typically limited to app start.
|
| A more fundamental issue for many of these apps is that
| XMPP group chats were very presence-focused, and quite
| chatty (you need to join and sync every channel every new
| session). People have worked around that in various ways in
| the past. These days we have the newer 'MIX' standard for
| group chats which is not per session and far cheaper for
| many/large groups.
|
| XMPP has evolved, and continues to evolve. But I fear that
| people inventing their own chat protocols is a problem that
| can never be fully solved.
| mekster wrote:
| > You can run your own Matrix server and communicate with all
| the other Matrix servers that already exist.
|
| What's the benefit of this? Seems like a very niche feature.
|
| > Most of the time this is used to create an instant
| messaging service, but it can be used for much more.
|
| What other use could there be?
|
| I'd want a software that does one thing well because to this
| day there isn't even a chat solution that rules all the
| others.
| kitkat_new wrote:
| > What's the benefit of this? Seems like a very niche
| feature.
|
| Cross organizational communication, e.g. across ministries
| (like France realized it with 60 Matrix servers), across
| different offices of companies, across multiple companies,
| across universities (which was e.g. important for TU
| Dresden).
|
| In principle it is the same with Email.
|
| > What other use could there be?
|
| > I'd want a software that does one thing well because to
| this day there isn't even a chat solution that rules all
| the others.
|
| Matrix is a protocol, not a software. Specifically it is a
| communication protocol. So anyone can create software that
| needs communication which benefits from properties that
| Matrix provides, can use it independently of the software
| you are using to chat.
| vlmutolo wrote:
| If you can only talk to other people on your own server,
| then the application is limited to just team chat.
|
| Matrix clients have the potential to be much more. You can
| use the same account for various team chats and still use
| it like a messaging app for your friends and arbitrary
| personal groups.
|
| Maybe most importantly, federation provides resilience
| against bad server operators. If Signal had allowed
| federation, it wouldn't have been a big deal to ditch its
| servers when they introduced a sketchy cryptocurrency onto
| the platform. Because they don't allow it, everyone was
| locked in.
| tabbott wrote:
| I wish the Matrix/Element folks the very best of luck,
| because they're pretty aligned with Zulip values-wise.
|
| That said, I don't think you should expect a Zulip-style
| threading user experience in Element anytime soon. Regardless
| of how the Matrix protocol for federation between servers is
| extended, providing the "Zulip user experience" would likely
| require a major overhaul of both their client/server protocol
| for Element and their client user experience. (Also, the
| proposal you link is for HN-style threading, not Zulip-style
| topics).
|
| I don't understand Element's internals, but my basis for this
| claim is a huge portion of all technical and design work we
| do on Zulip wouldn't be necessary or would be much simpler if
| Zulip didn't have topics (E.g. the architectural decision
| criticized in https://news.ycombinator.com/item?id=27150492
| is a good example). See
| https://news.ycombinator.com/item?id=27150196 for a few more
| examples. I imagine Element will only invest in all of that
| work that if they believe it's important to their business.
|
| As an outside observer, Element's business focus seems to be
| on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not
| Slack, so while I'd love to see Matrix/Element borrow Zulip's
| topics model, you probably shouldn't hold your breath.
| vlmutolo wrote:
| Thanks for pointing out that the upcoming Matrix threading
| model I linked to isn't the same as what Zulip has. I
| wasn't thinking about Zulip's model correctly.
|
| After doing some research, I think you're right that the
| proposal won't immediately enable Zulip-style threading.
| Though, it seems like a small change on top of the linked
| MSC (Matrix Spec Change) proposal _would_ enable Zulip-
| style threading.
|
| If Matrix had an event type that created a "topic", that's
| all you would need. The linked MSC is very general and
| allows events to reference arbitrary parent and child
| events, and allows updating those parent and child
| relationships. If the parent is some kind of "m.topic"
| declaration event, maybe that would be enough.
|
| It's also entirely possible that Zulip style threading
| doesn't even require that new event and I'm just not
| familiar enough with Matrix to see how.
|
| ---
|
| Your points about how advanced the Zulip client is, though,
| are very true. It will take a ton of work for Element or
| some other Matrix client to catch up. You guys really built
| something impressive there.
|
| I look forward to seeing what Zulip comes out with in terms
| of federation. It's a tough problem.
| nolok wrote:
| I am not familiar with the github sponsors, patreon and all ... I
| would like to sponsor them in the name of a company I run, do any
| of those options give me an actual invoice ?
|
| Zulip is such a joy to use after other solutions. Threads are
| something that's hard to bend your team around at first (mainly
| non tech users), but they seem so obivous afterwards and it's
| hard to use another team chat without them.
|
| One of the few things I wish it had was better admin and audit
| tools, because in my industry that is mandatory and while you can
| do it by poking the database yourself a reliable, featured tool
| would be great. As-is I use Zulip for internal chat and another
| solution for external (with customers).
|
| In general, in its control panels and settings and options Zulip
| maybe feels a bit too "power user, then we restrict" than the
| other way around, eg when having an external user on my network
| it's a bit overwelming that their settings screen includes the
| entire org settings (but they can't change them). Pushing to your
| team is one thing, but when pushing something to customers or 3rd
| party any unwanted complexity is a major pain point.
|
| Frankly in general Zulip doesn't LOOK like something you want to
| show to the people you ask money from (your customers), just like
| your car dealer doesn't want you looking at the inside of the
| car's engine. I know it's a difficult complaint to tackle because
| it's not about functionnality but purely perception.
|
| Hope the team does well and looking forward to the future
| tabbott wrote:
| Thanks for being interested in sponsoring us! Contact us
| (https://zulip.com/help/contact-support); there's a few options
| for how we might get you an invoice.
|
| The product feedback on external guests is very helpful! You're
| encouraged to stop by chat.zulip.org and start threads in
| #feedback about each item if you'd like to help design how we
| address it, but in any case I'll discuss them with the
| community.
|
| (For readers missing context, Zulip provides read-only access
| to many organization-level settings to normal users as a form
| of documentation on the organization's policies and what
| options exist that one might ask an administrators to adjust).
| dang wrote:
| Some past threads:
|
| _Zulip 3.0: Threaded Open Source Team Chat_ -
| https://news.ycombinator.com/item?id=23860338 - July 2020 (133
| comments)
|
| _Zulip 2.1: open-source team chat_ -
| https://news.ycombinator.com/item?id=21779717 - Dec 2019 (1
| comment)
|
| _Zulip 2.0: Open source team chat_ -
| https://news.ycombinator.com/item?id=19284321 - March 2019 (96
| comments)
|
| _Zulip Server 1.9: HipChat import and much more_ -
| https://news.ycombinator.com/item?id=18400988 - Nov 2018 (123
| comments)
|
| _Zulip - Open-source, threading-based Slack alternative_ -
| https://news.ycombinator.com/item?id=17622987 - July 2018 (99
| comments)
|
| _Slack channels are a waste of time_ -
| https://news.ycombinator.com/item?id=17622707 - July 2018 (49
| comments)
|
| _Zulip 1.8: Free software Slack alternative with email-style
| threading_ - https://news.ycombinator.com/item?id=16863675 -
| April 2018 (148 comments)
|
| _Zulip Server 1.6 released_ -
| https://news.ycombinator.com/item?id=14506426 - June 2017 (14
| comments)
|
| _Dropbox has open-sourced Zulip_ -
| https://news.ycombinator.com/item?id=10279961 - Sept 2015 (313
| comments)
|
| _Dropbox Acquires Zulip, A Stealthy Workplace Chat Solution
| Still In Private Beta_ -
| https://news.ycombinator.com/item?id=7419408 - March 2014 (14
| comments)
| [deleted]
| Snuupy wrote:
| I love Zulip.
|
| I've been self-hosting since the 3.1 or 3.2 release for a group
| of friends and the threading model works great, especially when
| you log in after a break (whether that's 8 hours to go to sleep
| or 2 weeks after a vacation).
|
| When I was looking at setting up a chat server for me and my non-
| technical/mixed group of friends (so they couldn't use IRC and
| set up bouncers), I considered matrix, zulip, rocketchat, IRC,
| mattermost, and slack.
|
| When I had issues (I use the docker install), the team was very
| responsive on their zulip server (chat.zulip.org).
|
| For those of you already using Zulip, I prefer this dark theme
| over the standard (bright) blue one:
| https://github.com/zulip/zulip/issues/11845#issuecomment-544...
|
| Thank you Tim and the Zulip team for the great software.
| aidenn0 wrote:
| Recently there was a an article about how everyone should just
| use e-mail. People would talk about slack/discord &ct. I find all
| of those to be strictly worse than e-mail for me.
|
| Zulip is the only chat I've used that is better than e-mail for
| some purposes. It's got great export functionality and it's the
| only tool I've used that has better threading than e-mail. Every
| message has a thread, and therefore a subject, and you can
| dynamically re-thread sub-conversations.
| roamerz wrote:
| Many thanks to the Zulip team and all who have contributed to
| this amazing project. We went live on 4.1 and appreciate the bug
| free installation and there being no 'Enterprise Only' features.
| Inclusion of Active Directory integration was a key must have
| feature for us. We use Zulip to communicate between 9 separate
| organizations that happen to share a common app that uses AD for
| authentication so having to not have an additional password was
| awesome. We have been anxiously waiting for some features in this
| update and will be installing it in a couple of weeks. This
| project imho is exactly what open source should be. Kudos!!!
| tbarbugli wrote:
| How many users can you handle on a server and how does it scale
| horizontally in terms of connections?
| nautilus12 wrote:
| Whats to keep slack from just adding this feature and blowing
| their value prop out of the water?
| edoceo wrote:
| Slack is the legacy dinosaur now. So adding a dramatic feature
| shift like this to a mature product will be problematic for a
| big old project like them. They've got "enterprise" clients to
| consume their focus.
| netcraft wrote:
| As someone who is subjected to slack, I kind of hope this
| happens. I have my doubts they ever will though, or would be
| able to do it well.
| tabbott wrote:
| When I founded Zulip, one of my stated goals was to change how
| the world communicates to be more efficient, just as my goal in
| founding Ksplice was to make rebootless updates ubiquitous.
|
| So if Slack and all of its clones copy Zulip's model, I'd call
| that a success for us having changed the way people work. That
| said, Zulip is 100% open source under the Apache license (very
| rare these days), and that will remain a differentiator, as you
| can't self-host Slack, nor can you audit its source code or
| fork it to solve a problem specific to your use case. (We also
| have a lot of other innovative features, like native LaTeX
| support, customizable linkifers, etc.).
|
| That said, topics are not something one can just copy in an
| existing chat app -- there's a lot more to Zulip's topic-based
| threading model than "a feature".
|
| * Being able improve organization by renaming and splitting
| topics, move topics between streams, etc., is critical to the
| reading and conversation experience. This requires lot of
| thought about subtle technical and user experience details.
| (E.g. if someone renames a topic, and you were in the process
| of composing a reply, your compose box updates to the the new
| topic).
|
| * Tracking unread counts on a per-message basis, rather than a
| "pointer within a channel", which is required for splitting
| topics to do something sane. This, in turn, requires clever
| data structures so that the moment the browser loads, you can
| see where all 35000 unread messages are. (Folks routinely have
| that when they come back to a busy open community after months
| away).
|
| * All sort of clever performance and client-side caching things
| to make it feel like the browser has all your data so that
| clicking around feels instant.
|
| * Dozens more things along these lines.
|
| And those are just the engineering details. The bigger part of
| topics that it requires an overhaul of the whole UI. At least
| for us, a huge fraction of features are different than they
| would otherwise be because of topics (E.g. Zulip's compose box
| supporting sending to a different place than what you're
| looking at, and fading messages that weren't sent to that place
| to help users avoid mistakes). This sort of overhaul is hard to
| do, and even harder to do with a large existing userbase.
|
| As a result, if Zulip fails, I'd be very surprised if it's
| because other companies copied Zulip's model so well that there
| was no reason to prefer Zulip's topics implementation.
|
| Far more likely is some combination of our competition having
| infinite marketing dollars, inertia in organizations that don't
| realize how much better their working experience could be, and
| Microsoft's campaign to make everyone unwilling use anything
| other than Teams, because "we already bought Teams with our
| Office 365 subscription".
| O5vYtytb wrote:
| I work at a tech company of about 500. We've used zulip for a
| few years now and are looking to switch to teams/o365. The
| reason is to have more integration between email, documents,
| chat, video meetings, and calendar. Zulip has been good to us
| but as we grow it's increasingly burdensome to manage a bunch
| of disparate open source collaboration tools.
| StavrosK wrote:
| So many thanks to you for creating Zulip, I love it to bits.
| ubertaco wrote:
| Maybe a hot take here, but as someone who works for Salesforce,
| if the Salesforce acquisition goes through, my guess is that
| most of Slack's time for a while will be occupied on pushing
| through tight coupling to Salesforce systems in the name of
| "integration" rather than features users actually want.
|
| That's not based on any sorta "secret insider information",
| it's just the pattern I've seen with companies they/we acquire.
| alberth wrote:
| >Giphy integration.
|
| Am I the only person who'd prefer their, potentially corporate,
| chat not be tracked by Facebook.
|
| Facebook owns Giphy [0]
|
| [0] https://techcrunch.com/2020/05/15/facebook-to-acquire-
| giphy-...
| jimkleiber wrote:
| Whoa FB bought Giphy? I guess I missed that in the heat of the
| pandemic. Goodness I wish there were fewer acquisitions.
| halfmatthalfcat wrote:
| Is Tenor still independent?
| dustyharddrive wrote:
| tenor was purchased by google in 2018
| (https://techcrunch.com/2018/03/27/google-acquires-gif-
| platfo...)
|
| (edit to add info and link)
| [deleted]
| anderskaseorg wrote:
| Nope, you aren't. Zulip proxies all external images in messages
| through the server, including those from Giphy, to stop them
| from being used to track you. (Also, Giphy integration can be
| disabled per-organization by an organization administrator.)
| ArmandGrillet wrote:
| Side note: Signal does this as well, this is why privacy-
| oriented services still offer a Giphy integration.
| jimmyed wrote:
| Zulip has a notoriously bad db schema. For example, a single
| write in a 5000 member public group would result in 5000 writes
| to the user table.
| tabbott wrote:
| > Zulip has a notoriously bad db schema.
|
| Interesting, I've never heard that rumor before.
|
| > a single write in a 5000 member public group would result in
| 5000 writes to the user table.
|
| This hasn't been true since we implemented soft deactivation in
| 2017. You can read about the feature in our documentation here;
| I think it's a pretty cool design:
|
| https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
|
| The optimization takes advantage of the fact that public groups
| with 10Ks of members tend to have a lot of totally inactive
| users, and so if you have a good way to know that only 600 of
| them have logged in during the last 2 weeks, your server can
| run like it only has 600 users.
|
| It is true that Zulip writes a tiny UserMessage table row with
| (user_id, message_id, flags) for every active recipient of a
| message, we need to do so in order to track the unread state
| for all of those recipients (as well as related details, like
| mobile push notifications state). We need to write to that row
| a second time when the user reads the message.
|
| With modern postgres and SSDs, writing 1000 rows is really
| cheap, and so part this is extremely fast when sending messages
| with 1000 online recipients, which isn't a thing real users do
| constantly anyway (since that's effectively an announcement,
| not a chat message).
|
| Folks who are curious can read https://chat.zulip.org/#narrow/s
| tream/3-backend/topic/send_m..., which is related optimization
| work we did this week that made it into this release.
|
| (You could have a bad experience if you use remote storage that
| rate-limits "IOPS", though, because AWS at least used to count
| each row as an IOP and would use your full quota for 20s if you
| marked 20K messages as read with a 1000 UOP/s plan).
| darkwater wrote:
| > It is true that Zulip writes a tiny UserMessage table row
| with (user_id, message_id, flags) for every active recipient
| of a message, we need to do so in order to track the unread
| state for all of those recipients (as well as related
| details, like mobile push notifications state). We need to
| write to that row a second time when the user reads the
| message.
|
| No software architect here so I might be completely off the
| target but, is not read/unread count something that squares
| perfectly with the "eventually consistent" model? You don't
| need to write it down to the persistent storage right now as
| long as the client UI has it, then some kind of cache has it
| (so mobile can be in sync when refreshed) and then you
| persist it to the DB.
| tabbott wrote:
| We could certainly do something in that direction, but it'd
| be a lot of complexity (and risk of synchronization bugs)
| to avoid a few ~10ms of latency when sending messages to
| very large audiences.
|
| Especially since that latency is mostly invisible, thanks
| to local echo:
| https://zulip.readthedocs.io/en/latest/subsystems/sending-
| me...
|
| It's also not very high-value to optimize; that database
| write is 10-20% of the total time to process sending a
| message to everyone in a large open community like
| chat.zulip.org (with 18K total users).
| itamarst wrote:
| The "threaded" part is key here. Slack threads are useless
| compared to Zulip. In Zulip you can create threads on the fly
| from existing messages, so if discussion starts diverging you can
| turn it into a new thread. It's just a fundamentally superior
| model.
| karlicoss wrote:
| Yep! I think the author highlights it well
|
| > I received over 20,000 messages in chat.zulip.org during my
| paternity leave. I really enjoyed reading everything and
| replying to the hundreds of topics where I had something to
| contribute or someone to thank. Systematically reading months
| of history would have been impossible with any other tool!
| stefan_ wrote:
| Wait what? We are supposed to do that? My reaction after
| months long paternity leave to something like Slack messages
| would be "mark all read".
| jeltz wrote:
| I don't think anyone should be expected to do that but if I
| wanted to read everything it would be a huge pain to do so
| in Slack. It is nice to have it as a realistic option.
| karlicoss wrote:
| Fair enough, and depends on your FOMO -- but with Zulip's
| topics/threads you'd be the one who makes this call. E.g.
| you probably want to skip some banter or some operational
| stuff, but still catch up with the topics you want to catch
| up -- and at your own pace.
| tabbott wrote:
| (Post author here)
|
| I don't think most people need to read everything they
| receive, but in my role as the project leader of a large
| open source community, essentially every conversation in
| chat.zulip.org is potentially relevant for me, so skimming
| every conversation is useful.
|
| The critical thing here, both in my daily work and coming
| back from time away, is that Zulip makes skimming really
| cheap (`n` to jump to next topic, then read a moment and
| then hit `End` if it seems likely that the thread is
| resolved to check the conclusion, and then repeat). So a
| 150-message thread debugging something takes like 30
| seconds -- read the first post (maybe a bug report), note
| who was helping investigate, jump to send and see that the
| topic ends with a PR link or other resolution.
|
| At the same time, Zulip's organization means I could find
| the dozen of threads that might be a short thread
| presenting a question or problem that I'm our main expert
| on. In these cases, I can read the thread carefully, and
| send a reply resurrecting the thread (2 months later) with
| answer that was missing, some added context/background, or
| a link to a PR I made to put the answer in our
| documentation (my preferred solution to unanswered
| questions).
|
| This has the effect of unblocking a bunch of useful work
| that had been waiting for me to return, and also giving me
| good context on everything I missed.
|
| It's also pretty fun to see all the great that folks did
| while I was away :)
| tabbott wrote:
| Backing up from the special case of a paternity leave,
| what's important here is that with Zulip, catching up on
| conversations you missed is an efficient use of your
| time, which it really isn't for other team chat tools.
|
| Essentially everyone has miniature versions of the catch-
| up problem:
|
| * Fulltime employees coming back from a normal 1-2 week
| vacation. * Anyone working closely with collaborators in
| other time zones (I wake up every morning to a couple
| hundred new messages in chat.zulip.org sent by our
| international community members). * Any leader who spends
| a lot of time in meetings and wants to focus on the
| meeting and then batch-process communications afterwards.
| * Any engineer who wants to be able to spend a whole or
| half day focusing on a really difficult problem and catch
| up on conversations afterwards. * Anyone who's a part-
| time participant in an open community, whether they just
| check it once a day, one a week, or once a month. A user
| in this situation really wants to skim everything that
| happened and find what's interesting to them, not read
| the last few hours' traffic, which is what the
| Slack/Discord/Teams model forces you to do.
|
| The same technique core works for all of these cases:
| pick your favorite streams and read them with `n` as I
| described above, then perhaps browse the list of topics
| in several more and click into just the topics that
| interest you and then mark the rest (if any) as read.
|
| All IRC-inspired chat tools are a really rough experience
| for part-time participants -- they just don't have a way
| to let you prioritize reading interesting conversations.
| We discuss this issue at length and its consequences for
| inclusivity of the communities that use them in
| https://zulip.com/for/open-source/. (It's framed around
| inclusivity in open source, but the Slack channel model
| also can exclude leaders who spend most of their time in
| meetings)
|
| (As a sidenote, being able to do this is why Zulip pushes
| users to have every conversation in a topic, rather than
| "threading" being a side feature used for 10% messages
| like some other tools do.)
| Quiark wrote:
| Interesting. Threads in MS Teams utterly don't get used, they
| require significant self discipline to use properly (and yet
| they get more love from the devs than chat, somebody at MS is
| misguided in how the thing actually gets used).
| Something1234 wrote:
| All it takes is disabling the bottom new thread creation box
| and replacing it with a button. That's what work did and it's
| so easily enforced on the creation of new threads.
| gregmac wrote:
| Is this not just something MS Teams did? [1] You seem to be
| implying it's an optional setting or customization. I'm not
| an MS Teams admin, just a user on one instance of Teams,
| and was happy when the button appeared.
|
| It stopped the broken conversations, but it didn't make
| anyone use MS Teams any more than necessary. (Our group has
| been using Slack for longer than Teams has been around, and
| since Teams is still inferior in nearly every way we
| haven't switched; due to the near silence from every other
| org in the company, they're probably doing the same).
|
| [1] https://stitchdx.com/blog/microsoft-teams-new-
| conversation-b...
| rkangel wrote:
| By "threads" in MS teams, do you mean what they call a
| "conversation" in a normal channel? How do they not get used
| - people just 'start a new conversation' for every reply?
|
| We get basically perfect usage of the conversation system at
| work (an engineering org), and so I've always thought that
| the MS implementation was the best. It has almost all of the
| organisation positives of Zulip threading without forcing you
| to name every single thread, and with none of the onboarding
| pain. We also have 'New Conversation' as a button as
| suggested by a sibling comment, so maybe that's the key.
|
| I find it interesting that we both had fairly self-centred
| views on how much the conversation system was used. Don't
| forget that MS have the actual data!
| happytoexplain wrote:
| I've had the opposite experience with Teams threads. I'm at a
| big company where about half the posts are made by non-
| technical people, and yet the threads seem to get used pretty
| well. For all the things I hate about Teams, they seem to
| have hit a sweet spot in that bit of UI where it's hard (but
| not impossible) to accidentally add to an existing thread
| with a new topic, or accidentally make a new thread when you
| were trying to reply to a post, and because of that things
| stay pretty organized.
| mushufasa wrote:
| Zulip is one of the very few software tools that I really find
| a joy to use, because they make it easy to work within the
| correct patterns.
|
| Seriously, it's hard to express this experience until you've
| tried it. If you look at their feature lists, you can't
| appreciate the craft and love and thought put into Zulip that
| makes it stand out from other chat systems.
|
| And you may live in the chat systems with your distributed
| teams all day.
| StavrosK wrote:
| My current company uses Slack and I groan every time I have
| to use it. I miss Zulip greatly.
| aesyondu wrote:
| > Zulip is one of the very few software tools that I really
| find a joy to use
|
| I'd like to know what the others are.
| mushufasa wrote:
| like that magical moment when you understand unix pipes and
| how to powerfully tie things together with a shell one-
| liner
|
| except without requiring years to master
| [deleted]
| josephcsible wrote:
| Zulip is my favorite modern chat program because it's actually
| 100% FOSS, unlike Mattermost and RocketChat, which are only "open
| core" because they put a bunch of important features in closed-
| source enterprise modules.
| orsenthil wrote:
| With Zulip, why do you need two namespaces for every chat
| content? I find it hard to understand it, and thus it hasn't
| clicked with me yet.
| eigenspace wrote:
| One namespace (Stream) is a long-lived, durable category. The
| second namespace (Topic) is the specific conversation you're in
| and is more like an email subject line.
|
| Topics are lightweight and can be split, merged and moved
| around as needed.
| volta83 wrote:
| The Rust project uses Zulip and I love it.
|
| The onboarding cost is real, it takes ~5 min for someone to learn
| the tool which is far above the expectations of most users that
| expect it to just be "a chat".
| sam_goody wrote:
| I use Zulip all the time at work.
|
| It is ugly, sometimes will post to a different thread than you
| expect (not incorrectly, just the UI is very unclear where you
| are posting to), and has an _infuriating_ tick that if you click
| off the the input box, it deletes everything you typed.
|
| Otherwise, it gets the job done with minimum fuss.
| karlicoss wrote:
| Hmm, does it delete? I think it ends up in 'drafts'?
| sam_goody wrote:
| Well, lookit that. There is this drafts button, and I had not
| even realized it.
|
| Thanks, you just made my day!
| szaliony wrote:
| I have just registered to write the same thing :) I think
| that must be the problem. It's not a very easy to discover
| feature and I was also pretty pissed about losing my messages
| -- until I discovered the drafts. I guess the idea was that
| once you exit the input box Zulip doesn't know which thread
| you are going to reply to -- and in order to avoid sending
| messages to wrong threads it just clears the box (yet keeps
| your text). Makes sense in the threaded model, but could be
| highlighted a bit more. We have tried using Zulip at my
| company and the main complaint has been UX.
| tabbott wrote:
| Thanks for the feedback!
|
| We know this is a real UX problem, and we're working on it.
|
| Before Zulip 4.0, there was a "Saved as draft" notice that
| appeared on closing the compose box, but empirically, that
| was invisible to some users, who had the terrible
| experience of fearing their message was lost.
|
| The 4.0 release replaces the notification with a darker and
| better located notification, which will likely help some
| users. But we'll only know for sure whether it's still
| invisible to some users with time.
|
| In any case, we're planning several more changes to improve
| the drafts user experience that didn't make it into this
| release.
|
| https://github.com/zulip/zulip/issues/17396 is one current
| issue on the topic.
| gilbertbw wrote:
| > it deletes everything you typed
|
| It saves the message into your drafts
| elric wrote:
| Does anyone have any experience with both Zulip and Mattermost?
| Currently on Mattermost and wondering if it would be worth the
| hassle to switch. The threading does seem nice...
| mekster wrote:
| Mattermost isn't bad but not good either. I'd switch to
| anything else if it provides user friendlier interface but
| currently all the other open source alternatives provide even
| worse interface.
| it33 wrote:
| Mattermost CEO here, thanks for being a user!
|
| We'd love to improve, are there one or two things top of mind
| for us to change?
| fblp wrote:
| Congrats zulip team! A very inspiring open source product.
___________________________________________________________________
(page generated 2021-05-14 23:02 UTC)