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?

First rule of Start-Up Weekend: it’s not a conference! It’s not like you go in and get lectured by CEOs older and richer than you. Start-up Weekend is hands-on from day one, and rightly so, because you only have a couple hours to pitch and vote on ideas before breaking into teams and building products and companies. In that way, Start-Up Weekend is *nothing* like Start-Up School—both were time well spent, but vastly different.

Here’s a very stream-of-consciousness play-by-play of how the weekend went for me:

Day One: The Pitch

Friday around 6:00 people started rolling in, and by 7:00 the room was at capacity and tropically hot. The first round of pitches lasted maybe an hour. One by one people stood and presented their ideas. Most of them rambled but there were some great presenters in the crowd. We raised our hands in support of each idea as it was presented. I pitched a crowd-sourced translations service for web apps; didn’t get many votes, which was sort of a bummer because I could really use that tool for my current project, TennisMatch.

After all ideas had been pitched, those with the most votes were selected for a second round of discussion with some time allotted for Q&A. Since my idea didn’t make it to the second round, I listened for a project that might have similarities with some other concepts I had been mulling over. My ears perked up when Jay Cuthrell pitched an idea for a location-aware mobile app that would show you what’s going on near you right now. Of all the product ideas I heard that night, Jay’s idea (originally called SPACE or PAGE or AGAPE or something similarly acronymious) had the right combination of real-time, location-aware, mobile, and fun that I was looking for.

Also in the second round, Mike Schinkel pitched an idea for an event aggregation service, something like an Eventful–MeetUp hybrid. His idea sounded similar enough to Jay’s that the crowd suggested the ideas be merged into a super event aggregation and discovery tool. So, we went with it.

With the pitching complete, teams started forming. I joined Jay and Mike; my role on the team was technical, as I had a couple years hands-on experience building web apps in Django. We were also joined by a graphic designer, a lawyer, a copywriter, a tester, a marketer, and some serial entrepreneurs that I’ll neglect to name here in the interest of time—with the exception of Justin Dawkins—no relation to Richard, by the way—whom I will mention because he’s awesome .

Our team convened in an ATDC conference room and began brainstorming about how the product should work. Justin and I seemed to have the same vision for a web app with a very clean UI that simply showed you what was happening near you right now, with kayak.com–style filters. Mike was less interested in the “now” component and more interested in the ability to discover MeetUp–style planned events, so we explored a concept where the central UI metaphor consisted of two prominent tabs: “Now” and “Later”. Not arriving at any consensus that evening, we decided to sleep on it and come back in the morning with ideas and name suggestions.

Day Two: The Rush

Still no consensus. After a few hours of trying to design a product that appealed to both Mike and Jay, we decided to rethink the merger that had brought the two ideas together, and instead approach it from the perspective of Mike’s concept as an API upon which Jay’s idea could be built. Once we recast the problem like that, it was simply a matter of splitting into teams and building two pretty straight-forward products. Justin, Jay, and I branched off and started working on the mobile, location-aware, real-time event discovery tool, while Mike and the rest of the team started designing the ultimate event aggregation service, complete with handy API.

We decided an iPhone app was too ambitious for a weekend project, but that a mobile-friendly web site was doable. We were behind schedule, having only begun to design our product after lunch on Saturday. Fortunately, Jay is handy with Linux and got our Linode server instance up and running lickity split, complete with Django and MySQL. And I was able to reuse the Django deployment process and work-flow that I had designed for TennisMatch—more details to come in a future post. So we were up and running with the necessary infrastructure by that afternoon.

I’m not usually very creative when it comes to naming things, but inspiration hit as I was playing with combinations of the words “go” and “mobile”: Gomodo! It’s short, rolls off the tongue, sounds interesting, is unique and brandable, and conjures a logo idea featuring a Komodo dragon. So we went with it. Jay doodled a dragon and our mascot was born—fortunately, he chose an obnoxious shade of orange to replace the dragon’s original obnoxious shade of brown, which had something of a poop patina.

Gomodo.com was taken, but not in use—have I mentioned how much I hate domain squatters?—so we opted for something fun and short: gomodo.me. We figured that if we were wildly successful and made it into the vernacular as a verb (a la “just google it”), that it’d be sort of catchy to say “gomodo me!”

In technical terms, the app is pretty simple: we have two models, Event and Venue, populated by an ingestor daemon that fetches event data from event aggregation sites like Mike’s EventTank and Eventful, and searched by a simple web front-end that figures out where you are using GeoIP or Javascript location services. I worked on the app all night, more out of excitement than necessity, and had it mostly working by 6:00 AM.

Day Three: The Pitch, Part Deux

The first real test of Gomodo’s utility was when I pulled out my iPhone early Sunday morning, and it told me about a running group meeting for breakfast and a run at Piedmont Park at 7:00 AM—so it successfully got the time and location and showed me something relevant! Much like a director must feel when he attends his film’s premier, there’s an inescapable feeling of pride and accomplishment when you’re first able to actually use the software that you’ve written. And if for nothing else, Start-Up Weekend was worth giving up my weekend for that reason alone.

The rest of the day we spent polishing details and working on the UI—and on our presentation. Justin took the lead on UI design and did a bang-up job making something simple and easy with the limited time and tools at our disposal. Jay took the lead on our presentation, and did a fantastic job of keeping it short and sweet.

Teams were feverishly racing to finish their products before presentations, and since ours was mostly done I took some time to stroll around and see what everyone was working on. Some folks had gotten wind of the fact that I worked at Twitter and that I knew Django, so I got to help a few teams with Twitter integration, Django arcana, and the vagaries of DNS.

As evening rolled around, all the teams reconvened and we launched into presentations. The energy in the room was electric, and it was really fun seeing what everyone had come up with. Almost all of the teams had working demos, and many had minimum viable products with which they could start attracting real customers. At least half of the companies had changed names, and a few had changed product ideas altogether.

Jay presented Gomodo—you can check out the slide deck here. I was pretty nervous because the presentation included a live demo—but not just Jay demonstrating the app on his phone. No, he gave everyone the URL and let them try it themselves, so we had about 50 visits to the site during the presentation. It was super exciting watching the logs and seeing the app serve up events just like it was supposed to!

The Aftermath

Something like 15 companies and alpha-quality products came out of Start-Up Weekend 3. Many of them are still alive. Gomodo hummed along with occasional care-and-feeding for a few months. Sadly, our main source of event data (Eventful) seems to have wised up and started prohibiting full event dumps, so Gomodo doesn’t return useful results any more. Neither Jay nor Justin nor I have had the time to invest in looking for other sources of event data because we’re all busy with our own start-ups and consulting gigs. I still think Gomodo is a great proof-of-concept for a real-time, location-aware, mobile event discovery app, and I’d love to pick it back up once things settle down with TennisMatch.

Thanks to Lance Weatherby and ATDC for organizing and hosting such a valuable event. It’s great to know that the Atlanta start-up scene is alive and well. With the connections I’ve made over the weekend, I have no doubt that Atlanta is the best place to bring TennisMatch to life.

[Ed note: this post is rather late. But hey, I'm starting a company, so the blog's pretty low priority.]