Zulip Server 1.9: HipChat import and much more • Hacker News Board

Re: Zulip Server 1.9: HipChat import and much more

#121

Post by rishig » Tue, Nov 13, 2018, 3:39 PM UTC

mehrdadn wrote: post #120

tabbott wrote: post #48

Earlier quoted context omitted.

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 fr…

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 Ent…

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

* Private Messages (called DMs in Slack) in Zulip work the same way they do in Slack, with an open-by-default compose box.

Re: Zulip Server 1.9: HipChat import and much more

#122

Post by mehrdadn » Tue, Nov 13, 2018, 7:26 PM UTC

rishig wrote: post #121

mehrdadn wrote: post #120

Earlier quoted context omitted.

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 Ent…

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…

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?

Re: Zulip Server 1.9: HipChat import and much more

#123

Post by rishig » Tue, Nov 13, 2018, 9:46 PM UTC

mehrdadn wrote: post #122

rishig wrote: post #121

Earlier quoted context omitted.

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…

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 th…

Got it, thanks for the concrete examples.

I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product.

The actual extra actions are:

* up to one extra keystroke to open the compose box

* typing a subject line like "projector C13"

You wouldn't have to search for a topic to send a message like that; you would just start a new topic. And "what's up w/ the projector in C13?? I have a meeting" would still be a perfectly fine Zulip message.

And then on the receiving end, you actually save a bunch of time.

* There's a simple keyboard shortcut ('n') to see the message that just came in.

* The fact that there's a subject line means that everyone sees "projector C13" and decides if they're a person that can respond to that, even if they aren't caught up on the rest of the channel.

* If someone does respond, you can see that they responded to your message, and not to some other conversation that's going on in the channel. That makes it easier to keep an eye on the conversation while the rest of you is improvising a solution.

Re: Zulip Server 1.9: HipChat import and much more

#124

Post by mehrdadn » Tue, Nov 13, 2018, 10:21 PM UTC

rishig wrote: post #123

mehrdadn wrote: post #122

Earlier quoted context omitted.

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 th…

Got it, thanks for the concrete examples. I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product. The actual extra actions are: * up to one extra keystroke to open the compose box * typing a subject line like "projector C13" You wouldn't have to search for a topic to send a mes…

> I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product.

The thing I don't get here is you have two competing claims/goals, both of which I could buy in isolation and in fact agree are perfectly reasonable goals, but both of which actively contradict & fight against each other. On one hand you believe it'd take the same amount of time as before if people would only learn to use the system as designed (which I'll take at face value here), but on the other hand you say "the medium correspondingly encourages more multi-line, thoughtful posts". Writing more thoughtful messages and coming up with subject lines by definition requires more time... how can it not?

Re: Zulip Server 1.9: HipChat import and much more

#125

Post by rishig » Tue, Nov 13, 2018, 10:45 PM UTC

mehrdadn wrote: post #124

rishig wrote: post #123

Earlier quoted context omitted.

Got it, thanks for the concrete examples. I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product. The actual extra actions are: * up to one extra keystroke to open the compose box * typing a subject line like "projector C13" You wouldn't have to search for a topic to send a mes…

> I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product. The thing I don't get here is you have two competing claims/goals, both of which I could buy in isolation and in fact agree are perfectly reasonable goals, but both of which actively contradict & fight against each other…

I agree that on the benchmark of time-to-send-a-message, Zulip is slightly slower than Slack, which is in turn slower than just putting the whole company in a WhatsApp group.

But the end goal is not sending messages, the end goal is getting the person who knows about the projector to see your message and respond, for you to see that response, etc.

In a moderately sized company, Slack is better than the WhatsApp solution, since you can direct the message at roughly the correct set of people, by spending the extra time to choose a channel. In turn, those people are more likely to get the message in time to act on it, because the message won't be buried under tons of messages meant for other people in the company.

Zulip takes that a step further, by adding subject lines to messages. The same tradeoff applies.

I think in the end the question really is how much more work it is to add the extra signal. The best case would be you could send messages like in WhatsApp (no subject line, and every message goes to the entire company), and read messages like in Zulip (subject lines, and with channels limiting audience). For both Zulip and Slack, the premise is that we can drive down the cost of adding the extra signal to low enough.

Re: Zulip Server 1.9: HipChat import and much more

#126

Post by price » Tue, Nov 13, 2018, 11:41 PM UTC

mehrdadn wrote: post #124

rishig wrote: post #123

Earlier quoted context omitted.

Got it, thanks for the concrete examples. I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product. The actual extra actions are: * up to one extra keystroke to open the compose box * typing a subject line like "projector C13" You wouldn't have to search for a topic to send a mes…

> I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product. The thing I don't get here is you have two competing claims/goals, both of which I could buy in isolation and in fact agree are perfectly reasonable goals, but both of which actively contradict & fight against each other…

I'd like to respond to another point you raise, in addition to what rishig said (which I agree with):

> you say "the medium correspondingly encourages more multi-line, thoughtful posts". Writing more thoughtful messages and coming up with subject lines by definition requires more time... how can it not?

I think the key here is that you can write more multi-line, thoughtful posts, and they come through and sustain a real conversation much better than they do on Slack or IRC. But when that's not what's called for, you can also write super-quick short messages too.

For example, a few months ago the Zulip developers gathered in one place for a week to hack together. We had a stream (~channel) for the event, and one frequent topic in it was "schedule". A lot of the messages there were like "@all dinner's ready" -- dashed off on a phone, notifying everyone in the group, so a lot like sending to a WhatsApp group.

But other messages on the same topic were things like the next day's schedule or some detailed logistics, sent from a laptop with a real keyboard. It was helpful to have those details in the same thread as context above the quick right-now updates.

Other topics contained a variety of side discussions, some consisting of quick short messages ("found an X, who lost it?"), others detailed and thoughtful. A lot of those would have been lost in the noise in a Slack channel or a WhatsApp group, or would have added noise to make the other conversations hard to follow, or both.

And it was extremely helpful that all of the above was in the same system that we use all the time for in-depth technical discussion and other collaboration.