There's this thing that happens in text messages, online chats—really, any text-based, real-time communication: the lag.
Because real-time isn't always actually real-time—or same-time, anyway—people often move through written conversations at different paces. Which means very often we end up having two or more conversations, subconversations, sidenote conversations, and so on—all on top of one another. (It happens even more frequently if you're group texting or chatting with more than one person at a time.) So sometimes people use lists to keep separate conversational tracks separate, or brackets to indicate an aside. These may not be the most elegant ways to navigate a conversation, but they mostly work.
Yet I've always wanted a chat platform that could visually represent the side conversations that spring out of a main thread. How might a "sidechat within a chat" functionality even work? What would it look like? Bolded text for one train of thought, normal for the other? Extra-tiny font for asides?
There has to be a better way.
At least, that's what Slack CEO Stewart Butterfield thinks, and Butterfield is fixated on just this sort of problem—the kind people don't even realize is a problem until they're presented with an intuitive solution. Slack, you may have heard by now, is the still-fledgling but already popular collaborative chat client that's setting out to destroy email.
If there's one thing that differentiates Slack from the way we've come to expect chat clients to work in the past 20 years, Butterfield told me, it's that it is "more intelligent." But the reason so many people love it—yes, the tech team uses it here at The Atlantic and, yes, we're mildly obsessed with it—is because it feels more intuitive. It acts the way you would expect a chat client to act without having to articulate what it is you want it to do. (Paste in a link, for example, and a headline, photo, and teaser show up in the chat itself—so you don't have to click the link to find out what it is.)
So it comes as no surprise to hear that Butterfield and his team are planning to introduce the exact kind of feature that would enable side conversations and otherwise provide clarity when a written conversation progresses at different speeds for various participants.
In Slack, this will look a lot like a reply-thread does on Twitter, he said. So instead of having to clutter up a conversation with parentheses or other clunky tools, you can create a new branch of discussion that's still within the larger feed. "We are going to add a feature," Butterfield says, "that's message replies pretty much the exact way that Twitter does them, but not necessarily requiring the @ sign... for when you want to explicitly make a connection between two different points." (Twitter users will know this as a "Twitter canoe.") The idea is to clarify any given thread of conversation as it's happening—especially if it happens over a long-ish period of time—but it also keeps a more organized thread of what happened for posterity, he says.
And all this—organizing rivulet threads in a single chat—is something of a synecdoche for a larger split in text-based communication that's been happening for the past decade or so. People aren't just chatting with various friends and colleagues in separate chat windows, but across a variety of platforms. "It takes a certain level of intimacy to SMS someone," Butterfield says. "There's some group of friends that, if I'm going to get in touch with them, it's going to be a Facebook message, others it's a Twitter message, others it's email, at work it's Slack and on and on and on."
Slack's vision for side conversations within a single chat seems like it makes sense for the platform—and there may be better alternatives for simpler formats like SMS, for instance. Though, actually, in the larger history of chat, the in-chat distinction of threads and channels is a throwback. The first online chatting of the early 1990s happened in simple threaded discussion boards. In other words, making sense of what chat has turned into—and where it's going—may first require a return to what made it work in the first place.