Comm Lab Web: probablyGonna

For my comm lab web class, we finished the course working exclusively with Ruby and Sinatra.  The learning curve was particularly high, and I spent a lot of time wrestling with getting my apps working on Heroku and on my MacBook Air, since there were a lot of subtle changes that had to be made to get the apps working on each.  But I got my Ruby, Sinatra, Postgres, and permissions straightened out on my laptop, and now I can do Shotgun development, which is fantastic because it’s pretty much real-time building of code.  Heroku takes some interpretation of cryptic error messages and symptoms to diagnose how to get things going, but it’s so nice to operate from the console — they have some hotshit engineers there.

So here was my pitch for my final project, probablyGonna.

Like, you might be, “I’m probably gonna go dancing this Saturday in Adams Morgan, so if anyone’s in the area…”  Or, “I’m probably gonna go hiking some weekend, is anyone possibly down?”  The person who opens the ProbablyGonna item is the pioneer of fun.  But the pioneer always needs the validators, the next few who make the event a “go”.  Then everyone else piles on.  But you need the initial sparks, and you need to nurture the kindling until it catches fire.

The thing is, with events, most people don’t plan well in advance.  Facebook has events and our email gets spammed with e-vites, but really, don’t you just end up at 4PM on Friday or Saturday wondering what the hell you really want to do?

Most plans happen at the last minute.  Some even happen on the fly, when you’re in the area.  Who has enough active friends on Foursquare to use it to locate a place nearby to go?  Who checks in regularly on Foursquare?

It’d be nice if someone puts out an open invite for friends (or even strangers) to converge on one spot — at their own leisure.  This also gives context to a location’s events during a specific time.  Look, there are these parties going on at this venue; once you get there of course, the parties dissolve into one mass of people enjoying the location. (it would be nice to have a site where you could do wrap-ups of how cool a party was the night before and what cool stories happened that you just HAVE to tell)

I want to do this because I hate when people blow their Friday and Saturday nights not knowing where the fun is.  I want to do this because I think it’d be cool to have a job where you just ensure that people attend one kickass party that they’ll talk about forever.

So with ProbablyGonna, you just need to enter in a rough when/where/activity entry, and see if others will join.

I’m also thinking there’ll be reputations, developed over time, with how reliable someone is for actually making an event happen after declaring it on ProbablyGonna.  That is, if someone posts 5 invites but bails on all 5, he’ll get a 0% reputation, whereas someone who’s solid will signal to others that it’s safe to make the trek to that venue because the host is definitely going to have made it happen.

The problem with my app was that my physical computing project ended up dominating my life, and I also ran into some last-minute deployment issues.  For instance, I found a great gem, Chronic, that does interpretation of human time (this Friday, next weekend, etc.) into database-readable time.  But on Heroku, they use the latest version of Ruby, 1.9.2, and Chronic was only compatible with Ruby 1.8.7, which was what I used for local development.  So I learned how to deploy to an older version of Ruby on Heroku.  I also had some problems setting up a one-to-many or many-to-many relationship in my database.  I wasted a lot of time on that.  I also couldn’t figure out how to build a proper authentication system for users when they log in — it’s one of the weakest points of my knowledge for web site development, making sure users are who they say they are and making sure their passwords are safe.

The result was that I gave what I thought was a horrible demo of the app in class.  A lot of features didn’t work, and there was far less to show than I had hoped in terms of what the idea could do.  I built it out so that you could easily create an event, for people to probably attend, and then you could easily browse different time scales or events for what you wanted.  But that was about it.  Sure, that’s all the idea is, but I could tell the demo did not resonate as well as it did when I explained the concept behind it.  So I really dropped the ball in executing the simplicity of the idea.

That really troubled me, particularly since I spent the rest of the night all-nighting an attempt to save my failed phys-comp project.  I felt like I was having major problems condensing a simple idea into simple execution, something that would really grab a hold of people instantly.  I’m hoping I just didn’t get enough time to spend on it, and that some mending later will make it more appealing, and my familiarity with it will help me reduce extraneous elements.

Anyway, you can demo the probablyGonna site if you like, over at Heroku.

Here are some screenshots.  I’m taking a break from coding over the Christmas holiday, and am hoping I can implement the site better in my spare time next semester.  I’m also probably gonna work with classmates Phil and Federico on something very similar, matching people to learn their respective skills over coffee, on the NYU campus.

I got some good feedback during the presentation, which indicated that people really liked the idea.  People did not like the name probablyGonna, because they felt it was too uncertain.  Would the originator of an event actually show up if he organized it?  What if you could set a threshold for whether an event will happen, like if it gets over 5 people?  I responded that I felt almost any originator will actually attend his own event, but I guess I could see that if people just started throwing out events onto the site, maybe it’d just get spammy but not deliver.  I think my original idea for this, however, was that people would earn reputations.  Did the person bail on events, particularly his own?  Did people show up when they said they would?  Did someone’s events really pack a punch and get good after-action reviews?  Reputation here, as will be for most sites in the future, will be key towards making the site efficient and usable.  I guess what I wanted to be wary of was making the site too ordered and structured — that product already exists, and it’s called Google Calendar.  But when we’re not in offices and not planning well in advance, how do we actually decide what we’re going to do?  We wait until almost the day of, or the morning of, to weed out the worse options and then settle on the best one.  We also might just want to grab lunch with whomever’s around, and probablyGonna can do that, too.

  • Jeffrey Johnson

    Great project.  Thought I’d throw out a few questions/suggestions of my own.  Hopefully they aren’t rehashes of other suggestions.  

    So would you only rate reliability for the originator or for everyone who responds?  If the originator is flaky, but you have a few solids scheduled to show up, it would still be a good chance at good time.  

    Have you thought about giving the user an option on how likely they are to show up?  Something along the lines of definitely/probably/maybe. 

    What about reputations for the locations?  Users doing their after-action review could rate not only the originator, but the location. 

    Would the posts be open to everyone or would their be some sort of social circles?  For example, an originator could limit the post to his immediate circle of friends or expand it to plus one (friend of a friend), plus two (friend of a friend of a friend), etc.  

    If you did have all that data, have you thought about some sort of algorithm to predict the likelihood of a good time.  Based on the reputation of the likely participants, the location, and how well the event fit a user’s profile, it could decide how well a fit the event is for a user.  One way to rate it would be a percentage “likelihood of a good time”.  Scores that met a certain threshold could notify the user of the event via text/email/twitter/(whatever).  Alternatively (or additionally), you could use the data to score events with predictive badges.  Some possibilities might be “bring cab fare, you’re getting drunk” or “likely sausage fest”.

  • Ben Turner

    Hey!  Thanks for writing.  I’m taking a break right now but will probably work on pG a bit when I get back to NYC.  The Ruby was making my head hurt.

    The “definitely/probably/maybe” designation is a good one.  This was mentioned in one of the questions raised in class, but you put it a little better.  I like how one could use it to firm up plan details.  Will add that for sure!

    Reputations for locations…would definitely love that.  Great idea!  I’d been thinking that I wish there were a way to rate one’s night based on the location.  Like, had a great time there, this was the crazy stuff I saw happen there, would go there again.

    The posts I was thinking would be as customizable as I could figure out how to code for.  Maybe make it either public, or add individuals.  I’d have to work on it longer to make groups of people (like Google+’s circles).  But it should definitely have this eventually.

    An algorithm for likelihood of a good time…you hit the ultimate endpoint of it right on the head!  I want to figure out (and reward) the most promising events, and quantify whether it was valid or not.  The “predictive badges”?  Brilliant.  That’d be the most interesting thing to code, I’ll get on it.

    Great suggestions, thanks!

  • Pingback: Dynamic Web Dev & Mobile Web: Final Project Proposals? « Ben Turner's Blog()