Pages

Wednesday, June 3, 2009

And the winner is...

And the winner of the Android G2 phone is...   Leonard Lin!

First apologies for not posting this sooner.  I did "pick" a winner at Monday at 9pm, just took me 48 hours to tell you who it was.

Secondly, thank you to everyone who submitted ideas.  I got about 20 serious submissions, and a few jokey ones, through comments on the blog post, tweets, and emails.  I thought many were great.  I hope you all do go forth and develop them.

The reason I picked Leonard's idea:
  • Bet on the team.  Leonard is a rockstar developer, fantastic track record...  Every project he touches thrives.
  • I think the app he described is extremely interesting.  Reminded me of Dash Navigation, a company I've found fascinating for a long time.  The concept of crowd-sourcing data about the commute (both historical and real-time) leads to many, many interesting derivative apps.  (For instance with Dash, real-time rerouting around traffic jams, determining speed traps, etc.)
  • I like the focus on public transport.  Good for the economy and environment.
  • Leonard's idea, as you see below, was well thought out. 
Darius Roberts was definitely my runner up.  Darius, I hope perhaps you can collaborate with Leonard (and I'll intro you guys.)  I think that "rideshare yenta" is an awesome, complementary idea.  I ought to be able to register an intent to get from San Francisco to Palo Alto, and the app connects me with the right commuter (I can express preferences about whether I'm willing to drive, split gas money, etc.) 
Leonard, I'll be in touch regarding getting you the goods.  Thanks, and I can't wait until you build something.

Finally, just to be explicit... This "contest" wasn't endorsed or sponsored by Google.  I just wanted to give the phone to a good home.  Thanks!

Leonard's idea:


So, here's the basic idea about creating a *great* Transit app (one that has features that no one else has really bothered with yet).

I'd start w/ SF for v1 b/c I have all the transit data (511.org gives full dumps) and because BART and NextMuni give full realtime data, so you can basically get to the minute predictions, but the idea would be to create something that could load any GTFS data, or ping against GMaps' routing but add some additional features.

I don't have a name/domain name yet, so if you have any bright ideas on that...

Backend:
* REST API for data
* Proxy for realtime data

Routing:
* Caching or full local DB of stops, routes, tiles
* Collecting data on favorite routes, stops, destinations
* Reverse chronological history of searched (maybe even taken) routes
* Easy reversals or routes, destinations

Route Choosing:
* visually lay out alternative routes
* pull in realtime data
* show more info on arrivals time, transfers

Reminders/Alarms/Affordances:
* Reminders for last return trip if you're out on the town
* Alarms for longer commuter trips (geoloc/time elapsed, absolute time)
* "First time" / "lost" affordances - what are the previous stops, where are you now, etc.

Nearby View:
* See nearby stops, specifically when they're coming.
This is especially useful if you know that multiple routes can take you to the same place... (I can take the 26, 14/49, or BART to get back home)


I whipped up a couple super simple wires (about 5min each, but hopefully they give somewhat of an idea)

Integration w/ Glympse would be interesting (I was glad that someone's been working on that since that is something I'd been complaining about for the past year :)

Anyway, if that's successful, the next thing that would be of interest to tackle (v2) is NYC - b/c of the Subway/undergroundness of it all and lack of any "real time" data, the NYC version would be focused on developing crowdsourcing capabilities - ie, when you head into and out of a Subway station, perhaps the ability to mark in/out times and aggregating and processing that data.  I haven't fully thought through the algorithms, but I bet just by when people are leaving at previous stops you can find out if you're looking at a 5m or 25m wait...

Once this sort of algorithm is perfected, if it'll work in NYC, it'll work (better!) for any city that has aboveground transit (buses) w/ schedules but no exact times...