6 ms·

Zulip founder here; I'm curious why you think that? Here's our thinking. Topics within a stream are ordered by the time of the most recent message. We keep t

Zulip founder here; I'm curious why you think that? Here's our thinking. Topics within a stream are ordered by the time of the most recent message. We keep the complete history, both of messages and topics, because it's useful for search and following up on things. Personally, I regularly reply to a conversation whose last message was a month or more ago to follow up with new information (often after getting there from one of the permanent links in our issue tracker). Because the context is all there and available with just a single click on the topic, I find it to be a really nice workflow.

grizzles 8y ago
The list of topics is too long to scroll through. For example, under general on zulip.org. A better UI would be if it just showed a few that it thought you might be interested in, and had autocomplete-type search for others.
- tabbott 8y ago
  I agree that the "more topics" thing takes up too much vertical space after just one click to see deeper history. We actually just had a discussion of it last week; the issue created from that is here: https://github.com/zulip/zulip/issues/10786 https://github.com/zulip/zulip/issues/10786
mehrdadn 8y ago
Hi there! I just started using Zulip (first-time user) looking forward to migrate off Slack and unfortunately I've been really disappointed. In Slack I can just load the website and begin typing into whatever channel I'm at (or use 1 click to select the right one if it's not the current one). In Zulip, it seems there's been a deliberately goal of explicitly designing it to be excruciating painful. For some reason Enter doesn't work by default (in which chat system is Enter an unfamiliar command for sending?!), and then I always have to press 'R' or click something to reply to (which often takes multiple clicks and several seconds)... why make things deliberately complicated/painful without even an option to turn off this 'feature'?
- rishig 8y ago
  Slack and Zulip are implementing pretty different communication models. In Slack, most messages are a single line, and are very real-time. E.g. if a channel is getting 100 messages a day, and a conversation starts in the morning, you're not going to try to engage with that conversation even that afternoon. In Zulip, communication is asynchronous by default. This has a lot of secondary implications; e.g. it means that by default you can assume people will see your message, rather than just the people that check in the next few hours. This means you can have substantive discussions on the platform, and the medium correspondingly encourages more multi-line, thoughtful posts. So we've currently decided that having to type an extra letter to compose is worth the tradeoff. As an example, not having compose open by default allows us to use single letter keyboard shortcuts for navigation. In any case, * You can enable "Enter to send": https://zulipchat.com/help/enable-enter-to-send https://zulipchat.com/help/enable-enter-to-send * Private Messages (called DMs in Slack) in Zulip work the same way they do in Slack, with an open-by-default compose box.
  - mehrdadn 8y ago
    Thank you for the reply! If this is the intention, then I'm baffled at how you intend your product to be used. Your advertisement of Zulip is completely at odds with... its fundamental principle? What I mean is, your website says "Zulip combines the immediacy of real-time chat with an email threading model", but it seems you're explicitly designing away the immediacy and requiring people to spend significant time thinking about what to type and clicking around to find the appropriate thread to reply to, just like with email. It can't function as a team chat system if it doesn't facilitate instant messaging -- "chat" systems are designed pretty much by definition to allow instant communication. (Like what "chatting" meant, before computers were around.) What you really seem to have is a shared-inbox email service -- kind of like a mailing list, but in a shared workspace, which would produce something that's more close to the exact opposite of your description... something like: "Zulip combines the deferred/asynchronous model of email with the shared-inbox nature of a mailing list". So here's my question: what do you expect teams to do when they actually need instant communication with the rest of the team? Do you expect them to have another (actual) chat system in parallel for that, or do you intend a model where you intentionally insert obstacles to make that viable somehow? I'm not talking about stuff you'd put in a email, so I'm not talking about something like "Let's discuss item 2 on the design doc. I think it would be better to approach the problem by doing X, then Y, then Z. This benefits us because Y helps us with Z and [blah blah]." I'm talking about stuff where there is something urgent going on and immediacy is the #1 priority, like "can s/b urgently cover me here I gotta run" or "what's up w/ the projector in C13?? I have a meeting" or "who's covering the slot rn? s/b's waiting" -- you know, the day-to-day stuff where the extra 10 seconds finding the right topic to reply to and the extra O(minutes) trying to articulate an eloquent email-like message for your team is going to tick everyone off (especially outside clients etc.) rather than please anyone. This kind of immediate communication is what teams need instant messaging systems like Slack for -- if your software is explicitly designed to discourage it, what do you imagine continuing to fulfill this need after teams switch to Zulip -- another parallel Slack?

grizzles 8y ago

The list of topics is too long to scroll through. For example, under general on zulip.org. A better UI would be if it just showed a few that it thought you might be interested in, and had autocomplete-type search for others.

tabbott 8y ago
I agree that the "more topics" thing takes up too much vertical space after just one click to see deeper history. We actually just had a discussion of it last week; the issue created from that is here: https://github.com/zulip/zulip/issues/10786 https://github.com/zulip/zulip/issues/10786

mehrdadn 8y ago

Hi there! I just started using Zulip (first-time user) looking forward to migrate off Slack and unfortunately I've been really disappointed. In Slack I can just load the website and begin typing into whatever channel I'm at (or use 1 click to select the right one if it's not the current one). In Zulip, it seems there's been a deliberately goal of explicitly designing it to be excruciating painful. For some reason Enter doesn't work by default (in which chat system is Enter an unfamiliar command for sending?!), and then I always have to press 'R' or click something to reply to (which often takes multiple clicks and several seconds)... why make things deliberately complicated/painful without even an option to turn off this 'feature'?

rishig 8y ago
Slack and Zulip are implementing pretty different communication models. In Slack, most messages are a single line, and are very real-time. E.g. if a channel is getting 100 messages a day, and a conversation starts in the morning, you're not going to try to engage with that conversation even that afternoon. In Zulip, communication is asynchronous by default. This has a lot of secondary implications; e.g. it means that by default you can assume people will see your message, rather than just the people that check in the next few hours. This means you can have substantive discussions on the platform, and the medium correspondingly encourages more multi-line, thoughtful posts. So we've currently decided that having to type an extra letter to compose is worth the tradeoff. As an example, not having compose open by default allows us to use single letter keyboard shortcuts for navigation. In any case, * You can enable "Enter to send": https://zulipchat.com/help/enable-enter-to-send https://zulipchat.com/help/enable-enter-to-send * Private Messages (called DMs in Slack) in Zulip work the same way they do in Slack, with an open-by-default compose box.
- mehrdadn 8y ago
  Thank you for the reply! If this is the intention, then I'm baffled at how you intend your product to be used. Your advertisement of Zulip is completely at odds with... its fundamental principle? What I mean is, your website says "Zulip combines the immediacy of real-time chat with an email threading model", but it seems you're explicitly designing away the immediacy and requiring people to spend significant time thinking about what to type and clicking around to find the appropriate thread to reply to, just like with email. It can't function as a team chat system if it doesn't facilitate instant messaging -- "chat" systems are designed pretty much by definition to allow instant communication. (Like what "chatting" meant, before computers were around.) What you really seem to have is a shared-inbox email service -- kind of like a mailing list, but in a shared workspace, which would produce something that's more close to the exact opposite of your description... something like: "Zulip combines the deferred/asynchronous model of email with the shared-inbox nature of a mailing list". So here's my question: what do you expect teams to do when they actually need instant communication with the rest of the team? Do you expect them to have another (actual) chat system in parallel for that, or do you intend a model where you intentionally insert obstacles to make that viable somehow? I'm not talking about stuff you'd put in a email, so I'm not talking about something like "Let's discuss item 2 on the design doc. I think it would be better to approach the problem by doing X, then Y, then Z. This benefits us because Y helps us with Z and [blah blah]." I'm talking about stuff where there is something urgent going on and immediacy is the #1 priority, like "can s/b urgently cover me here I gotta run" or "what's up w/ the projector in C13?? I have a meeting" or "who's covering the slot rn? s/b's waiting" -- you know, the day-to-day stuff where the extra 10 seconds finding the right topic to reply to and the extra O(minutes) trying to articulate an eloquent email-like message for your team is going to tick everyone off (especially outside clients etc.) rather than please anyone. This kind of immediate communication is what teams need instant messaging systems like Slack for -- if your software is explicitly designed to discourage it, what do you imagine continuing to fulfill this need after teams switch to Zulip -- another parallel Slack?