Slack Shoehorns Threaded Messages into Its Interface
The group messaging and collaboration service Slack has at long last added threaded messages. Slack lets companies, groups, and individuals set up free or paid teams that function as private communications hubs. Conversations in teams center around channels, which theoretically correspond to a particular subject or sub-group.
(Last year, I wrote a pair of books documenting Slack: “Take Control of Slack Basics” and “Take Control of Slack Admin.”)
But channels can quickly become overwhelming, either because of talkative people, too many members relative to the breadth of topics discussed, or overlapping projects. In some cases, messages flood the channel, and you would have to spend all your waking hours scrolling and reading to keep up. In others, the interleaving of unrelated conversations and replies makes it hard for anyone in the channel to follow a particular discussion.
Until now, Slack’s general advice — and mine — was to split a channel that was too busy or too interleaved into additional separate channels, each with a stricter focus. But that imposes a different burden, as it requires people switching among multiple channels to keep up. Context switching is neurologically hard, and also makes it more likely someone will miss valuable information that’s not specifically called out to them.
Slack tried to drive down the middle of this conundrum with its new threading feature. The company chose to embed threads within a channel rather than, say, indenting and collapsing them, a common feature in discussion boards and email programs. When you want to interact in a thread, you take your “sidebar” discussion into a literal interface sidebar or use a new team-wide Threads view.
You can add a thread to any message in Slack’s desktop or Web apps by hovering over a message and clicking the new Start a Thread button; in the mobile app, press and hold a message and choose Start a Thread. This opens a Thread sidebar in the desktop or Web apps, or slides over into a Thread view in the mobile app.
The Thread view shows all the messages in the thread and lets you type a reply, with an option to select an Also Send to #channelname checkbox. If you check that box, Slack displays the first message and the one you just posted in the channel.
As threads start appearing in a channel, you’ll see avatars beneath a message and a count, like “5 replies”, that’s also a link. Click or tap the link, and you’re dropped into the Thread view. When viewing a thread, if you lose your place in the main channel’s discussion, you can hover over the first message in the thread or any replies in the channel and click the Open in Channel button. This scrolls you to the appropriate spot in the channel and highlights the
threaded message. Clicking or tapping a message that has been sent back to the channel is also a quick way to open the thread.
Unfortunately, it’s easy to miss the fact that a message has become the start of a thread. To make it simpler to find threads, Slack added an All Threads link at the top of the team sidebar. The label changes to New Threads when any thread in which you’ve participated has a new reply. Click or tap All Threads, and you can scroll through your threads — but unlike the rest of Slack, which has older messages scroll from bottom to top and out of view, the Threads view shows
threads with the newest replies on the top. This sorting switch and the split between channels and All Threads aren’t entirely comfortable.
If you want to stop getting notified about a thread, you can hover over the first message in the sequence, click the Show Message Actions (…) button (or hold down on the message on mobile), and choose Unfollow This Thread.
Threads can help prevent digressions, keep project-based discussions together, and segregate anything that not everyone in a channel needs to be in on while still keeping it available to anyone who is interested. If you’re in a Slack team with overloaded channels, encouraging people to shunt related conversations into threads might offer a good solution. You might think of them as temporary sub-channels instead of threads, if that makes it easier to visualize their use.
The best use for threads that I’ve found is a form of “topic necromancy,” as one colleague described it. Before threading, if you wanted to reference a message that was further back in the channel, you had to use the Share command, which let you post a message and include the quoted and referenced message. (The necromancy refers to reviving that message from the “dead” part of the channel.)
However, with threads, you can instead use Start a Thread to reply to the old message, and then a new thread forms referencing that person and anyone else you might @-mention in your reply. This approach leaves the old message in place, but Slack notifies participants about the new thread. When you’re done discussing the old topic, you can post a reply that shares it back to the channel if it’s relevant.
Do I love this approach to threading? Not so far. Although I’m still getting used to how to use threads, it’s still too easy to just continue with the quick back-and-forth in a channel. We’ll see if users manage to change their habits. That said, I understand that Slack had to compromise between trying to engineer threads into a linear chat interface while not making it so unfamiliar that users require retraining.
While this moves Slack closer to a discussion forum approach, in which everything is a thread instead of an eternally scrolling chat, it still retains its distinct identity and informality. We’ll see how Slack’s team continues to improve on this over time.
This is good news. One of the reasons I've refused to use Slack is its completely unthreaded nature. Without threading and a "mark as read" feature, it makes catching up with previous discussions and ensuring that you haven't missed anything (for example, after being out on vacation for a couple of weeks) effectively impossible.
Now if they'd just fix the *truly* idiotic requirement to having to create a completely separate login/password/interface for every team you're a part of, I might consider giving it another look, though I still don't understand how it's an improvement over more-traditional discussion forums such as Google Groups.
You don't have to create a separate login and password for every team. Yes, you're prompted to do so, but nothing stops you from using the same one for each team.
Slack and Google Groups are just different. Slack is interactive and real-time chat, whereas Google Groups is basically a mailing list with a Web interface.
I know I can use the same password for each team, but why do I even have to go through the trouble of setting up a separate account for each of those teams, then manually switching between the websites for those teams, and then within the channels within each of those teams, just to see if there's anything new to read? It's an incredibly poorly-thought-out design.
Re. the difference with Groups, I still don't get it: I get messages sent to a Google Group in effectively real-time (or near enough that it makes no difference), it's threaded, it shows up in my email client so I don't have to have a separate page or app open to read it, I can apply filters, and so on. It's just a far better experience all around.
It would be nice to have a way to unify a message feed across channels in a single team. You can already do that with DMs: there's a most-recent DMs view in mobile.
But across teams is problematic. Team messages are owned by the team owner, and Slack gives all the power to that person or people. Providing a unified view across teams could breach security and retention policies.
Perhaps teams should have the ability to check a box to allow it, but as a general structural point, I don't think it makes sense.
This is hilarious: A properly-threaded discussion about how Slack doesn't have proper thread support.
There is no irony property in the HTML DOM model, unfortunately!