
Zulip 3.0: Threaded Open Source Team Chat - nicholasjbs
https://blog.zulip.com/2020/07/16/zulip-3-0-released/
======
eigenspace
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](https://julialang.zulipchat.com/#recent_topics)
if you wanna check it out

~~~
dTal
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!)

~~~
st1ck
I don't quite get this concern about proprietary JS. I agree JS can be
malicious, but it has nothing to do with license. Or you can say you don't
want to give your data to Slack.

~~~
dTal
I sympathize with those who object to proprietary JS, but in my case I'm
mostly annoyed at having to run code just to read static content - quite heavy
code, too. When I have a lot of discourse.julialang.org pages open, my browser
noticeably chugs.

------
nikisweeting
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...](https://monadical.com/posts/how-to-make-remote-work-part-two-
zulip.html)

~~~
krisreddy
I dont get why everyone thinks that searching for anything in a chat system is
a good idea. This has nothing to do with how good the search engine is within
the system. Because of Slack's inadequate design, they promoted searching, and
now everyone thinks search is a MUST. If you really have to search in chat, I
say you already have done something wrong. If searching in an email system,
with its vastly more structured data, is itself inefficient, why would anyone
think searching in chat is a good idea?

~~~
varispeed
Well, if you discussed some detail and can't remember which channel / thread
it was on then the search is a must. I could agree that search may not be
needed for a small team of a couple of people, but large teams with dozens of
channels and topics should be able to search them to find required
information.

~~~
krisreddy
If thats the scenario you think search is most applicable for, you are going
to be sorely disappointed. Firstly you have to remember what it is you are
looking for. Even if you do, the information is hidden in so many channels
that you are unlikely to find what you are looking for without some effort. I
think the best search is no search at all. Searching makes sennse for VERY
large universe of data, as in WWW. The sheer volume makes creation of
optimized search engine a profitable one. But a small universe search engine
is inherently sub-optiomal, & is going to make the user sift through the
"results" to find what they are looking for.

------
StavrosK
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
> 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
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
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
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.

------
chubot
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
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!

~~~
jlokier
> 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
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
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.

------
hereisdx
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](https://github.com/zulip)

~~~
tabbott
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...](https://zulip.readthedocs.io/en/latest/subsystems/sending-messages.html) 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.

~~~
ssivark
Thanks for you comment with interesting points. It’s quite different from the
perspective of “scratching an itch” open source code. I look forward to your
posts on nurturing open source communities.

------
JoshTriplett
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.

------
dang
If curious see also (related threads):

2019
[https://news.ycombinator.com/item?id=19284321](https://news.ycombinator.com/item?id=19284321)

2018
[https://news.ycombinator.com/item?id=18400988](https://news.ycombinator.com/item?id=18400988)

2018
[https://news.ycombinator.com/item?id=17622987](https://news.ycombinator.com/item?id=17622987)

2018
[https://news.ycombinator.com/item?id=17622707](https://news.ycombinator.com/item?id=17622707)

2018
[https://news.ycombinator.com/item?id=16863675](https://news.ycombinator.com/item?id=16863675)

2017
[https://news.ycombinator.com/item?id=14506426](https://news.ycombinator.com/item?id=14506426)

2015
[https://news.ycombinator.com/item?id=10279961](https://news.ycombinator.com/item?id=10279961)

2014
[https://news.ycombinator.com/item?id=7419408](https://news.ycombinator.com/item?id=7419408)

------
jamesponddotco
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
[https://element.io/](https://element.io/) ?

Like XMPP it supports federation, but Matrix is JSON instead of XML.

~~~
jamesponddotco
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](https://github.com/poljar/weechat-matrix)

------
timwis
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?

~~~
price
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
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.

------
spooneybarger
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.

~~~
maneesh
What were the gripes?

------
tiffanyh
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...](https://miro.medium.com/max/4050/1*iwfLW4rnn6U-mlUQpmBAfg.png)

[2]
[https://get.twist.help/hc/article_attachments/115005750965/i...](https://get.twist.help/hc/article_attachments/115005750965/inbox.png)

------
sandGorgon
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.

~~~
tabbott
We don't at present have an official policy on it, but we'd certainly be open
to creating one. (And of course one can always self-host).

What is Slack's adjusted pricing in India/Asia? I don't see it advertised on
their website.

~~~
sandGorgon
[https://slack.com/intl/en-in/pricing](https://slack.com/intl/en-in/pricing)

------
neumann
I love Zulip. Not only does work smoothly and with no bugs, it was one of the
least painful installs and maintenances of any recent service I've tried to
self host.

I've tried to get traction with it as a self hosted solution at a few orgs
instead of cloud offerings, and often meet with resistance by ITS in party
because of the pains of administering a lot of these products. However, one I
have succeeded pushing it through the feedback has been, 'Great, it just
worksout of the box. We don't have to deal with it regularly'.

------
micimize
I find Zulip really promising, but lack of topic archival has always been
troubling to me:
[https://github.com/zulip/zulip/issues/11154](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](https://github.com/zulip/zulip/issues/12340)

Very exciting project

------
AceJohnny2
I found Slack's design discussion on how they decided for single-depth threads
interesting. There's a balance to strike between powerful features and
usability.

[https://medium.com/slack-design/threads-in-slack-a-long-
desi...](https://medium.com/slack-design/threads-in-slack-a-long-design-
journey-a7c3f410ecb4)

Of course, people here have self-selected for favoring threads, but Slack's
attention to the silent negatives is interesting and a lesson in product
design.

~~~
price
In the context of this post, an important thing to add is that threads in
Zulip also have just a single level of hierarchy - it's not at all like the
tree structure here on HN, or on Reddit. We've felt that single level is the
right balance for having a conversation that someone else can come to an hour
later and easily read and follow.

The way it works in Zulip is quite different from Slack, though. Here's a
description in another comment in this thread:
[https://news.ycombinator.com/item?id=23863588](https://news.ycombinator.com/item?id=23863588)

------
dzonga
the codebase is beatiful, however this is a nasty gem:
[https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe4...](https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe474e9e2ae7fe050c5/zerver/models.py#L831).
if it was me, I would've broken that into at least 3 models

~~~
aero31aero
Good point! When I was new to the Zulip codebase I thought the same but after
a while, my views changed. Its a very long model (and file) but very linear
and organized, so it doesn't have that usual set of problems for which we have
the common wisdom of not having long classes or methods.

Basically, for this you have to ask yourself why you want to split it and what
would you split it to. If ultimately what we'll get is something like
UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one
long UserProfile.

------
hardwaresofton
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).

------
switch007
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](https://github.com/zulip/zulip/tree/master/zerver/lib)

------
jjordan
Zulip is fantastic, and any steps we can take to free ourselves from the
walled gardens is a good one, IMO.

------
evacchi
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.

------
erlend_sh
Seeing as Zulip is growing ever closer to a chat/forum hybrid, I hope you’ll
consider making Zulip instances browsable by guests, just like a Gitter or
Discourse instance.

~~~
Cyphase
The master issue for that project is
[https://github.com/zulip/zulip/issues/13172](https://github.com/zulip/zulip/issues/13172).
It's being worked on and is considered a high priority.

There's also an archive tool at [https://github.com/zulip/zulip-
archive](https://github.com/zulip/zulip-archive).

------
fareesh
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
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](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).

~~~
fareesh
Seems to be the case. Scrolls fine on Firefox

------
awill
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
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](https://news.ycombinator.com/item?id=17629329)

~~~
awill
Thanks for the background. So it sounds like Zulip was purely an acquihire.

~~~
lwf
[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...](https://ourincrediblejourney.tumblr.com/post/146708555778/zulip)
framed on my wall.

------
muska3
Honestly I found Zulip way too confusing. Am I the only one?

~~~
cookiecaper
No, we've had several experienced users immediately disengage because they
felt overwhelmed and/or confused (not using as synonyms here, but common
related reactions) by the interface. Performance issues, especially on mobile,
haven't helped. Most people are just annoyed that you aren't using their
favorite chat app already.

Zulip is promising but I think there's a little bit of a bubble around it here
on HN. In the real world, its reception is much more mixed, and outside the
context of software development, topic threads are awkward and difficult to
manage.

------
bovermyer
I would love to use this, but I don't manage any communities that aren't
already married to either Discord or Slack.

~~~
tabbott
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/](https://zulip.com/for/open-source/)

~~~
bovermyer
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.

------
lathiat
Sounds like this is a better UI for Slack Threads.. which they were doubling
down on in twitter just this week.

------
mderazon
Can anyone compare the threaded model to Google Chat threads ? Is it the same
?

~~~
nikisweeting
Google chat is completely unthreaded as far as I can tell. Unless you mean
Google Groups?

~~~
mderazon
The other other Google chat
[https://gsuite.google.com/products/chat/](https://gsuite.google.com/products/chat/)
[http://chat.google.com](http://chat.google.com)

~~~
nikisweeting
Woah wth I've never even seen this before. Since when does this exist? Is it
cross-compatible with Hangouts at all?

~~~
mderazon
It is completely different product, any GSuite accounts gets this included for
free.

It has weird relationship with Hangouts. It was previously called "Hangouts
Chat" but that was too confusing (doh) so they've changed it to "Google Chat"

When someone sends you a message there, it sometimes pops in your Gmail
Hangouts widget... So a lot of people are not aware it exists.

------
monadic2
How is the experience of trying to find a conversation from a few months ago?

~~~
tabbott
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...](https://monadical.com/posts/how-to-make-remote-work-
part-two-zulip.html) 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).

------
red2awn
Congratulations to the Zulip team, this release looks awesome!

------
liquid153
Can you do screensharing and audio call in Zulip?

~~~
Jeaye
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
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](https://zulip.com/help/start-a-call)

(And of course we're happy to integrate anything else that has a reasonable
API)

~~~
j1elo
Is BigBlueButton, or Zoom, covering different use cases than Jisti? or they
are offered just for the sake of offering alternatives?

------
zaphod4prez
LOVE zulip!

------
chrismorgan
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
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.

------
agustif
Threads are the new black. It looks cool, might try it before Slack.

~~~
garborg
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
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.

