[HN Gopher] Zulip 3.0: Threaded Open Source Team Chat
___________________________________________________________________
Zulip 3.0: Threaded Open Source Team Chat
Author : nicholasjbs
Score : 323 points
Date : 2020-07-16 16:02 UTC (6 hours ago)
(HTM) web link (blog.zulip.com)
(TXT) w3m dump (blog.zulip.com)
| awill wrote:
| Is Dropbox still involved with this at all? It surprises me that
| Dropbox didn't integrate Zulip better, or combine it with
| Dropbox, Paper etc.. to create some kind of G Suite competitor.
| price wrote:
| Dropbox is not involved with Zulip. I'm not sure we've ever
| posted a good canonical write-up of that story, but here's a
| version I wrote a couple of years ago:
| https://news.ycombinator.com/item?id=17629329
| awill wrote:
| Thanks for the background. So it sounds like Zulip was purely
| an acquihire.
| lwf wrote:
| [First engineer at Zulip; work at Dropbox]
|
| Portions of Zulip's backend were used to power some Dropbox
| features in 2014-16, but the product itself wasn't further
| integrated.
|
| In any case, I'm proud of how we handled the handoff to OSS
| and a sustainable independent stewardship org. I have https
| ://ourincrediblejourney.tumblr.com/post/146708555778/zu...
| framed on my wall.
| bovermyer wrote:
| I would love to use this, but I don't manage any communities that
| aren't already married to either Discord or Slack.
| tabbott wrote:
| FWIW we have been seeing a lot of larger communities that
| previously were deadset on Slack because "everyone knows it"
| importing their data from Slack in the last few months.
|
| Part of the reason is that Zulip's topics make it a lot easier
| for a part-time participant to use their limited time well
| (E.g. skimming or reading the conversations in most relevant to
| them in batch a few times a week). The Slack/Discord/IRC/etc.
| data model limits how effectively one can participate and
| benefit from a high-traffic organization without constantly
| watching it (and being in the organization's dominant time
| zone!).
|
| More on the inclusivity issues with synchronous chat here:
|
| https://zulip.com/for/open-source/
| bovermyer wrote:
| Awesome.
|
| Well, I have no users because there's no community yet, but I
| did set up a Zulip (cloud) for my Iron Arachne project.
|
| I plan on linking to it from the website's main menu.
| pantaloony wrote:
| Man, do I ever miss chat services and chat clients not being so
| tightly coupled to one another.
| tiffanyh wrote:
| I recently was in the Zulip community design stream and the topic
| of their UI came up.
|
| I absolutely love Zulip but I'm afraid the design keeps folks
| from joining.
|
| There was a recommendation for it to update their design to be
| more like Discord new light theme [1] or Twist [2].
|
| Twist is the more fair comparable since they are both Thread
| based (like email subject line) it's just that Twist isn't open
| source.
|
| [1]
| https://miro.medium.com/max/4050/1*iwfLW4rnn6U-mlUQpmBAfg.pn...
|
| [2]
| https://get.twist.help/hc/article_attachments/115005750965/i...
| monadic2 wrote:
| How is the experience of trying to find a conversation from a few
| months ago?
| tabbott wrote:
| A big benefit of the organization provided by every message
| being in a topic is that it makes finding this more efficient.
| E.g. if you remember that Steve made a joke about donuts in the
| conversation, you can search for messages sent by Steve
| mentioning donuts, find the topic, and from there find the
| actual conversation. I do this to find months-old or years-old
| conversations several times a week.
|
| If you're curious to hear more,
| https://monadical.com/posts/how-to-make-remote-work-part-two...
| talks about this idea in more detail.
|
| I also highly recommend making use of Zulip permalinks to
| conversations in issue trackers and other resources -- my
| anecdotal sense is most projects using Zulip do that a lot (the
| Zulip development team certainly does). Certainly the main
| feedback we've gotten on the zulip.com domain transition is
| "Will my permalinks keep working???". (Yes, they will).
| JoshTriplett wrote:
| The Rust community uses Zulip heavily; I'm on it every day.
|
| Before I tried it, I was a little resistant to "yet another chat
| platform", and I didn't know how easily the threading model would
| work. Once I tried it, I got used to it very quickly, and started
| very much enjoying it. I'd highly recommend it.
|
| I also think it works well with automation; bots can create
| threads, and do things in response to messages in those threads.
| StavrosK wrote:
| I can't recommend Zulip enough. It made remote communication many
| times easier, it's a dream to use because it's faster than Slack
| (though that bar is so low you have to dig to find it) and Riot,
| and its keyboard navigation is second to none.
|
| The mental model might take an hour or two to click, but you can
| think of it as Slack rooms where the only thing you can do is
| open new threads (can't post messages in the room itself, only in
| the threads).
|
| I really really think everyone should try it, it's a big
| improvement.
| JoshTriplett wrote:
| > The mental model might take an hour or two to click, but you
| can think of it as Slack rooms where the only thing you can do
| is open new threads (can't post messages in the room itself,
| only in the threads).
|
| I've used both Slack and Zulip, and I wouldn't describe it that
| way. Slack threads feel more "isolated" by default, hidden away
| from the conversation, and you have to go look at each one; a
| Slack channel where you can _only_ create threads doesn 't feel
| like it'd be as appealing a UI as Zulip. On Zulip, you can look
| at the entire stream to see messages from different threads in
| real-time, _or_ you can look at just one thread and see only
| the messages from that thread.
| StavrosK wrote:
| Oh, yes, the UI is fantastic in how it handles this, but I
| was describing the general data structure. Some people had
| trouble grasping the mental model initially, and I found
| thinking of it in those terms helpful for figuring out what's
| going on.
| JoshTriplett wrote:
| Part of the reason I brought this up was that this is
| roughly how Zulip was first described to me, and my
| experience with threads in Slack made that sound _really
| unappealing_ , which led me to avoid trying Zulip for quite
| some time. Once I finally tried it, it was completely
| different than I expected, and much better.
| StavrosK wrote:
| Oh, yes, that makes sense. I'm definitely not trying to
| entice people with that description, I more intend to
| help them understand what they're looking at when they do
| try it.
| zaphod4prez wrote:
| LOVE zulip!
| evacchi wrote:
| Zulip is great! We've been using it for kie.zulipchat.com
| (Drools, jBPM, OptaPlanner, Kogito). Quarkus team uses it too.
| Can't recommend it enough. Only downside so far, you can't mute
| private conversations. Overall great experience, though; threads
| really work.
| liquid153 wrote:
| Can you do screensharing and audio call in Zulip?
| Jeaye wrote:
| Zulip integrates with Jitsi Meet, so the video call button
| generates a unique Jitsi meeting link which everyone can join
| without installing anything or making an account.
| tabbott wrote:
| Also, new in this release: BigBlueButton (another OSS
| video/call project).
|
| This release removes Google Hangouts support (as Google
| killed it and rebranded it to Google Meet). Unfortunately,
| the Google Meet rebrand came with removing the API that was
| useful for third party tools like Zulip. I don't understand
| why they don't provide the brilliant API Jitsi has where you
| can just generate a URL containing a random meeting ID and
| everyone who clicks it gets the same meeting (which Google
| Hangouts did, at least if everyone was in the same G Suite
| team).
|
| We also support Zoom (though note that Zulip Cloud is stuck
| in their marketplace approval process as it has been for
| months; supposedly it'll get approved any day now).
|
| https://zulip.com/help/start-a-call
|
| (And of course we're happy to integrate anything else that
| has a reasonable API)
| agustif wrote:
| Threads are the new black. It looks cool, might try it before
| Slack.
| kitd wrote:
| Cf. any usenet client
| aloisdg wrote:
| Both Reddit and HN do it right too.
| garborg wrote:
| It's had that model way before Slack, et al., kind of bolted it
| on. I've participated lightly in a couple orgs that use Zulip.
| Zulip's model does a much better job of keeping convos from
| getting drowned out / lost when pushed off the page, so it's
| much easier to log in sporadically and meaningfully
| participate. The apps, especially mobile have rough edges, but
| I still prefer it to Slack and the like, fwiw.
| brians wrote:
| It's a descendant of Zephyr, a lovely chat system that had
| great success in the world of stable IPv4 addresses,
| statically assigned, but which really hasn't made the mobile
| transition acceptably. Namable threads are amazing.
| hardwaresofton wrote:
| Made some small contributions to Zulip and I can confirm that
| their team (and leader) is super friendly, and it's actually
| relatively easy to self-host these days.
|
| My personal favorite thing about Zulip is the keyboard navigation
| and how much muscle memory you can build moving around
| threads/conversations. Of course there's also the actual markdown
| (not some weird variant).
| jamesponddotco wrote:
| I am looking for something to replace XMPP with our team; I
| wonder if Zulip could be the one. I do like the thread idea.
|
| Does anyone know if there is a CLI client, and if E2E encryption
| is possible with Zulip? It does not seem like these are built-in,
| but maybe someone built these as add-ons somewhere.
|
| I love XMPP, and OMEMO, but Profanity, and Conversations have
| some weird quirks when used together that we would rather avoid.
| And while we would love to just move to IRC, and WeeChat, lack of
| E2E encryption is a deal-breaker.
| tapoxi wrote:
| https://element.io/ ?
|
| Like XMPP it supports federation, but Matrix is JSON instead of
| XML.
| Ericson2314 wrote:
| Yes if you want an XMPP replacement with E2E you definitely
| want Matrix.
|
| (Element, formerly Riot, is the client by the company founded
| by the founders of Matrix.)
| jamesponddotco wrote:
| I looked into it a couple of times, but most clients lack E2E
| encryption support, and the oficial ones are Electron
| monsters. We mostly work over SSH on remote workstations,
| hence the CLI/TUI requirement.
|
| Altough, it seems there is a plugin for WeeChat with E2E
| encryption[1]. Gotta take a look.
|
| [1] https://github.com/poljar/weechat-matrix
| abhigyank wrote:
| There is a Zulip CLI client - https://github.com/zulip/zulip-
| terminal .
| jamesponddotco wrote:
| Awesome, and it seems to be official as well. They could
| mention it on their website, even though it is still not
| considered stable.
|
| Now to look for E2E encryption support.
| johnisgood wrote:
| I suppose for private messages it would be relatively easy
| to implement that, or add OTR support or something.
| rakoo wrote:
| E2E encryption kinda breaks with the model of Zulip, ie a
| company or a project where everything should be visible by
| everyone even if they arrive after the conversation has
| started. You'll probably be better served by hosting your own
| instance and trusting everyone who connects to it.
| jamesponddotco wrote:
| That is another thing, it would be even better if we could
| control E2E encryption per room.
|
| Since we do everything in the open, instead of needing
| something like XMPP for private conversations, and IRC for
| public conversations, we could simply have private rooms with
| E2E encryption for the team, and public rooms for everyone
| else.
|
| I wish IRC had E2E encryption.
|
| In the end, I think we might stay with XMPP with OMEMO for
| private conversations -- or Matrix, depending on how well
| weechat-matrix work --, and use mailing lists for public
| discussions. We already use them for patches anyway.
| jjordan wrote:
| Zulip is fantastic, and any steps we can take to free ourselves
| from the walled gardens is a good one, IMO.
| timwis wrote:
| I love the idea of this, but I'm trying to move my team away from
| synchronous communication. That tends to put us back in email,
| though that has its own problems. What is the asynchronous
| version of zulip? Forums?
| c17r wrote:
| There's twist https://twist.com/ from the makers of ToDoist
| wott wrote:
| > _That tends to put us back in email, though that has its own
| problems. What is the asynchronous version of zulip? Forums?_
|
| Newsgroups (NNTP)?
|
| (I don't know Zulip and I don't know what problems you have
| with e-mail, so that's just a guess.)
| price wrote:
| The asynchronous version of Zulip is Zulip. :-)
|
| A thing I really like about how Zulip works is that a
| conversation can happen asynchronously just like email, as well
| as synchronously. And the same conversation can shift smoothly
| from one to the other and back. I work on Zulip, and we
| basically don't use email at all - it's all either in Zulip or
| on a GitHub thread. (And the interesting discussions, I
| increasingly try to make sure to do on Zulip because GitHub is
| such a frustrating place to have a conversation.)
| molsongolden wrote:
| Adding on to +1 this.
|
| Zulip is great for async communication because it surfaces
| unread messages in an easy to skim and non-overwhelming way.
|
| After a day of not checking Zulip, the user can then open the
| chat and (before seeing any actual messages) see:
|
| 1) which streams have had activity.
|
| 2) which threads/topics within those streams have had
| activity.
|
| then choose which topics to read in a "relevant to me, not
| relevant to me" quick skim.
|
| Having the topics within streams also allows those topic
| discussions to persist over time without being lost in the
| deluge of other messages.
|
| There might be thousands of other chat messages between when
| I ask a question in #frontend > supercool.js but a teammate
| will skim later, see
|
| #frontend > supercool.js [1]
|
| and think "hey I know about supercool.js, what's up?" then
| respond.
|
| I can also search to see if there's already a supercool.js
| topic thread and catch up on what we've discussed in the
| past.
| micimize wrote:
| I find Zulip really promising, but lack of topic archival has
| always been troubling to me:
| https://github.com/zulip/zulip/issues/11154
|
| Aside from that, I think it's biggest potential killer feature is
| tight issue thread integration:
| https://github.com/zulip/zulip/issues/12340
|
| Very exciting project
| eigenspace wrote:
| A group of us in the Julia open source community have been trying
| to migrate to Zulip [1] from Slack. There's a lot of resistance
| from some community members, but those of us who made the switch
| are quite happy.
|
| The topics model is fantastic, having proper markdown and LaTeX
| support is also killer.
|
| The development team for Zulip is also really responsive and
| friendly. Coming from Slack, it was a breath of fresh air to be
| able to make an issue on their GitHub issue tracker and have
| fast, friendly thoughtful replies and quick action.
|
| [1] https://julialang.zulipchat.com/#recent_topics if you wanna
| check it out
| dTal wrote:
| That's excellent news. Being locked out of the community by
| virtue of it being hosted on a proprietary service, requiring a
| proprietary code blob to access, was one of the biggest sour
| notes I had coming to Julia.
|
| (Now if only discourse.julialang.org links would render without
| Javascript!)
| oehtXRwMkIs wrote:
| Remind me of Rust with the added bonus of requiring a GitHub
| account to upload crates.
| dijit wrote:
| FWIW Rust has a zulip, I'm on it, it's the only community
| I'm part of on zulip.
|
| It's mostly frequented by the infrastructure teams. :)
|
| Apparently the compiler team is also >primarily< there:
| https://rust-lang.github.io/compiler-team/about/chat-
| platfor...
| fareesh wrote:
| Unrelated question - I went to chat.zulip.com in the browser and
| signed up. Scrolling through the messages (pixel xl2) is
| incredibly laggy.
|
| If I were to build a similar UI on some project, what's a good
| way to ensure good scrolling performance on the web?
| tabbott wrote:
| I notice you mention a pixel phone; are you by any change using
| mobile Chrome? I think this is
| https://github.com/zulip/zulip/issues/14943, which sadly didn't
| get fixed for this release but is being worked on.
|
| Generally Zulip's scrolling and view-switching is very smooth
| and a ton of work has gone into it (my view is that if an app
| that you use all day isn't snappy it's going to waste tons of
| your time).
|
| The short answer for how to make good scrolling performance
| (like any other performance work, really) is to profile, make
| sure you understand what's happening, and fix it. It can be
| hard to predict what makes things slow without doing so. (Fun
| fact: seemingly reasonable ways to use an emoji spritesheet
| with CSS can wreck scrolling performance).
| eigenspace wrote:
| I find the scrolling quite fast. Do you have a huge amount of
| unread messages by chance? I think I remember some issue where
| a gigantic amount of unread messages can reduce performance.
| There's a 'mark all messages as read' button.
| hereisdx wrote:
| Apart from a user, I am also a contributor to the Zulip project,
| for the last ~7 months.
|
| The community is very helpful and for getting started with open
| source development, I can't recommend a better place. You get
| really high quality code reviews, get to participate in
| meaningful discussions on features and the development goals of
| the project, and developers constantly share lots of knowledge in
| streams like #learning about software development, tech, git,
| best practices and so on.
|
| Also, the documentation is very detailed and the codebase is very
| high quality. It's really easy to get started.
|
| You can find the github org here: https://github.com/zulip
| tabbott wrote:
| Thanks for the kind words!
|
| One of our goals as a project is to have a "teaching-quality"
| codebase, so this is no surprise. I think this is incredibly
| important and something every community open source project
| should strive for.
|
| An analogy I like to use is to think about the experience of
| contributing to your open source project as a product, so you
| should:
|
| * Do usability studies where you help a group of people try to
| get started with your product (I used to do this all the time
| at events like Python conference sprints pre-pandemic). The
| first few we did were eye-opening as nobody got anywhere
| without a lot of handholding, and I suspect that's common.
|
| * Make the development environment tooling Just Work and have a
| good support experience.
|
| * Write good documentation that thoughtfully explains the ideas
| one needs to understand to participate on your project. My
| strategy for this was to avoid explaining how things work to a
| contributor, and instead meet the need by spending a couple
| hours writing something like
| https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
| and send it to them. That way, even if that contributor bounces
| (as the vast majority of new people who show up to any
| volunteer organization do), I still used my time well.
|
| I'm planning a series of blog posts on building a successful
| open source community, since we've spent a lot of time thinking
| about how to make contributing to Zulip a great experience, and
| some ideas are subtle (E.g. the secret to being able to give
| high quality code reviews is equipping new contributors with
| the tooling and documentation to help them avoid problems
| before a reviewer even looks at it!), and I regret not having
| spent more time sharing that thinking.
| sdesol wrote:
| > The community is very helpful and for getting started with
| open source development
|
| That probably explains the healthy number of active developers
| for this project:
|
| https://imgur.com/XwhDHVZ
|
| Based on my simple analytics that looks at the time between a
| contributors first and last commit, I'm getting 50 active
| contributors, which matches up with many of the other popular
| open source projects I've indexed.
| hereisdx wrote:
| Also, that's just the server project. There are also clients
| like the mobile app and the terminal app, which have a whole
| new set of active contributors.
| cobbzilla wrote:
| As a fellow Zulip user and minor contributor, I wholeheartedly
| agree.
|
| In addition to coordinating development teams on three
| continents, we also use Zulip as an integration hub. git
| commits go in the #commits channel, jenkins build status to
| #builds, and run-time errors to #errors.
|
| We use errbit (API-compatible Airbrake clone) for error
| reporting and Zulip didn't have an errbit integration.
|
| So I wrote one, and they integrated it within a few days. The
| Zulip team was super-responsive and easy to work with. It
| certainly helped that they had excellent docs on how to write
| integrations, and tons of examples.
|
| Go Zulip!
| sandGorgon wrote:
| Does Zulip have India/Asia pricing?
|
| Slack has an exchange rate adjusted pricing which is much cheaper
| (in dollar terms) for people paying from India.
| spooneybarger wrote:
| We've been using Zulip for the Ponylang community for about 18
| months now. It is by far our favorite tool in the "chat"
| category.
|
| And this release addresses three of our biggest gripes.
|
| We highly recommend.
| dang wrote:
| If curious see also (related threads):
|
| 2019 https://news.ycombinator.com/item?id=19284321
|
| 2018 https://news.ycombinator.com/item?id=18400988
|
| 2018 https://news.ycombinator.com/item?id=17622987
|
| 2018 https://news.ycombinator.com/item?id=17622707
|
| 2018 https://news.ycombinator.com/item?id=16863675
|
| 2017 https://news.ycombinator.com/item?id=14506426
|
| 2015 https://news.ycombinator.com/item?id=10279961
|
| 2014 https://news.ycombinator.com/item?id=7419408
| chubot wrote:
| Threads are one major reason I like Zulip over Slack, but speed
| is another. I usually have two different instances open on my
| browser with no problems, and one of them has dozens of
| conversations going on at once.
|
| Zulip is also one of the only apps I put on my iPhone, and it's
| straightforward and unobtrusive.
|
| For some reason when I use Slack, the keys feel mushy. I think
| they're doing so much stuff in the background that my keystrokes
| get delayed.
| isbjorn16 wrote:
| They are the primary reason to use Zulip. In this way, Zulip is
| more of a Teams competitor than it is a Slack competitor.
|
| I, frankly, cannot stand threads. I want a chat room, not a
| realtime forum. I understand why people would like that, but it
| still bothers the shit out of me.
|
| I work for MS so we have to use Teams, but I'd prefer opt-in to
| threads vs. threads by default. I fully understand and accept
| that my way isn't going to be the way for everyone, but when
| looking for a community chat option for friends, we uninstalled
| zulip in less than a day and ended up going with matrix. That
| didn't work super well for us at the time so we went with
| Mattermost, which much closer aligns to our chat preferences.
|
| The good news is there are tons of options for people to choose
| what fits best for them! That's super exciting!
| chubot wrote:
| Of course you should use what you like, but I'm also puzzled
| because you can "ignore" threads if you want in Zulip by
| keeping your focus on the channel.
|
| For example I have a channel called #oil-discuss. It has a
| bunch of separate threads. If I put the focus on the left bar
| in #oil-discuss, then it shows me all the messages in
| chronological order, regardless of thread.
|
| If you click on a thread, then you see only the messages in
| that thread. So I think it's the best of both worlds.
|
| ----
|
| Unfortunately it doesn't go the other way around in my
| experience -- Slack can't emulate Zulip. I joined Slack to
| discuss a nascent Python project.
|
| https://twitter.com/teoliphant/status/1217611221396082695?la.
| ..
|
| The creator of the channel encouraged everyone to use Slack
| threads to keep the conversation organized. But the threading
| was so awkward -- it felt felt like my replies were getting
| "lost" on the side, outside the main flow.
|
| Multiple people disliked the Slack threading and eventually
| we tried python-dev's nascent Zulip instance instead.
| Although I think the conversation died out in both places for
| other reasons.
| isbjorn16 wrote:
| I'd suspect it depends on what you're using it for - our
| instance of chat is primarily roughly themed chat rooms
| where we can talk about video games and bitch about python
| or rust or scala or home improvement projects or the news.
| It's very much so a modern day AOL chatroom experience, and
| that's by desire. We have discourse for things that make
| sense for deep threading, but for the most part everyone
| ignores it and just uses the chatrooms or the fairly
| effervescent threading in MM (that is basically the same as
| Slack's).
|
| If you're looking for a more real-time mailing list type
| behavior though, then Slack or MM would be a terrible,
| terrible, terrible choice imo.
| jlokier wrote:
| > The good news is there are tons of options for people to
| choose what fits best for them! That's super exciting!
|
| Personally I'm finding it a bit of a nightmare, as just about
| every community I'm interested in seems to require a
| different tool to be installed. Same for work clients.
|
| Worse than that, some communities are fragmented into
| different IM tool groups.
|
| The plethora of IM and other tools needed to stay vaguely
| involved in the leading edge conversation in multiple
| communities is a right pain for usability.
|
| What I really want is some way to see an overview of
| conversations in multiple communities I'm interested in and
| interact with them through that. A single tool would be nice,
| but some way of visually integrating similar tools would be
| ok as well.
|
| I was pretty happy with Pidgin for this many years ago, as it
| worked with almost everything. But even then I needed Skype
| separately. I don't think libpurple is quite as universal
| now.
|
| Matrix is an attempt, but by no means a solution.
| isbjorn16 wrote:
| I tend to use the web clients for everything for just this
| reason. Turning notifications on gives me the same toast
| behavior I'd have in a thick client and I'm not running 14
| instances of electron at a time. I can see this being
| frustrating for you, though (just because I found something
| that works for me doesn't mean it'll work for everyone!)
| jlokier wrote:
| That's a good suggestion, and as it happens I use web
| clients when possible as well.
|
| That sucks in a different way, as the experience tends to
| be sub par, but at least it works (when on desktop - it's
| high friction when I've only got my phone to hand).
|
| It's still much like having a different application for
| every community or work client though - only it's become
| a different _tab_ for each of them, with the tabs
| organised by application rather than by usefulness (or
| there are too many tabs), which is a poor way to
| organise.
|
| It also makes it difficult to organise information beyond
| the crude tools provided. Desktop notifications exist,
| yes, but I would find it so much more useful to be able
| to filter content and notify me of only relevant things,
| sort, pin, annotate, link and so on. And for this
| prioritisation and context management to mediate between
| different information sources globally, rather than
| having to use my own brain to do it manually, which I
| find to be a significant cognitive load.
| StavrosK wrote:
| Can't you just make a single "general" room and talk in
| there? Have you ever used Zulip? Your objection puzzles me a
| bit because I can't see how it's a problem, since your use
| case is trivially supported.
| isbjorn16 wrote:
| Yes, I've used zulip - every single comment spawned a
| thread or responded to a thread. Users weren't used to
| responding to a thread, which meant we had threads of
| single comments _constantly_. I 'm puzzled that you're
| puzzled. I thought this was the way Zulip worked. It was
| about 2 years ago, at any rate. Did it change since then?
| If so, that's exciting in its own right.
| molsongolden wrote:
| This is the case (and it's okay)!
|
| Every message (other than PMs) is within a topic thread
| which is within a stream.
|
| This can be structured by having ongoing social threads
| but users do need to know that they should respond to
| existing "broad topic ongoing" threads instead of
| creating a new micro-thread for every message.
|
| We structure the Streams into roughly:
|
| - company-wide announcements
|
| - org streams
|
| - team streams
|
| - social
|
| then within #social you could have ongoing topics like
| "books", "weekend", "music", etc...
|
| You can also restrict stream access as needed (only team
| members can view the team stream).
| isbjorn16 wrote:
| I bet that was the problem; we created streams for
| channels and vs. having a single stream with all the
| channels being threads inside of them.
| StavrosK wrote:
| Hmm, that sounds like something was going wrong, threads
| don't just spawn, you have to create them, and a thread
| with a single comment kind of defeats the purpose.
|
| Oh, were you editing the subject every time you
| commented, maybe? That's not indicated, you only edit the
| subject when you want to create a new thread. In our use
| case, threads were relatively infrequent and specific to
| a topic, e.g. "middle name database migration", and
| that's where the discussion for that happened.
| isbjorn16 wrote:
| Somehow we had like 15 users and not one of them managed
| to make a comment that wasn't a new thread - like I said
| though, it was like 2 years ago. Either there was a bug,
| or it was a design decision, or maybe even a
| misconfiguration on the server - regardless it got a
| hearty thumbs down by the community and we went on to try
| matrix. I was hoping for Zulip since it was a way easier
| install than matrix + riotweb was, especially since we
| wanted to self host _everything_. In the end all the bugs
| we had in riotweb and the phone apps were enough for us
| to jump for MM, which has its own problems but was most
| in line with what we wanted.
|
| Anyway, if Zulip isn't thread-first, then I guess it's
| less a competitor to Teams than I thought. The only way
| we found to make teams work for us and our very small
| team is to keep everything in a named joint chat and
| everyone utterly ignores the channels like the plague.
| It's always amusing when someone posts something to a
| channel for the first time in weeks/months and then
| people start responding thinking it's chat and every.
| single. response. becomes a new thread, because they
| didn't respond inside the original thread.
| StavrosK wrote:
| That's very odd to me, I've never had that problem and
| don't see why it could be.
|
| Zulip is thread-only, it's just that thread can be used
| as channels if you ignore the top level (streams).
| rst wrote:
| You may not even need the app. Zulip on Android Firefox is a
| better experience for me than the app, personally. (Tho the web
| version was, oddly, severely laggy in mobile Chrome the one
| time I tried it, some time ago...)
| hereisdx wrote:
| Can you share what you did not like about the app? I would
| love to know what the users don't like so we can work on
| those areas.
| rst wrote:
| The UI is somewhat confusing; also, it seems designed to
| give a view of particular, selected streams and topics of
| interest, and doesn't always seem to keep up even with
| those -- but volume on my server is low enough that I want
| "all messages", and if there's UI which does that
| reliably... it's not signposted well enough for me to find
| it before my patience ran out.
| StavrosK wrote:
| Oooh, thanks for this. I adore Zulip but the Android app is
| pretty terrible :(
| chrismorgan wrote:
| I noticed the changed logo and favicon today. I'm not fond of it
| yet: I find the discontinuity in the middle of the Z crossstroke
| surprisingly disconcerting. At large sizes it might work out OK
| (though I'm not convinced, it's still feeling unbalanced
| somehow), but at small sizes it _really_ doesn't work.
|
| Furthermore, they've changed the style of the "number of unread
| messages" badge on the favicon so that it's bigger and less...
| neat, is probably the right word, having gone for the "write the
| number in a normal sort of a font on a semitransparent white
| background and sit that atop the original favicon" rather than
| writing the number in what's essentially a small bitmap font
| without needing the semitransparent white bit; and given that
| style, it looks quite terrible on a dark background, which my tab
| bar is. It ends up looking like the icon is just a number on some
| indistinct mess, with no real substance of the logo left visible,
| where before it was a clearly-visible small number on a clear and
| distinct Zulip logo. It's unfortunately fundamentally impossible
| to pull off the style they've changed to--you _must_ know whether
| it's going to be matted against a dark or light colour for it to
| work, and the web doesn't give you that. (I really wish it did.
| Sure, there are a couple of workarounds like using the (prefers-
| color-scheme: dark) media query to guess that the tab bar is
| _probably_ dark, and that if that doesn't match it's _probably_
| light, but that's still _wildly_ inaccurate and insufficient.
| It's a big enough deal that I'd like browser manufacturers to
| come up with something.)
|
| In all this I do say that I'm not fond of it _yet_. It'll
| doubtless feel more acceptable after a few days. But comparing my
| reasons for disliking it with other occasions when I've not liked
| change (either at first or forever), I don't _think_ it's going
| to grow on me as much as many do.
| price wrote:
| Thanks for the close look :-) We're aware that the favicon
| image doesn't come out great at small sizes. Right now it's one
| SVG for all sizes, and I expect we'll have tweaked PNGs
| specific to small sizes out soon.
|
| For the number-of-unreads bit: might I persuade you to make an
| account on chat.zulip.org and come give that feedback there?
| That way we can perhaps iterate on variations of it and you can
| discuss those too.
| nikisweeting wrote:
| Zulip has been absolutely pivotal in our company's remote work
| setup. It becomes a searchable knolwledgebase as a side-effect of
| its threading model (the exact opposite of the pile of
| unorganized mess that Slack usually devolves into):
|
| https://monadical.com/posts/how-to-make-remote-work-part-two...
| muska3 wrote:
| Honestly I found Zulip way too confusing. Am I the only one?
| eigenspace wrote:
| Not the only one for sure, but I suspect that the big reason
| people are confused by Zulip is that they're already used to
| another, different chat service and don't remember how confused
| they were by it in the start.
| switch007 wrote:
| I remember coming across the Django part of the project a while
| ago and thought it was quite nice and pretty. Neither over-
| engineered nor under.
| https://github.com/zulip/zulip/tree/master/zerver/lib
___________________________________________________________________
(page generated 2020-07-16 23:00 UTC)