we don't send notifications for @-mentions, by default. instead, mentions ends up in your activity feed so you can check it on your time. But, for when you need to reach someone, we have !!-mentions — which will send a notification.
(you can also set per-channel and per-thread notification settings — so you can turn it down, or turn it up.)
(I work at Quill.) Yes! That's exactly how we think about it. By default, @-mentions _will not_ notify you, and instead end up in your activity feed. And if something is truly urgent, we have priority notifications (!!-mentions) which will send a notification. (They have a higher cost, and make it very clear that it will cause disruption on the other end.)
We think of it as bringing the way people behave in person, online. If you have headphones on, working away, and I have a low priority question, I'll find you later. But if I just brought down prod, I urgently need to reach you :)
Fantastic - you should make this a bit more clear as it feels very apple oriented,
Throw this under the 'Professional Messaging' with something like 'Cross Platform': 'Works on all your favorite tools - your browser, Mac, Windows, Android, and iOS.'
Otherwise, this just feels like an apple garden app.
(I work at Quill.) Everything in Quill is a thread -- which is quite a big shift from an IRC-like firehose (even with optional threading.) We've found the shift to have threading by default creates a behavior where you opt into just the conversations you care about, and don't have to skim through hundreds of messages to find what's relevant (or, say, replies to an earlier conversation.)
May be hard to get across the _feel_ of using a product in screenshots -- we're ramping up our invites (making sure things scale + features work as expected!) but we'll be fully open quite soon! :) (and, we might be slightly partial to dense UIs!)
What you're saying makes a lot of sense to me, but I think the OP's comment still has valid insight. The point about the in-your-face bright colors all over the place could be addressed as easily as muting down the colors of the tags that you're not subscribed to. You could click the tags you want to subscribe to, which would instantly brighten them.
The choice to use color as a primary axis for differentiating users in a thread is interesting. I can see the appeal in it – disentangling voices at a glance is potentially high-value in a group conversational UI – but it also comes at a pretty high cost in terms of visual complexity, as evidenced by some of the reactions.
Another drawback to assigning colors to users is that you tend to run out quickly: Do those users carry their bubble colors across the entire workspace? If they do, in a company of more than ten or so people, you end up with repeats, and threads where everyone will be the same or similar colors. Conversely, if colors are assigned dynamically per thread, it will be confusing switching context and having the same person appear in different colors!
If I were designing something like this, I'd look into other axes on which to vary chat bubbles to promote differentiation. Avatars are a reliable source of high-entropy variance, so maybe you could utilize them in a novel way. It could even be a generating a combination of colors using a scheme similar to the old iTunes album cover color matching.
Anyway, it's an exciting product, and I'm looking forward to seeing where it goes!
Thanks for clarifying. Maybe I'm just cranky today (very likely – Old Man Yells At Cloud), but I'd love to see a black and white subdued mode for emoticons as a user preference, it would help with the stimulation if focus is one of the central tenets of this product.
IRC is very different from teams. IRC is a public server and each channel could have 100s of members which leads to an unmanageable firehose.
Are you sure the same problem is also applicable to teams which are going to be much smaller than an irc channel and wouldn't be as busy as IRC? A private channel with a subset of team members wouldn't be the same as a public irc channel.
(I work at Quill). We've found threading to work really well with teams as small as 3. (2, probably not.) In professional contexts, conversations tend to be about specific topics -- someone posts a GitHub issue, bug report, feature discussion, etc, vs say a more social conversation that is less structured.
It's a way to keep track of the conversations you're having instead of a stream of consciousness (with multiple conversations interleaved) that is often times what people find in a channel. Once you shift to using threads, you sort of unlock a lot of things: revisiting old conversations via search, restarting conversations becomes trivial (all the context is right there!), managing your notifications (per conversation instead of per message now), quickly catching up on what you missed vs. sifting through hundreds of messages.
We're mostly solving for teams bigger than 3, but, we think it's really important that it does scale down to small teams.
> We've found threading to work really well with teams as small as 3. (2, probably not.) I
For what it's worth, my company is (unfortunately) very chat-heavy, and I use threads in two person conversations fairly often. Sometimes conversations branch off of other conversations.
Sure, I'm not just talking about participants in a conversation either (with the possibility of a wider audience). Even in DMs, I use threads plenty. Sometimes someone asks multiple questions not realizing that they'll branch off significantly, and threads are a tidy way to address that. I don't see why habits relevant to a DM wouldn't generalize to teams of that size too (in which case you're always DMing).
How does it work as a knowledge base? I like the idea that, like Notion, it has a hierarchy (both the explicit team hierarchy, and enforced threading within each subteam). I could see each team's feed becoming a stream of ad-hoc documentation for each of their user stories etc. If you can make a search experience that's more like Slack than Notion, that would be really powerful.
Separately, I'll agree that busy colors in a UI will limit adoption (particularly for anyone in enterprise or startups with a strong visual-design culture). You don't want Quill to clash with the visual work people are doing. Perhaps having the ability to have multiple "color intensity" themes, and a more muted scheme as an option, would let you expand your audience.
Good luck! Plenty of these tools but it looks like you're pushing the boundaries!
I used MS Teams at work, which already has this "thread-first" method of communication.
MS Teams is garbage overall. But the threaded-only chat style is actually kind of nice. It's easy to keep conversation threads in order, and people tend to veer less into off-topic banter. Plus I can just keep IRC and Discord open in the background for banter.
(I work at Quill.) Quill definitely has some similarities to a forum/message board in that it's slightly more structured -- but it's very much chat at it's core.
What we've found is when a group gets large and/or complex enough, they end up graduating to creating a team and using the channels/threads model.
I noticed the job postings you had open were for platform devs working with the Swift/Kotlin rather than Web stuff. Does that mean that you’ve built native apps for each platform?
(I work at Quill.) Of course! We take your privacy and security very seriously. Your regular conversations are absolutely yours -- your messages by default are encrypted in transit and at rest.
For user's that want extra security, we plan on offering e2e encryption for direct messages and groups (and maybe eventually channels). There are some tradeoffs with e2e encryption including scalability, search, history, and just the ergonomics of using it, which is why we call out that distinction specifically.
(But, we can see how current wording may be a but obtuse -- we'll tweak it.)
(you can also set per-channel and per-thread notification settings — so you can turn it down, or turn it up.)