4 ms·

We used Zulip at $job[-1] and it was awfully painful. I’ve used nearly every chat client invented since the BBS days, and Zulip was one of my least favorite. We

We used Zulip at $job[-1] and it was awfully painful. I’ve used nearly every chat client invented since the BBS days, and Zulip was one of my least favorite. We’re using Slack now at $job and I vastly prefer it (even though I still call it “IRC”). The biggest selling points of Zulip, from the POV of the people who put it in place and truly loved it, were that it’s free/OS software, it has explicit threads as a first class citizen, and that it’s very configurable. All those things are true. The day-to-day use was painful, though. It was riddled with UX problems, e.g., forgetting state between restarts, inconsistent hotkey support, multi-action use paths for common cases, frequent full reloads of its web view. I’d much rather use vanilla IRC than Zulip. Slack is just enough of a shim layer on IRC, and with good usability. It has threads, and in use it’s not a problem that you can’t name them like Zulip. The integrations are nice to have (e.g., type `/zoom` to start a Zoom meeting) but not a big deal. The UX is clear and predictable and (mostly) stays out of my way.

tabbott 5y ago
Hi! I lead the Zulip project. I'm sorry to hear you had a bad experience with Zulip. If you can share details on the UX problems you had, perhaps in https://zulip.com/development-community/ https://zulip.com/development-community/ where we can have an extended conversation, I'd be very appreciative. I personally review every issue reported in zulip, and some of the specific problems you cite are not unfamiliar and surprising to me. Specifically: * I'm not aware of a plausible explanation for Zulip frequently doing full reloads of the web view. Zulip's core design is to live-update everything [1] and there's only a handful of code paths that can trigger a full reload (the most common being when the server version was updated, and in that code path, the client has an algorithm where it waits up to 30 minutes for a moment when your window is idle and not focused to reload to get the updated version, to minimize the chance of disruption). * I'm also not sure what what state might be forgotten between web client restarts; almost all of our client UI updates happen via the client asking the server to change something, and the client updating via the same server-client push mechanism that updates other clients (the main exception to this is sending messages, where local echo is important for UX reasons). And at least the server-initiated reloads are designed to preserve your precise scroll position, compose box state, etc., and that's been true since ~2013. (Though we did fix a couple bugs where compose box state was not properly preserved in the last year). I know you're not using Zulip currently, so your memory may be imprecise, but any additional detail that could help us reproduce what you experienced would be awesome! [1] https://zulip.readthedocs.io/en/latest/subsystems/events-system.html https://zulip.readthedocs.io/en/latest/subsystems/events-sys...

tabbott 5y ago

Hi! I lead the Zulip project. I'm sorry to hear you had a bad experience with Zulip. If you can share details on the UX problems you had, perhaps in https://zulip.com/development-community/ https://zulip.com/development-community/ where we can have an extended conversation, I'd be very appreciative. I personally review every issue reported in zulip, and some of the specific problems you cite are not unfamiliar and surprising to me. Specifically: * I'm not aware of a plausible explanation for Zulip frequently doing full reloads of the web view. Zulip's core design is to live-update everything [1] and there's only a handful of code paths that can trigger a full reload (the most common being when the server version was updated, and in that code path, the client has an algorithm where it waits up to 30 minutes for a moment when your window is idle and not focused to reload to get the updated version, to minimize the chance of disruption). * I'm also not sure what what state might be forgotten between web client restarts; almost all of our client UI updates happen via the client asking the server to change something, and the client updating via the same server-client push mechanism that updates other clients (the main exception to this is sending messages, where local echo is important for UX reasons). And at least the server-initiated reloads are designed to preserve your precise scroll position, compose box state, etc., and that's been true since ~2013. (Though we did fix a couple bugs where compose box state was not properly preserved in the last year). I know you're not using Zulip currently, so your memory may be imprecise, but any additional detail that could help us reproduce what you experienced would be awesome! [1] https://zulip.readthedocs.io/en/latest/subsystems/events-system.html https://zulip.readthedocs.io/en/latest/subsystems/events-sys...