Take a look at Zulip, if you're not already familiar with it. They nailed threaded chat in a way I haven't seen anywhere else, with the possible exception of Zephyr.
That similarity is very much not an accident - Zulip is based on Zephyr. (I forget whether that's true technically or just in terms of inspiration, but the latter is definitely true.)
Inspiration very much so, code and technology not at all. (I'm one of the Zulip developers.)
I have enough friends who've hacked on Zephyr, and they tend to get such a look of horror on their faces when talking about that protocol and codebase, that I'm pretty sure that was the right approach for us. :)
It really was/is a fantastic social product, though.
So this is not Zulip-specific, but I am trying to figure out what it is that they supposedly nailed about threaded chat, and getting really annoyed by the experience of it. It really highlights a number of general issues I have with the way all apps in this space try to sell themselves.
TL;DR: If you proudly state on your features page that you have "First class threading on top of everything you could want from real-time chat", then give a good explanation of what makes it first-class and why it works so well. Don't assume that everyone who visits your page has already tried out a dozen other modern chat programs and therefore is familiar with all the UI idioms. I don't know if that is arrogance or naivety, but it's wrong either way.
So my goal is a quick overview of the UI and a feeling for the UX. How it all comes together, how it flows when used. I have no interest to first install it and explore it to do so, and that would require having conversations and discussions in it, and I don't feel like convincing a bunch of friends to give this a try and make them invest time in testing it.
First, the Zulip webpage (which has a broken back-button.. great). The features page proudly opens with "First class threading on top of everything you could want from real-time chat."[0] Great, so how does that work? No explanation, it just lists all the other features - the "everything you could want" bit - without every going into detail on the conversational threading UX.
Yeah, those features all look nice, but you're not telling me why the threading is better than elsewhere.
Ok, well, if I search on YouTube for videos, I'll probably find a video of some nerd trying to convince me Zulip is better than anything else and why. Although I don't like it when companies lean on that kind of "implicit crowdsourcing", so I am already slightly annoyed.
Turns out that there isn't much on YT either.
A lightning talk by one of the devs, talking about organisational structure and culture of an open source project[1]. Great, but not what I need right now; the fifteen second overview of the UI (with an implicit "you're already familiar with this stuff" tone) does little to help me.
What else? A series on how to install Zulip[2]. No discussion about the interface itself, so same problem. The remaining search results are either promotion videos of other chat platforms, or screen captures of people complaining about bugs in the Zulip app[3]. So far, the latter are the closest thing to something informative: at least it shows the app in action, and since the narration explains what is broken, you also hear what the expected behaviour is. Still not very useful.
As a last resort, I dive into the (extensive) documentation[4]. It lists everything you might want to do with the chat ("how to set up an account", "how to edit a message") and is very extensive. That is great in itself, since it lets people find answers to these specific problems, but I am still missing a good explanation of how it all comes together.
Ok, fine, I'll dig through the docs myself and try to get a picture of the app. Clicking through it I see a lot of things that are familiar from other chat apps. But when it comes to the threading, I find only a few spread-out paragraphs somewhat explaining how Zulip organises its chats:
> Zulip is a group chat app. Its most distinctive characteristic is that conversation within an organization is divided into “streams” and further subdivided into “topics”, so that much finer-grained conversations are possible than with IRC or other chat tools. [4]
> Messages in Zulip are organized into streams and topics. Streams are similar to chatrooms, IRC channels, and email lists in that they determine who receives the message. Each conversation in a stream also has a topic, which plays the role of the subject line of an email (though topics are usually shorter, e.g. "logo" or "logo design", not "feedback on the new logo design?") in that it organizes messages into threads. [5]
> In each stream, messages are sorted by topics. Topics are specific, fine-grained subjects that fit with the overall subject of the stream that they're sent to. Topics ensure sequential messages about the same thing are threaded together, allowing for better reception for users. [6]
As far as I can tell, that's it.
COME ON! So the whole thing is that you have a conversational tree that where for each topic ("streams"), you can have one extra sub-topic ("topics")? So it's essentially just forums and subfora, but with different user interface based on chat idioms?
And I can figure this out due to previous familiarity with this kind of software. I guarantee you that this is still pretty mystifying to people less tech-savvy.
OK, so now I wonder: how to start a topic then? I see pages on how to start a stream, how about topic? There is one about editing one[7], or viewing all messages about a specific topic[8]. Nothing about starting a topic though.
There has to be one, of course, since you can't use this software without this. Dig through the docs long enough, and you'll find it under "Send a new stream message"[9]. No hint that this has anything to do with starting a new topic.
What?! Why is it called "sending a new message"? I guess that in Zulip-idioms, a new message is different from replying to another message; the latter implicitly subscribing to that particular topic. Starting a new message in a stream means defining a new topic.
So in order to figure out Zulip-logic, I must already be familiar with Zulip-logic?! WHAT THE HELL PEOPLE. You cannot expect this from new users. Just call "sending a new message" what it is: starting a new topic. Or make an alias that forwards from one page to another, like merged pages on WikiPedia, or whatever, but not this.
Zulip looks like a great app, but this is ridiculous.
More developers/designers should read https://news.ycombinator.com/item?id=6429848 and ask themselves whenever they develop/design something: "would this way of explaining intimidate the elderly, or anyone else who is less comfortable with technology than me into thinking they are too stupid to use computers?" If you're not somewhat thinking about that, you're doing it wrong.
I'm one of the original developers of Zulip. The long comment I'm replying to is a somewhat rant-y critique of Zulip, but it's basically valid. We honestly have a hard time communicating the stream/topic paradigm, even though in some sense it's just forum/subfora.
I encourage vanderZwan and others to come to https://chat.zulip.org/# to talk to us. We're real people. We like the app we've developed, but we know it's far from perfect, and we especially know that our marketing could use some constructive feedback.
No need to downplay it: it is a rant, and I knew it when I wrote it, but I wanted to get across the raw frustration that I think a lot of users feel. Plus, as I said at the beginning, it was more to illustrate a more general problem.
You have my respect for taking it in stride and listening to the critique! I already mentioned it does look like a good app, and based on skimming through that lightning talk (not to mention this reply by you), the dev community behind it looks open too.
Doesn't Slack support at least one 'level' of replies? I've come back to busy channels to find replies/discussion in the right pane to earlier messages.
Just to check that we are on the same page: when we say "threaded conversation", be we both mean the ability to visually group the messages in the conversation in hierarchical trees[0], right? Because I don't recall ever seeing anything like that in Slack, nor being taught how to do that. I haven't used it in quite a while though.
Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation. There is a huge difference between something being theoretically possible for expert users, or intuitively embedded it in the mode of conversation.
Mind you, I'm not saying that hierarchical trees are a panacea. I think human conversation is much more similar to the way branching and merging works in distributed version control systems, but I can't see how one would easily make a conversational UI based on that.
I think that Slack's implementation of threaded conversations is severely lacking. It's easy to miss that someone has replied to you and started a thread, and it's hard to find existing threads, you have to scroll up in history and try and find it.
Slack threads almost got me fired. Long story short: I requested leave for a couple of days, by posting in the #leave channel on the company slack, as is company policy. A week later I was sick and took a day off work, that same day my boss (who works remote to the rest of the team and was separate to my supervisor) denied my request, by posting a reply and starting a thread on slack. The next day, when I came into work, my Slack was filled with unread messages and comments. I checked my DMs, and just marked everything else as read since it was mostly people mentioning @channel. Because I only checked my DMs I missed this reply to my request for leave. I only discovered the day before I was due to leave that my request was denied, when one of my colleagues mentioned it to me. I then proceeded to go on leave, which work wasn't too pleased about. I was basically asked to resign, which I did because I was planning on leaving the company anyway.
There were a few problems caused by slack here (as well as my own failings).
Slack has too much noise. After only a day away, I was inundated with messages, and no easy way to sort the wheat from the chaff. This can be mitigated by good management and company policy. Using @channel to chat about your plans for the weekend is not appropriate use of @channel.
With email, I would've gotten a nice list of unread emails, which I could scan down and automatically delete the ones I don't care about, and I would've clearly seen the email titled "re: leave request". Slack DMs also lack any kind of subjects or threads, so it's not possible to send leave requests to a manager with a subject heading, if company policy required me to put leave requests in as a DM, it would sit in a single threaded conversation with my boss along with all my other messages.
I think that slack is a good tool if used properly and appropriately. @all or @here should be used sparingly, and for important messages. DMs shouldn't be used for anything serious. It shouldn't be company policy to have a #leave channel where you post your leave requests, where your boss can publicly second guess your requests for sick leave. It all comes down to how its used. Slack is great if I need to send a quick message to a colleague, or if I need to post a comment in a channel where a prompt reply isn't required.
Slack does try to advertise itself as an alternative to email though, which is BS. It's a tool to use beside email. It's just like how IRC didn't replace email, neither did Skype.
First that a company would deny a vacation request. Vacation is something that you schedule with your manager, not that you ask for. It's vacation. Of course you're going. You're just letting them know when.
Second that anybody would try to have such an obvious email conversation over slack. That doesn't seem like a good use for group chat. For the reason you describe.
It never struck me as good company policy to have all leave requests in a public channel visible to all company employees.
I think that this solution came about because the company had a very strong dislike of email for some reason. All support was done using Intercom.io, rather than email and all company communications were done in Slack. I don't think I sent a single email in the 2 years I worked there.
Being able to create a direct message with a topic would've been the ideal solution, which is literally what email is.
It's perfectly normal for companies to deny leave requests, especially smaller ones.
One common reason is simply boots on the ground, can't have everyone take the same day off. Deadlines, if I ask for leave in the last week before a deadline.
You might be thinking from a programming perspective but imagine your whole support team taking the same two weeks off.
There are loads of reasonable, practical, reasons to deny leave. Every company policy in the UK will usually clearly state don't book tickets, etc. until approval.
Vaguely related, here in the UK there are people who get a bad rep for being greedy by blocking off certain holiday before other people as soon as the year gets 'released' e.g. booking every Friday before a bank holiday Monday off, so no-one else can. Good managers will shut down that behaviour and tell them they can only take X of them, as it causes resentments.
That proves Slack doesn't work in the same sense that it proves frictionless professional interaction doesn't work.
As in, it proves nothing except it's an ineffective product for what humans use it for. Same as we'd say if Slack wasn't around -- "is IRC really the best way for us to do this?"
No. Of course not. We don't live in a best-case world, however; the relevant question to their user base is "are we helping you more than alternatives?", and for an entrepreneurial community like HN, "what does the better solution that solves the same problem look like?"
What’s the point of an office break room if people aren’t there constantly?
It still allows you to have a conversation with the people who are there, with the added benefit of people who walk in later can still see it and chime in.
Coming back later really doesn't help (at least for me). Because chats are interspersed throughout, you can't really follow/search anything.