How Location-Based Social Networking Should Work

I'm excited about the possibilities of location-based mobile services. By this I mean software services that take advantage of a user's physical location (determined by a GPS transponder in the phone or by geographic information transmitted from the phone to the mobile network) to provide current and pertinent information such as traffic, public transit data, local attractions and restaurant reviews, localized shopping, and, most importantly, localized advertising, all determined by the user's location. The ability to offer an advertiser an audience qualified by their actual current location would be of huge value.

But today, in 2007, most LBS applications suck. They're difficult to use, and require so much time and attention to sign up, set up and use that most casual users will never try. It's a chicken-or-egg dilemma, but without a growing and active userbase, an LBS will never become successful.

The Killer LBS App
Start with Dodgeball. Functionally, it's a good place to begin. It's under the nurturing care of Google, so there are plenty of possibilities for piggybacking onto existing services that already have userbases, like Gmail.

Right now, users of Dodgeball are required to 'check in' actively via SMS. For some phones without GPS functionality, this is the only way it could work. But let's look further forward into the future, and go ahead and add passive GPS-derived check-ins. No more typing "@local bar name" and waiting for a flurry of SMS messages to go out to all of your friends. Instead, just go to the bar, and if you've turned your visibility on, then your friends will know where you are. If they need to be reminded, then just click "Announce My Location", and let your phone's GPS service take care of the rest.

The next step would be to build a mashup of Dodgeball, Google Maps and Gmail Chat, so that all of the big LBS benefits are delivered seamlessly through one solution.

Let's move on to the illustration of what this could look like, to facilitate the explanation:

From a mobile device (or from a desktop, but for the full benefit of the mobile aspect, let's assume we're using a mobile device), the user accesses a list of friends. Each friend's location is being tracked and reported by the GPS component of their mobile device, and their location is logged on the list. An illustration:

By selecting the Map view, the same list of friends can be viewed visually, with each contact's location displayed on a map, as shown here:
And finally, by selecting a friend individually, their profile can be accessed, a call or SMS can be initiated, or directions to their location can be requested:

How Google Money Could Work

This is a follow-up to my previous post about how a web-based personal finance tracking solution could make life easier, as an improvement to the current state of Quicken, which is currently shackled to a desktop application.

I'm very deeply entrenched in Google's suite of online products; I use Gmail and Google Calendar extensively. I use Dodgeball and Google Voice Local Search and Google Earth and Sketchup, etc. I'm also very excited by the future prospects of Google Apps for location-free and collaborative document management. Generally, I find that as Google continues to add functionality and interoperability to their suite of online offerings, my life becomes easier to track and my personal information easier to maintain.

The one exception so far is my personal financial tracking, for which I use Quicken. A web-based version of such software, offered by Google and taking advantage of existing features in their other products, would be a useful way to manage my life.

Calendar products manage time, ensuring that I don't double book my schedule or miss a planned activity. Personal finance programs manage money, ensuring that I don't spend more than I budgeted or miss payment deadlines.

Spending time often means spending money, and many events in my time schedule directly correlate to events in my financial schedule. I schedule my time using one piece of software, and my money using another one. But why not mash them up?

Here's an illustration of what I mean:

How It Is
I call to schedule a haircut for next Thursday evening. After I've confirmed the appointment time, I create an event in Google Calendar, indicating the time and place. Now, if I want a fully accurate view of my upcoming transactions in Quicken, I'll need to remember when I get home a few hours from now that next Thursday, I'll be spending some money on a haircut. Unless I create a calendar event to remind me to enter the transaction (which would be a fantastically redundant waste of time), then I'll just have to remember, because Quicken is installed on my desktop computer at home.

How It Should Be
I call to schedule a haircut for next Thursday evening. After I've confirmed the appointment time, I create an event in Google Calendar, indicating the time, place, and expected cost. The end. It could look something like this: