Hacker News Reader

Comment by ferdowsi | Hacker News Reader

Is there really no better design for "aside" conversations than this? People lean on Slack threads too much, leading to a confused flow of conversation that makes it extremely difficult to piece together how the discussion was ended or resolved.

View on HN

I’m always surprised by how practically every single opinion regarding personal communication is the opposite in hacker news to the mainstream opinion of my “real life” circles.

Use of social networks, slack, emojis, messaging apps, sync vs async communication…

Its not a criticism of any kind, mind you, it’s just very surprising to me.

I would be a bit slower on the hasty generalizations. I’m here on hacker news and I love using threads and am happy they’re coming to Discord there’s also multiple comments below this saying the same thing.

The lack of threads is something that made me not use Discord before (before they had the replies).

There was simply no way to know who someone is replying to, or part of which of the multiple conversations in the channel is that message a part of

That's because it was designed to be a real time chat. When you're having a group conversation, there are no threads. You just keep track in your head what the topics are and who said them and then figure out how the next sentence applies.

Discord was modeled after this interaction (and IRC, which was modeled after this interaction).

None of the Discord servers/channels I'm involved in are that active so that sort of real time chat aspect is much less significant.

I agree with that you're saying but it's also not the only way one interacts with Discord. I might only visit a server once a week and try and catch up on the messages posted in that time.

In IRL chat you have physical modifiers to indicate threading though (volume, posture, gaze).

Seems like threading but with a UI option to collapse to a flat presentation suits both sides?

That might be the initial model, but it's not the current model. People use Discord for far more than real time chat. It's effectively replaced forums for many communities. While real time chat is still important, it's not the only use case.

When you're having a large-group "stream of conversation" in meatspace (in the lobby of convention hall, say), subgroups within the conversation will break off temporarily to form smaller "huddles" that step slightly away from the group, focusing on one-another rather than the group, to have a temporary "sidebar" conversation.

Content from a "sidebar" conversation is usually taken far enough away from the larger group that it's not bothersome/interrupting the topic of the larger group; but—unlike a whispered aside—these temporary sidebar conversations are still public conversations, and they leak enough signal to the larger group that if someone in the larger group focused on the sidebar conversation, they could pick up the general topic of what's being discussed, and choose to join the sidebar discussion themselves.

Hey, that's threads!

It's not the same thing though - the sidebar usually gradually merges back into the main conversation, and certainly you can't resume a sidebar from a week ago and have it magically reemerge with the same group of people.

Nah, lots of us here love threads. Threads was one of the reasons our large private friends-only Slack server didn't move to Discord. This has reignited that conversation, as we like Discord more for certain things, and threads were one of the things holding us back.

The difference is we just aren't really saying anything.

I have some issues with Slack threads but use them a lot, appreciate them, and so far haven't seen a better solution (even in this thread).

HN always presents a lot of reactionary positions to anything.

I kind of feel similar. I already thought that the Replies feature was a better compromise for a chat room than Slack's threads (which I hated because so much conversation would just "disappear" from channels only to find out it was still happening in a thread from days or weeks before), but I'm also in several Discords that migrated from Slack and I know how many of my friends have been complaining that they missed Slack style threads for whatever reason.

I'm going to give this a shot a bit: an in depth reading of this blog post has given me some appreciation that Discord is trying to keep it better than Slack's. They have moderation mentioned front and center, so that feels good to me that they kept it strongly in mind. I also like that they will be visible in the channel list as "sub-channels" and that they will auto-archive with a time limit (defaulting to 24 hours to start). Those two things do try to address things I disliked about Slack's implementation, so I'm hopeful to give it a shot.

Maybe my remaining criticism here is I think I'd prefer the default time limit to be something smaller and related more directly to activity. Maybe something like "after an hour or maybe two hours of silence" to keep them to "active conversation sidebars" only. I also don't like that currently changing the time limit is a Level 2 Boost server feature if I wanted to explore options on smaller servers I control/moderate. On smaller servers your main option is just to turn them off entirely. (Though I sort of understand that it is a Level 2 Boost because from their perspective servers are going to want to increase the time limit as a perk. I wonder if they could make it free to decrease it, if it's not a "perk".)

> They have moderation mentioned front and center, so that feels good to me that they kept it strongly in mind.

What's annoying about this is it was sprung, default on, with no warning. I'm a mod (not the owner) of a server that got them, and we weren't given the permissions to disable them from @everyone, only the admin can do that at first. And he's not currently been on because of time zone differences. Which means it's just an easy open vector for someone to come in an raid and just cause chaos. They should've had it off by default, at least for a few days to let server owners experiment and play around with it.

They've given that choice to servers that are labeled "Community Servers" at least (giving them until mid-August before it is forced on by default) which will help some of the largest servers, but yes they maybe should have given that a wider option to the medium/smaller servers too.

Yep, we're a small server (~2700) that just randomly had it turned on. We've currently got about 10, just from random members thinking to test if they can create them. 10 that we can't delete. Thankfully nobody has tried to abuse it by naming any anything offensive, or mass creating them yet. Hopefully they won't before the admin gets back on when he wakes up.

2700 users? I'd classify that as more than a "small" or a "medium" server myself. That's definitely in the range where setting it as a "Community Server" could be beneficial for a lot of other reasons.

What are these reasons? It's a pretty niche server, focusing on a specific language family, and I doubt the admin or the other moderators would really want it to be super available. We also have probably <20 really active users, which is probably why I would consider it small.

Yeah, 20 active users would still feel small. That's fair. I probably wouldn't recommend a Community Server with only 20 active users.

To answer your question, though: Community Servers get a couple more security and safety features that help with moderation. They get a "Welcome Screen" for helping new users not feel quite so lost on first joining the server. Discord is generally better about notifying Community Servers of upcoming updates and slower about rolling out new features to them (such as Threads).

https://support.discord.com/hc/en-us/articles/360047132851-E...

Of all the chat apps I have used, Mattermost's implementation of threads/replies [0] has felt the most natural. That said, all implementations I've tried leave something to be desired.

[0]: https://docs.mattermost.com/messaging/organizing-conversatio...

That looks identical to Slack's implementation to my eyes. If you don't mind sharing, what did you like better?

Slack threads don’t (or at least, didn’t; it’s been a couple years) show in the main message feed, they show when you expand the thread into the sidebar. In the feed, it shows the original message with an “n replies” text below it.

In Mattermost, new replies show as normal messages in your feed with a bit of context for what they’re replying to, and clicking on the context expands the full thread in a sidebar.

I find the Mattermost implementation more ergonomic because you can read replies without expanding the whole thread every time, and stale threads will get bumped by new messages.

Ah interesting. I believe Slack does the former thing (displays as k replies) but not the latter. Thanks.

You might not have noticed but your link goes to the new design (in beta) of collapsed threads which are much more similar to Slack's and I think this has caused some confusion in this thread

It's worth noting that the design you prefer isn't being deprecated; Slack-style threads are being added as a user display option.

Oops, yeah. Looks like there are not really any docs for the existing (better) system: https://docs.mattermost.com/messaging/sending-receiving-mess...

Slack has the option to "reply in main channel" as well as have it show up in the thread. This allows people to surface something important in the thread that should also be in the parent channel.

I have liked Zulip's threads (they call them "topics") best: https://zulip.com/help/about-streams-and-topics

I always found Zulip too thread-focused. I think the Slack implementation is a nice balance.

In Zulip you can make a "general" topic thread, and then move messages to a new topic when you feel like it's warranted. The normal stream (channel) view shows all threads simultaneously. There's also a view of all streams combined. The UI would be more confusing if Zulip had to display un-threaded messages, because then you wouldn't have a way to view only un-threaded messages without threads being interspersed. If you use the "general" topic method you can just focus on that.

I think we need to scrap the concept of a channel, and everything should be a thread instead.

You can categorize/tag threads (why not automatically based on groups of users) and they can show up as a feed similar on HN/SO/Reddit, but in a sidebar so you can easily swap between them.

If you're imagining how that would look, no need to look further than an email client. The advantage of it being threads with tags/categories is that it makes it easy to move one thread from one category/tag to another (for example moving the conversation from DEV to SRE) without loosing context/history.

Then there's no aside conversation, because everything is an aside.

I love having threads on Slack, but I absolutely hate that it always open in the right corner, instead of showing in the center. I always have to drag the border all the way to the left so it's not just a small column on the side

I agree. The Slack thread UX is not ideal, but the flow of conversation is so much better than it was pre-threads. I always end up closing the side bar and navigating to the thread in the "Threads" view. They should make it easier to maximize a thread.

At least this UX of Discord's makes it easy to do that: the article points out that opening the thread from the list below a channel will open it in the main chat view instead of the sidebar. At least from the article it does seem that Discord was paying attention to flaws in Slack's UX.

I genuinely hadn't realised you could resize threads to be wider and found it really annoying how narrow they were. I don't think I'd noticed any visual cues you could resize them either (assuming the cues exist).

Wait how?!?!? This always bothers me but I can't drag the border!! Edit: OMG YOU CAN DRAG THE BORDER I WAS JUST DOING IT WRONG SOMEHOW

The only other type of thread design I know of is Reddit-style threads in a chat app. The negative of that is that the threads cannot be directly incorporated into chat itself after creation because they become things of their own, just like Reddit threads, but the positive is massive: threads are entities of their own and they can be infinitely nested and referred to indefinitely into the future.

An example of this design is Aether. (Disclosure: I work on this, aether.app) If you have issues with Slack-style threads or curious about alternative solutions to this issue, it might be worth checking out.

Zulip is the only decent implementations of threaded chat I could find, although it’s solution to “aside” conversations is that all conversations are “aside” (or none are), since you are using channels. It does wonders for discoverability though

I feel like threads are a solution to having an enormous continuous channel. Zulip solves this by not having an enormous continous channel. I think it makes sense to have topic-oriented discussion threads, and then have discussion within those threads all in the same continuous stream.

Doist's Twist thing is the "real thing".

Forum threads/email convos for focused convos, stream-y chat otherwise. Mixing the two ends up being really messy IMO.

It does mean you gotta kinda move around, but I would kill for Slack to implement an "inbox-y" form of conversations, so I can actually keep track of open loops

Reply on news.ycombinator.com