Slack Overload: A Frustrated User Rant

by Matt Cholick

Slack introduced threading. I had such high hopes for this feature. But... it misses the mark and doesn't solve the problem that Slack creates.

First, some background:

Slack is not optional
I'm on a distributed team but, even when I haven't been, using Slack is a requirement.
People say important things in Slack
This shouldn't come as a surprise, but given a communication channel, people say important things. Since slack is not optional, people expect others to read the messages they write. This is a pretty reasonable perspective.
People say unimportant (to me) things in Slack
Again, no surprise here. Assuming what they're saying is relevant to the channel, it still might not be specifically relevant to me. In the context of a single team this is true, but it's even more applicable in a larger organization. Even after quickly leaving low-relevance channels and muting others, I still keep tabs on more than a dozen channels.

Taken together, all these things result in an information filtering problem. Across all these channels are a subset of messages that I do want to read, but any given message has no context. Over and over again, I have to evaluate and dismiss messages that I could have ignored. Context is critically missing.

For a contrasting example, every email message has a subject line. I can quickly evaluate any message and ignore those not important to me. To manage email further, one can do things like add filters or mute discussions. For example, my credit cards automatically send me an email for every transaction. I tag these emails and trigger a specific notification on my phone, so I know immediately any time my cards are charged. I archive an email immediately if it's a charge I'm expecting. That single tag provides complete context.

Managing email is a solved problem. Anyone who says otherwise hasn't put in the work to route and filter incoming information.

Email is, of course, not Slack. Chat requires different solutions. What's frustrating, though, is that other tools similar to Slack have solved (or at least helped to mitigate) the filtering problems they introduce. Flowdock is what I used before Slack (and no, Flowdock isn't a Slack clone: it came first). They built a workable solution to this problem years ago. Here's a screenshot:

Flowdock threading

The colored bar on the left gives enough context that the message flow can be chunked. At a glance, I can evaluate a given thread and dismiss it. In real-world usage, often the last several messages would be a single thread. This style of threading drastically reduced the problem of information overload; it facilitated quickly viewing a channel and categorizing entire blocks of messages as either dismissible or something to be read.

Slack's solution fails to solve the problem. It takes messages completely out of the channel body and thus will only be used on a small subset of any channel's messages. Once a team embraced Flowdock's threading, every single message had existing context or established a new one. Slack's threading doesn't support this, because a thread hides replies behind additional clicks.

With a different implementation, Slack could drastically reduce the amount of time I'm forced to spend reading and dismissing irrelevant information. I had such hopes that they would get threading right. Slack, please give me the context and tools I need to filter information.