As somebody who is often said to be right in the age bracket who should like things like these, I think in most cases I'd prefer email over this.
This is why: friction is not always a bad thing. Having to print out that mail twice before putting it into the envelope stops you from sending stupid stuff – it would just not be worth the effort, or you'd reconsider before you bring it to the mail. This means also friction saves you from reading a lot of unconsidered, badly worded and meaningless words, people would just easily write off their chest if it was frictionless.
The lack of friction in messengers is great for friends, family and loved ones – but I'd rather have work collegues either see me in person, call me, open a ticket or write me a nicely worded mail than chatting me up using a messenger at work. This is mostly due to the fact that many people can't keep messengers strictly work related. If you send five mails in a row because you always "forgot something", you look like an idiot. If you do the same in a messenger you will just come away as beeing casual. And the other side ends up having to filter through that mess. The energy you save by the lack of friction is payed by the other side.
I have a weird observation about the friction of e-mail. I think a high percentage of the friction comes from having to think up a subject. It seems that step, if required, forces some extra thought. It changes things a bit if you don't enforce subjects.
yes to this a 1000 times! It's amazing how our familiarity with certain interfaces changes our behaviour too. Anything that resembles a chat box and a "hit enter to send" encourages chat like behaviour. No matter whether it's threaded or otherwise. Interfaces like Jira or other software management tools which have ceremony involved before actually creating a task encourage people to think through things fully before hitting create.
I'm a huge advocate of async work especially in remote teams. Every real time chat about an importan decision has felt chaotic as people type message after message adding details and leaving out others which causes this long back and forth between people. The end result is always a mess leaving it to someone to go through it again and summarize information.
Messaging is just a bad format for focused conversations. Ceremony and friction are, like you say, a good thing. The physical parallel to this is sending in a request for a meeting with some details as opposed to just walking up to someone to chat with an idea you just had.
Not to say messaging is bad for everything. But it's definitely not good for calm, slow, focused conversations.
I'd pay for a slack add-on that gave my folks "message tokens". If they used a token it would send a message to me and then, as soon as I replied, if would open a 3 minute window for us to correspond. Then the window would close and the convo would be over. 3 tokens per day per employee. would cut down on the annoying stuff.
Am I missing something here? It talks about focus but has an extremely busy UI with colors and icons in your face all the time. Maybe it's better to actually use it than see the screenshots?
(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 had the same reaction. It may be misleading so I'd suggest if the primary selling point is better focus, not to have the first screenshot be so jarring (I couldn't even count how many different colors there are, etc.). It actually looks worse than my average slack situation (which is pretty bad ...).
I’ve been using this tool with a 10 person team and it’s -awesome-
I love the focus and clarity it brings to our work. And I am so glad to have a much better sense of peace while working at my computer than when I’ve used other tools for collaboration.
Sorry to be that guy but there are two big players in the chat industry, and this page does nothing to convince me that this product is superior. There are lots of smaller competitors, including Zulip and Twist, that already do what they claim to be their innovation. There's no product, just an "opportunity" to give your email to someone you've never heard of.
There were always big players in the Chat Industry, AOL, MSN, ICQ, Mig33, Yahoo Chat, GChat, Wave (oh the nostalgia), Hangouts, Skype, Lync and now there's Slack, Teams.
But communication is essential to humans so there'll always be space to do more, or doing more by doing less. I really welcome the competition in this space.
At first I loved slack, now I have a love/hate relationship with it. I'm sure I could easily be swayed with a more performant product focused on basics and good integration with other services.
At the risk of sounding like that bloke who wrote about how he wants to be playing offense, not defense, when it comes to communication, this is what I tell people I work with:
Important/Urgent: Call me or come find me
Important/Not Urgent: Tell me when we next talk, or email me
Unimportant/Urgent: Hover by my desk, or message me. If I'm not dealing with more important things, I might see it in time.
Unimportant/Not Urgent: Bring it up when we next see each other, or email me.
The only things I want making a noise and interrupting me is calls on my phone, the doorbell, my egg-timer and my smoke alarm.
(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 :)
It's beyond me that the culture at my current company doesn't understand this concept, so a few months into my tenure here, I took matters into my own hands and turned do-not-disturb on in my Slack and informed my team.
It was pretty vindicating to see multiple staff engineers follow my lead haha; when you get to a certain level of responsibility, the volume of Slack pings from people who need something from you makes it impossible to do any focused work.
The real problem here is that my co doesn't use email for things that aren't time-sensitive; avoiding email means removing the async channel, so my only option was to convert Slack to async.
The recent switch to remote has been challenging though, since there's no pressure valve of "come by my desk if it's time-sensitive". Slack's DnD mode has a "notify Anyway" option, but I've found that only higher-ups are comfortable using it, even though my status says "please feel free to notify".
We - fully remote team - made the switch from Slack to Twist about 2 years ago and really like Twist. Anybody here that uses Quill and used Twist can share a bit more about how these two differ?
Early user here. This has been great. It is hard to overstate the difference it makes to not be bombarded by random messages with constant fear of missing out on important conversations.
I'm a sucker for good design and your product looks quite sleek and beautiful, so if I was starting a company tomorrow, I might consider giving it a try. (As others mentioned, it does look a tad bit overwhelming).
What concerns me about whether Quill could succeed is: why would I choose this over Slack?
The whole 'threading' part could be accomplished via better onboarding and policy around Slack usage, and at the last startup I worked on, we were diligent about threading conversations on different topics already.
Is this a bet that tailoring the app around that 'threading' use-case and further encouraging its enforcement will be enough of a marginal improvement to take some market share, or is there more that's new here?
Also, what about those fun channels where you just chat and ramble with your colleagues about stuff outside of work hours? Would someone still need Slack for that, or would you have very large groups of DMs?
On top of my own company's, I'm constantly signed in to 21 Slack workspaces mostly belonging to clients, and the endless notifications are starting to become a real problem, particularly when people use @channel or @here all the time. Add into that the Slack's notification sounds are some of the most grating noises to hit my ears since Skype's. If I'm concentrating on a complex task and Slack starts going off I come very close to throwing my laptop out the window.
That can work for some slacks and some channels. But with others, not so much. When you're being paid to pay attention to client needs, there's only so much you can get away with.
But Slack still creates the expectation of immediacy in a way that other tools don't. Handling the same number of clients via email is a whole different experience. And Slack makes it very hard for people to filter out noise.
To my mind, Slack is to virtual work what open offices are to physical collaboration. They can be used well, but the default is a continuous drain on attention.
Is this mac only? Are there plans for PC, Desktop, apps? The website /feels/ very mac-centric which is why I am assuming and that feels like a disastrous mistake if its the case.
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.) 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.)
Looks interesting! I'll echo some other comments about the visual noise. From what I can see, each person has their own color and it is stable across contexts. It's a curious design solution. There are certainly some things gained from this - some sort of visual familiarity of names. But it makes using color for other purposes a lot more difficult, and I'm not sure it's a worthy tradeoff.
I'm also really curious how you'll handle End-to-End Encryption. The only good alternative in this space is Keybase, and even their UX has some ways to go. Do you plan to use MLS?
I think you're confusing the implementation of threads with the feature itself. Emails (and mailing lists), forums, reddit, HN, etc has shown us that threads are great. IMO they make discussions less ephemeral which is a good thing for slower communication methods. So hopefully the use of this tool is less "chatty" and less stream-of-consciousness.
I haven't used Quill, but judging from the screenshots, the implementation looks nearly identical to Slack's. So when they say "everything is a thread", it seems safe to assume they mean "we like Slack threads so much that we made our entire app behave like them". I'm not here arguing against the concept of nested reply structures in all cases.
how will the API work for developers? Personally I think the attention Slack put into their API is the reason it is so popular and will continue to own the space until there is a competitor with their api/bot building abilities.
Haven't used it but what I like from the features is that it combines Slack and Discord (with the voice rooms, that's currently (now that we are a forced remote company) a bit annoying that we have to use third party tools just to add this voice channel functionality to Slack.
You're right but in this case, I don't think your criticism is relevant to why they mentioned "IRC". Maybe I misread their webpage but it sounds like they're criticizing IRC. The full blurb immediately after "We grew up using IRC" is about "message fatigue" and "pain of having to skim thousands of messages":
>We grew up using IRC. We’re a team of engineers and designers that hit message fatigue. We’ve felt the pain of having to skim thousands of messages, and we’re building Quill to solve it.
So it's like they're actually saying, "We grew up using IRC and know all its faults really well and we're trying to fix it."
I know in an ideal world developers would make their software free as in speech, but most of the time that translates to free as in beer, which means getting paid nothing. Paid proprietary services don’t meet ideals but they tend to provide good support for business customers who choose to use them.
I'm well aware of the dynamics of money in a capitalistic society. Especially for companies like this one who have taken funding and not launched a product yet.
My annoyance was them touting "we grew up using IRC" and then taking none of the hacker ethos from it. I'm not saying they have to abandon profit entirely, but I would like to have seen some openness in their protocols. Some mention of launching an open API. But nothing.
Let's project forward a little using lessons from the past : This is a company, that has taken funding, has not launched a product, and is presumably not profitable. So if they run out of cash they're going to say to their investors, we have run out of money, and the investors are going to say what are your assets?
- The code
- A huge database of private conversations
Can you see why I'm not rushing to put all my private conversations in there?
I think you should call it QwertyQuill. Better suits the colour scheme, tone of the copy, product, market etc.
the logo should be a keyboard button with a quill on it.
(as you know) This is a very competitive market. You should lean into being the good-times-vibe-work-chat-app choice, be genuinely counter-culture, I don't mean put a gay flag on your social media profile. Get those eco-groups (the weird ones) using your app, get alt-right groups (not the ones that have killed people) using your app, fandoms, femdoms etc. Be proud of it, broadcast it, make sure you are the weird chat app people.
This is why: friction is not always a bad thing. Having to print out that mail twice before putting it into the envelope stops you from sending stupid stuff – it would just not be worth the effort, or you'd reconsider before you bring it to the mail. This means also friction saves you from reading a lot of unconsidered, badly worded and meaningless words, people would just easily write off their chest if it was frictionless.
The lack of friction in messengers is great for friends, family and loved ones – but I'd rather have work collegues either see me in person, call me, open a ticket or write me a nicely worded mail than chatting me up using a messenger at work. This is mostly due to the fact that many people can't keep messengers strictly work related. If you send five mails in a row because you always "forgot something", you look like an idiot. If you do the same in a messenger you will just come away as beeing casual. And the other side ends up having to filter through that mess. The energy you save by the lack of friction is payed by the other side.