~clay

We’re building a social utility for tennis players, called TennisMatch. I say social utility and not social network because, while we have all the features you’d expect from a social network, our goal is to help tennis players make new connections and set up tennis matches—to be useful, and not just fun.

One of the most useful features we offer, not surprisingly, is messaging—the ability for one tennis player to contact another, whether to schedule a match, get directions to a court, find a tournament partner, or just to say hello. When we designed our messaging platform, our first instinct was to follow the de facto standard Inbox convention, found in nearly all email clients and replicated on social networks like Facebook and LinkedIn.

But the Inbox model leaves some things to be desired. You’d like to be able to group related messages into conversations, and not have to bother with cumbersome folder-oriented organizational schemes. Google delivered innovative solutions to these problems when they built Gmail: messages are threaded into conversations automatically, and Google-powered search makes it easy to find archived emails.

So we refined our design for TennisMatch messaging, adopting a conversation-based approach. Because it was simpler to implement at the time, we opted not to include a subject field in our database, and to only allow one conversation per pair of users. We planned to go back and add support for subjects and multiple conversations in subsequent iterations, but after looking at what we had built, we realized that our messaging feature worked very much like the iPhone’s Messages app, which has no subjects and only one conversation per contact. Since that design seems to work well on the iPhone, we decided to explore that paradigm a bit.

Text messages are limited to 160 characters. Adding a subject line to each message would eat into the available message size, but I think there’s another reason the telco engineers who designed SMS opted not to support subjects: they just slow you down. There’s the obvious fact that typing on a mobile device isn’t speedy, but there’s also the cognitive burden of having to summarize what you’re about to say before you say it that makes it take longer to send a message with a subject line. And, since text messages are short enough as it is, there’s really no reason to summarize them with a subject.

Thinking about how tennis players would use messaging on TennisMatch, we suspected that most messages would be short and conversational, much like text messages. “Do you want to play today?” and “Sure, I’m free after work. I’ll reserve us a court at Piedmont Park” seemed like common use cases for our players. We couldn’t think of many examples of where having a subject line would make the message more meaningful. And without subject lines, it doesn’t make much sense to have multiple conversations going.

Like many other web apps, we send an email notification when a user receives a new message. If the user has given us their mobile number, we’ll also send them a text. That can be great for keeping on top of your inbox, but if you get engaged in a back-and-forth conversation with someone, all those notifications can be really annoying. That’s a situation I’ve sometimes found myself in with Twitter direct messages—I want to get a text when someone first DMs me, but not after every subsequent DM.

The solution seems straight-forward: if you’re not logged in to TennisMatch, we’ll send you a notification when someone sends you a message, but if you are logged in, we’ll just update the unread message count in the page header. As a convenience, if you happen to be on the conversations page when someone sends you a message, we’ll dynamically insert that message into the page. Likewise, we dynamically add any messages that you send to the page, too.

With those changes, our messaging interface started to look and feel a lot like chat—it’s real-time, conversation-based, subject-less message exchange. But it’s not exactly like chat. We don’t show a buddy list. We show whether the person you’re chatting with is online, but we don’t show when they’re typing.

Probably the biggest difference between our messaging system and chat is that on TennisMatch, you use the same interface to send someone a message regardless if they’re online or not. You don’t have to burn the cognitive energy to figure out whether someone is online before sending them a message, like you do on other sites. If I want to send a message to a friend on Facebook, for instance, I’ll first check to see if they’re online in the chat interface, and fall back to the message interface if not.

So we’ve arrived at a messaging design that’s something of a hybrid between asynchronous, Inbox-style messaging and synchronous, real-time chat. When we launched our site, we were curious whether users would understand our hybrid messaging paradigm. Now that we’ve had a chance to collect some empirical data, it looks like most people do understand it well enough for it to be useful. The most common source of confusion for new users is that when they’re composing a message, pressing enter is all it takes to send the message. So we see some conversations that start with nothing but a “Hi,”. But after that first surprise, users seem to learn how the interface works.

I’m curious what user experience designers think of our hybrid messaging approach. Are we asking for more trouble than it’s worth by conflating two well-understood concepts—Inbox messages and chat—or could our hybrid messaging model prove to be a smash hit?