Gustav’s Mindshare

The model that is quickly emerging as the de-facto model for location updates is the so called check-in model.

Contrary to the  always-on, automatically updating friend tracking model used by services like Google Latitude and Loopt, that has been prophesized and expected to take off for years,  the check-in model used by services such as Gowalla, Foursquare and MyTown lets a user manually and deliberately “check in” to an exact/discrete location and actively update friends and others about it.

You could argue that this is not really a new model at all, that it is in fact exactly what Dennis Crowley (now of Foursquare) did over SMS and Wap with his previous company Dodgeball (acquired by Google in May 2005). But for one reason or another, Google did nothing with Dodgeball and it seems like everyone went back to focussing on the prophecy of the always-on friend tracking model for the subsequent years.

Why haven’t the friend tracking services taken off?

• Until recently, you could argue that it was because there was not critical mass of technically capable devices to get the network started. With the adoption of GPS enabled iPhones, Androids, Blackberries and Nokias etc, that argument doesn’t hold anymore.
• That leaves the argument that people are simply not prepared to share their location with a bigger group of people, it’s too private. Well, the screaming adoption of these new check-in services, that are actually very public, prove that this was not true either.

To me, it is clear that it was the location model that was wrong. So what is the difference?

What the check-in model solves:

1. Privacy: With the tracking model, as soon as I friend someone, I will have to go through the mental exercise of thinking if I REALLY want to share all my future locations with this person, which is very hard to do since I don’t know what they will be doing in the future. Alternatively, I’ll have to set different resolutions on different people and remember to turn some or all of them off when I go certain places. The check-in model obviously solves this by way of the model itself, pushing an update is always a deliberate event.
2. Accuracy: It may seem intutive at first that location information doesn’t have to be very accurate to be useful, This also rhymes well with the fact that you expect people to be more concerned about their privacy the more accurate it is (the reason Google Latitude offers city level-only filters). In reality though, I find it to be totally the opposite. Actually, to be useful at all, the location information has to be super accurate, down to single meters and it has to include altitude. Looking at a dot on a map with an error of  +/-100 meters or so (which is best case, when you’re outside in GPS view) doesn’t tell me very much at all. I want to know if you’re in a ski slope, a particular café/pub or a department store and which floor  and shop of the department store you’re in. The technology to automatically deduce this with sensors and local directory services simply isn’t there yet, and won’t be for a long time.As low-tech as it may seem, the check-in services solve this in a beatiful way, by using the device’s sensors to present a list of adjacent exact/discrete and canonical locations and then letting the user do the “last mile” positioning manually, by choosing one of these. This beatifully solves the problem of getting infinite resolution in both x,y and z axis. It obviously requires a huge amount of discrete locations to check-in to, but as these services let’s you quickly create such locations, if you find yourself on the corner of Broadway and 5th and it doesn’t exist as a discrete location yet, you can simply create it.
3. Context: Even if the resolution deduced by the sensors would somehow be good enough. If I don’t know that particualar spot myself, an X on a map somewhere doesn’t tell me anything about where that person really is. Is it a hotel, café, store, ski slope etc? Of course, clever mapping to local directory services can attempt to solve some of this, but it will take a loooong time before they will automatically tell me that “Eric is at the skate board ramp in central park” (as opposed to him being at the ice rink 10 m north of it). Not to speak of the complete loss of  Z axes when you go into a 10 story building. The fact that the discrete locations are man made, (but still typed, making them machine readable) means that I get clear text context to that specific location apart from just it’s coordinates.
4. Update frequency: A constantly tracking service has the generic problem of not knowing when a friend of mine does something interesting or news worthy that I might want to know about (which is likely a tiny fraction of the time that I’m tracking him/her). That results in me constantly having to check the service and all my friend’s locations, making the likelihood of any actual serendipity extremely small. The model of deliberate updates solves this by it’s design and allows for both pushed updates to friends and posting to social networks.

As the fit with services such as Twitter and Facebook are so obvious, I’d expect to see some acquisitions fairly early in 2010

So I just returned from an awesome week in San Francisco where Anders, Ludvig and I demoed the first version of Spotify mobile on the HTC Magic Android device. We’ve worked very hard on this application for the last few weeks and are pretty pleased with the result. Using it on the trans-atlantic flight was a good test of the offline sync mode, really useful! 😀

I really like the HTC Magic (thanks for giving everyone a free device Google), it’s pretty clear that the form factor is everything when you compare it to the G1. It actually makes my iPhone feel just a little bit big…..

Spotify for Android at Google I/O

The event itself was huge fun. The party on the Wednesday was in true Google style with any and every geek interest represented + ofcourse, the sign of Google, lots of free food and drinks!

I probably don’t need to mention the Google Wave presentation to anyone, how can you have missed it? I would like to say however, that I think the general blogosphere has kind of missed the core of what it is (which is easily done, considering it took 1,5 hours just to demo all the different things it CAN do). But in one sentence, Google wave is about Centralized conversation objects, where everyone edits the same object, rather than the current distributed model, where everyone has local copies of conversations and edits (replies etc) to their individual copy. This basic paradigm difference allows for all of the rest of the features (realtime, simultaneous update, in message editing, collaboration etc). I actually think they should’ve stuck to just the core messaging use case for the demo, to not confuse it too much.

It’s a super ambitious project in itself, but what really blew me away was the fact that they are going after a federated solution right away (i.e. I can have my own Google Wave server), meaning there will be multiple copies of these conversation objects, that need to be kept in sync. I think it was crucial that they did, it just wouldn’t have worked to say that all future communication should be hosted by Google themselvers, but it does make it orders of magnitude more complex I would guess…..