Evite has firmly entrenched itself as the party planning platform. Throwing a party in two weeks or holding a BBQ next weekend? Make an evite and invite a bunch of guests. Let them RSVP. One person makes a plan and announces it to everyone else to accept or not. This system works for a big number of social functions. But what about the even greater number of informal social functions like dinner between friends on a Friday night?

Planypus aims to serve that category. The Evite plan announcement model flops here. Friends plan together as equals, negotiating any or all of who, what, when, where. They negotiate over phone, email or SMS in an imperfect and time consuming process. How do you put everyone onto the same page with Evite efficiency? Skobee made the first prominent attempt, but came up short on follow through, making only made a rough sketch of great ideas. Planypus took that sketch and refined it into an elegant, useful system.

The co-founders Yan and Alex were nice enough to allow me a preview of Planypus. (The beta launches early November.) The key page that distinguishes Planypus is the plan page. Rather than presenting a plan as a finalized event to be merely RSVPed, Planypus makes it a democratic process. With everything in a single view, and a liberal application of AJAX, participants can comment, vote on all major aspects of the plan, suggest alternatives, and invite others. (Links also allow you to make restaurant reservations and buy tickets.) The plan page is an interactive dashboard that's easy to use and natural.

One person crafts a plan and invites a bunch of friends. The planypus emails out a link to the plan. Each recipient can then participate and elect how to receive notifications about actions in the plan. Aside from email and SMS, RSS and iCal subscription or integration with web portal home pages or the likes of Google calendar are also options. Right now the communication is one way; interaction via SMS is in the works. Once someone finalizes the plan, the details are broadcast to everyone.

Plan initiators can draw on restaurant lists and event feeds for ideas. One click on the plan icon next to a listing brings up the plan page. Skobee was isolated in this regard.

I haven't had the opportunity to put the planypus in practice with a gathering of my friends yet, although last week presented a perfect case for the system. One of my friends planned a dinner, sending out an invitation to two dozen people. Through successive emails he had to poll interest on three different dates, announce the results, then poll interest again before making reservations. It was a lot of work for him and a lot of being in the dark for the rest of us, and we're not even done yet. Planypus would have added a lot of value here. I'll plan a dinner soon with it and let you all know how it goes.

Planypus' plan making ideas are no doubt solid. The question is how willing people are to change their old ways of doing things and who wins the pie. No one remembers the second or third competitors in Evite's space. Likely that will be the case in plan making too. Renkoo better hussle, the Planypus guys are agile with Ruby!

As a bonus for reading this post, I'm including a graphic I made for understanding the evite user base and its growth dynamics.

Popularity: 13% [?]

[11/17//2006 - version 2 adds BusyTonight, Submate, Vibely]

After reading the TechCrunch article on nascent activities-centered websites, I decided to take my own look at the activities space. I wound up examining nineteen ventures by the end. Their aims may seem too desparate to lump together in one examination. However, in the abstract, they all attempt to catalyze social interaction, and, technically, there are only a dozen or so features that they all try to implement in various combinations. For your visual stimulation, I've produced two graphics, one a venn-type diagram attempting to categorize each service and the other a feature set chart. My notes on the services should be read in order as later ones will build on earlier ones. I consider their major focus, ie their marketing position and the way they are actually used, not the subset of possibilities rarely or never tapped.
Read the rest of this entry »

Popularity: 9% [?]

Having examined a trio of recent entrants Pinger, Jyngle, and 3Jam in the multperson mobile communication space, I've decided to return to one of their forefathers, the colorfully named Dodgeball. This ambitious early experiment in social communication from NYC eventually caught the eye of Google, which gobbled it up May 2005 for an undisclosed sum. With the stability and support afforded by the acquistion, one would expect Dodgeball to be in the stratosphere with traffic today. In fact, the service still hugs close to the ground.

Why's it grounded? Dodgeball aspires to be too many things at once and before hooking an audience: it's okay to evolve new features with user momentum behind it but it's deadly to be muddled at the starting line. Friendster+Yelp+3Jam they want to be, unused they is. The probability p of each concept getting off the ground is low enough. Joint probability pFxpYxp3 ~ 0.

If we take the mobile-centric view, 3Jam by comparison is easy and open. If 3Jam's chatroom archetype isn't already embedded in your mind from IRC or Yahoo Chat experience, it is a design pattern with a good fighting chance with the uninitiated. Spinning new conversations is easy and unregistered recipients are full participants: I can include anyone with a phone number immediately in a convo and there's a decent chance they'll figure out how to participate.

Read the rest of this entry »

Popularity: 6% [?]

Next up is 3Jam. Since I reviewed Pinger previously, and the two services share similar ambitions and grapple the similar issues, each exploiting server side processing to foster group communication over the existing crude infrastructure, I'll bring up points of comparison as I go along.

3Jam, like Pinger, threads conversations and distributes messages to all parties in a group chat. Unlike Pinger, 3Jam traffics in SMS only, not voice. 3Jam's mobile interface to the service is an intuitive command set. Contacts can be added either through the web interface or from the phone. Unlike Pinger or Jyngle, 3Jam's web UI is only good for contact management and contains no messaging functionality, demonstrating focus on mobile to mobile communication.

3Jam Convos are Virtual Chatrooms

If you wanna think in OOP terms, a 3Jam (group chat) is like a server side object that gets instantiated when a registered user texts 3Jam (43526) with a list of contacts. The contacts are individual entries like "Mark Cuban" or "Michael Arrington" or a group like "HotOrNotGuys." Contacts are entered through the web interface or the phone. So an SMS sent to 43526 with "Text Mark Michael HotorNotGuys" will create a chat object with those guys (and myself) as participants. 3Jam will reply with an SMS informing that a "3Jam started with MarkC MichaelA JamesH and JimY." (The object would also have me in the chat_starter attribute.)

In a clever bit of engineering, that chat opening SMS message is sent from a five digit SMS shortcode distinct from 43526. Replying to that distinct short code broadcasts the SMS to everyone else in the convo. This system allows a 3Jammer to be in more than one chat group! The 3Jam convo is the primary object, not the message as it would be in email or Pinger; it is essentially a virtual private chatroom (think IRC or AIM).

Read the rest of this entry »

Popularity: 6% [?]