Massive Earthquake Hammers China

A series of massive Earthquakes hammered China this morning, the largest of which registered 7.8 on the Richter scale.

How big is 7.8? The image below from my Earthquake map mashup shows that the 'rumble zone' (the area over which the quake could be felt) covered all of China.


There's been over a dozen after-shocks registering over 5, so the 'impact' zone is harder to view, but if you look at the 'Australia' tab they're only showing the largest quake which gives a better idea of its scale.

For comparisons sake the 'damage zone' (the area susceptible to severe damage) covers an area about the size of Ohio or Austria. In the image below it's represented by the darker red circle about the size of Thailand.


The humanitarian result of a quake of this size is predictable. You can read more about the effect of a quake of magnitude at Google News.

"Explore This Area" with Google Maps

Google Maps Australia are slowly rolling out a feature that let's you "Explore This Area", essentially a 'universal search' implementation for Google Maps.

When you search from the Australian implementation of Google Maps (http://maps.google.com.au/) the message in the screen shot below appears in the search results panel to the left of the map and displays pictures, videos, and community maps based on the current map location.

Clicking 'explore this area' overlays tiny geocoded image thumbnails onto the map as well as displaying arrays of photos, videos, and community maps that are found within the currently visible map boundary.



While this additional information is currently available only using the Australian map search, you can do a search anywhere in the world and see the same extended results.

A nice touch is that as you pan and zoom your map everything updates dynamically, adding, removing, and reordering the videos, pictures, and maps available based on the new map location. Very slick.

There's also a new 'drop down' array to the right of the search box which displays your 'saved locations' for easy access.

Find Your Way in WA with Google Maps

I hail from the small-town city that is Perth in Western Australia. If you were feeling generous you could say that Perth does not have a reputation as a fast moving, innovative city ready to embrace change. So it's great to see the local government embracing the future, the locals will now be able to schedule trips on the on-time, on-budget Mandurah rail link using Google Transit!


View Larger Map

It's actually really neat and I congratulate Transperth for being the first Australian transit authority to get involved with Google Transit. Nice one!

In related news, you can now add new places to Google Maps for any physical location in Australia (or New Zealand or the US). So if there's a local landmark, or a new business that doesn't appear on a Google map search you can go ahead and add it yourself.



Nice touch, and a good way to ensure visitors can always find a bus to catch to get home from a day's site seeing.

Android v iPhone: SDK Showdown

Apple responded to Google’s Android SDK gauntlet in some style last week when they released details on the much anticipated iPhone SDK. Is it a legitimate challenger? Let’s take a look.

Feature	Android	iPhone
SDK Cost	$0	$99 (to allow distribution)
Distribution Cost	$0	30% of the list price
Distribution Channel	Open	iTunes exclusive
Mashable Maps?	Yes	No
Location Services?	Per Hardware	GPS Pending
Accelerometer?	Yes	Yes
Multitouch?	No	Yes
3D Graphics Support	Yes	Advanced
Background Services	Yes	No
Application Interaction	Supported	Disabled
Native P2P Comms	GTalk	No
Actual Phones that Support the SDK	Q4 2008	4 million and counting

Free versus Really Not Free

A 30% cut of the list price? Even my agent would blanch at demanding that sort of cut. The $100 fee is just baffling. Why charge? I’d love to have a play with the SDK but I’m not convinced it’s 10 books worth of entertaining. I’m not writing mobile apps for profit so where is the return on my investment? It’s a system designed to provide a smooth distribution channel for approved 3rd party providers but it’s going to discourage those who are simply ‘iPhone curious’.

Android’s approach charges nothing to experiment and there’s no distribution cost. If one of my experiments turns into something people will pay for I won’t have to hand back a third of the price to Mountain View or Cupertino.

Foreground versus Background

Techcruch pointed out this gem in the iPhone docs. Your iPhone applications can only run in the foreground. If you switch away for any reason it will close. In the process of creating examples for my book on Android development I found that background services are one of the most exciting features of Android, albeit not the flashiest, so it’s very disappointing to see this explicitly disallowed on the iPhone.

Foreground only apps are great if you’re writing games (clearly the big target for Apple) but 90% of the time my mobile lives on my desk or in my pocket until it rings, flashes, or vibrates.

Background services let you create applications that extend this event driven model. Maybe it’s an app that keeps track of the football and vibrates the phone when your team scores, or maybe it changes the LED color when your team's ahead or behind. Maybe you write a service that sends your location to your friends so they always know where you’re at. This is the sort of thing that’ll make my mobile more useful not just more entertaining.

Interprocess Communication

The iPhone explicitly disallows communication between processes, to the extent that each application and all its data are completely sandboxed. There’re a lot of good security reasons to do this but Android manages to handle it without the sky falling. Then again, if your application is only allowed to operate in the foreground there’s not much point trying to communicate between two apps.

Native Map Support

Since the iPhone release Google Maps has been its most popular application. In Android I can write on-phone mashups, on the iPhone I can’t.

Bottom Line?

The iPhone SDK is a way for game and mobile developers to write the same sorts of programs as they always have but on the shiniest new device on the block. That’s great if you want a 3D, accelerometer controlled version of breakout, or to play Spore on your mobile, but it doesn’t bring anything new to the party. Well, apart from an extortionate 30% licensing fee.

Three of the four iPhone apps demoed at the release were games. The iPhone looks like a great platform for mobile gaming. It’s about the size of a PSP or DS and the interface has some great possibilities. While it’s an excellent portable platform for running software the SDK restrictions make sure that no one is ever going to download an iPhone application that fundamentally changes the way they use their phone. An iPhone will always look, feel, and work the way Apple designed it.

Android lets you write applications that do more than just run on a portable device. It has the potential to create software that extends the functionality of the phone itself, to change how and why you use your mobile phone completely. More on that later.

Android Updates

Google released a new version of the Android SDK today.

There's a range of improvements, the most impressive being the expansion of mapping services to include forward and reverse geocoding as well as business lookups. This feature plugs a big hole in the LBS and mapping functionality previously available in Android.

Other improvements include a new iteration of the still-being-worked-on Android GUI (screen shots here), a new Animation class for creating animations in layouts, and an improved MediPlayer class that supports additional audio formats.

Also, while I've been away getting married for the last month there's been a few important Android annoucements. Here's a quick summary of what's been announced so far this year:

• LG have joined Samsung in committing to releasing an Android compatible phone towards the end of 2008 / start of 2009.


• The Android Developer Challenge has been extended until April 14.


• You can now file bugs against the Android SDK.

Android Developer Challenge 'Open'

It's a couple of days late, but those of you with a bright idea for a mobile app and a hankering for a slice of US$10 million in angel funding should head over to the submission page for the Android Developer Challenge.

Google is accepting submissions from today until March 3 for the first of two rounds of development funding. The 50 most promising entries will get $25k and be in the running for ten $250k and ten $100k prizes.

Project submission involves uploading a compiled .apk file along with your contact details and a readme file. You can include any additional information you like in the readme -- instructions for use, design documents, or a narrative describing your vision for your application.

The entries will be judged on their (i) originality, (ii) use of the Android platform, (iii) polish and appeal, and (iv) indispensability. So the perfect project will be one of a kind that leverages all the Android specific features, looks amazing, is well polished, and once installed you'd never want to remove it.

The challenge is more 'Iron Chef' than 'Dragon's Den', so the working application you submit is definitely the most important part of your submission. They're not looking for your plan for the $25k - $275k in prize money, they want to reward what is already a polished indispensable project. A detailed 'pitch' document submitted with a dinky 'proof of concept' is probably not going to get a look in.

Be sure to check out the new Terms & Conditions, here are some highlights:
- You can submit your application using any of the SDKs released on or after 3rd Jan.
- March 3 is a hard deadline.
- You can submit updates to your project(s) at any time until March 3.
- You can submit projects as an individual, team, or business entity.

The danger of this 'show me' rather than 'tell me' approach is that it is a reward for work rather than a submission for funding. The initial winners will be the development teams that have been able to implement and polish the most functionality within the competition time frame -- most likely the developers with the least need for funding to continue their development.

There's also the question of multiple similar applications. Obviously they'll be up against it on the originality criteria, so you'll need to make sure yours is the most polished and feature rich of the entries to stand a chance.

More details on the challenge can be found on the ADC FAQ.

(For those wondering, real-life Android phones are still expected in the second half of 2008)

New Year, New Template, New Direction

2008 promises to be another big year in technology. Apple's 3G iPhones are set to do battle with Google's Android phones, Google looks to take on Facebook on multiple fronts, and a whole bunch of secret (and not so secret) Google projects look set for release.

On a personal note 2008 is shaping up to be pretty massive too. I'm getting married in January and I've just started writing a new book (more on that later). I've also decided to tweak the emphasis of The Radioactive Yak. I'm going to leave the comprehensive Google coverage to Philipp and Tony at Blogoscoped, and the up-to-the-second Google-code-hacking to Ionut at the Google Operating System.

I'll be looking more closely at Google's programming offerings - particularly Android - so expect to see more tutorial posts like How To Program Google Android and Google Mashup Editor. I'll continue to write speculative posts like Google TV and Google World, as well as more detailed analysis of announced services like Android and Knols.


I'll also continue my series on the Google Office and I'll announce the projects I'm working on like Earthquake!, Hit For Six, and what I promise will be an increasingly large collection of Android applications.

Along with content changes I've given the template a fresh new look. I hope you like it and continue to visit and read in 2008!

Don't Believe the Hype: Knols Won't Compete with Wikipedia

Google's announced but unreleased Knols isn't a Wikipedia killer, it's a knowledge base for original thought.

If we're going to accuse Google of stealing an idea give credit where it's due.

Most of the press touts Knol as a Wikipedia killer with the differences explained away as cosmetic changes. They aren't. Fundamentally Knols and Wikipedia articles are two very different things; Knols are about sharing an author's knowledge, Wikipedia is about summarising a consensus.

If we're going to accuse Google of ripping of an idea, let's give credit where it's due -- Knols sound just like Nodes at Everything2.

Citation Needed

The philosophy behind Wikipedia can be summed up in two words -- 'Citation Needed'. It's no secret that Wikipedia is not a place for original research or original thought. If you can't provide a cite for whatever you're entering, don't. And that's as it should be. An encyclopedia is a place for objective summaries of knowledge on a subject. If it's working there should be little controversy as the only items valid for publication should be verifiable and beyond reproach. This doesn't always work.

Anyone who's spent any time in academia knows that you can find a citation to justify your point of view. For Britannica the decision on what the consensus is, is made by people trusted to be objective and expert enough in their fields to make the call. In Wikipedia it's up to editors whose authority comes from having made similar decisions many times before.

The raison d'etre is providing a forum for original thought and research.

Knols are like journal articles as Wikipedia is like an encyclopedia. In journals authorship is key, the quality of the research and the reputation of the author are more important than the reputation of the medium they're published in. Journals, and now Knols provide a forum for people to publish their research, their scholarship, their original thoughts. With Knols, when multiple people do research on the same subject they can be published side-by-side and people can review, comment, rate the quality of the scholarship, and the conclusions all in one place.

Original research isn't limited to academics either, it opens the knowledge base to personal experience. Where Wikipedia is the perfect place to describe the science and timeline of the Apollo missions, a Knol of the Apollo 11 mission written by Buzz Aldrin holds immeasurable value. A Knol written by someone who remembers watching it on TV would be valuable too.

Where wikipedia seeks to create a homogeneous, objective article - Knols can provide fragmented, subjective perspectives that can be evaluated in the context of their authors.

If it still sounds to you like Knol will be a haven only for academic types, have a look at Everything2. If Knols can become Everything2 with professional and academic involvement we all win.

That's not to say that you can't stick Wikipedia articles into a Knol, you could, but there's little point. An army of anal editors and contributors is still a better way to converge on the most correct article. What Wikipedia eschews is exactly what a Knol is perfect for, they should be able to live side-by-side complimenting each other.

You do a search and find my Knol -- but how do you know if it's accurate?

Let's say I publish my findings on the current state of the art of subsea Inspection engineering. For a start you've got the ratings and comments on the article, and if I've done my work well there should be citations for the well established information, but as for the rest you need to research the author - me.

Turns out my honours thesis was on inspection engineering techniques, and I worked in the industry for more than 5 years developing bespoke inspection software. From that you can probably establish that I know what I'm on about but might have a bias towards whichever technology I'd been using. And you'd be right. If you're lucky other people will have written Knols from their own experiences, failing that you can look at my other writing to see if I'm generally considered an unbiased source.

Knols gain the power of life over a journal article that remains a lifeless document.

By providing the ability for users to comment and suggest changes a Knol gains the power of life over a journal article that remains a lifeless document. Rather than peer review by a select group of experts, Knols will be peer reviewed by the wider community. There's a risk there, but one that can be mitigated by giving more 'weight' to other Knol experts. They can learn from Everything2 on this as well.

By collecting all this original thought in one place rather than scattered and abandoned single blog entries or single page web sites, Google groups related thoughts and research together, and gives us a centralised view on fragmented thoughts.

Google Powered Dynamic Charting

Google have expanded their API collection to include fantabulous real time, dynamic charting. They announced it today on the Google Code Blog.

Putting this into your img tag or browser:
http://chart.apis.google.com/chart?cht=v&chd=t:40,40,40,10,10,10&chs=250x150&chdl=Google|Charting|Awesome

Will produce this:
It's the same technology they use in Finance and Video, so it's nice to see them make it available for all of us. It currently supports line chart, scatter plot, bar chart, Venn diagram, and pie charts.

Google Maps Terrain

What do you do if you're Google and you've got excellent terrain data for most of the world?


You make it available on Google Maps of course!

Google Maps now features 'Terrain' in place of 'Hybrid', with the hybrid selection becoming a 'Show Labels' option under Satellite view.

Terrain data varies depending on the terrain resolution they have available, but it covers the whole world, just like Google Earth.

It reminds me of the old style relief atlases I used to browse through at the library, and a old hardcover book my parents had for the Grand Canyon. Love it.

View Larger Map

Android in Action

It's been a week since Google released their first cut of the Android SDK and despite Scoble's claims to the contrary, thousands of developers spent last week developing their first Android applications.

Where Are My Friends?

Here's what I was able to do in about 14hrs of development.



It reads the address book to find my friends, uses the Location Based Services to show how far away I am from them, and then plots everyone within 10km on a map. Philipp over at Google Blogoscoped has published my experience, leave a comment here or in the Blogoscoped forum if you've got questions -- or send me an email at Reto.Android@Radioactiveyak.com.

Today I'm a desktop and mobile developer.

As a development platform Android is phenomenal; It's powerful and it's intuitive. I week ago I was a desktop developer dabbling with online apps -- today I'm also a mobile developer. I don't say this lightly, desktop development is what I do to pay the bills.

Doesn't it make sense to launch the SDK well in advance of any actual phones?

Erstwhile video blogger Scoble is disappointment with Android. It seems this is largely because the launch "videos were boring". Robert? Dude? Who gives a shit about the videos? Developers don't want videos, they want CODE. Code, samples, and a well documented API. I still haven't watched the videos, I was too busy using the SDK to spend time looking at the pretty moving pictures. Apparently the shiny lights distracted Scoble as he screeches "[I] DO NOT TRUST THINGS THAT THEY WON’T SHOW ME WORKING". Android works. I've seen it, I've used it. They announced a software stack not hardware, and the software stack is available right now.

True, there are no phones yet, but Android is about development tools for 3rd party developers, so doesn't it make sense to launch the SDK well in advance of any actual phones? Google aren't going to out Apple the iPhone but they may just out Microsoft Windows Mobile.

You can bet that there's more than one Android project to duplicate the iPhone interface in excruciating detail.

There's been some complaints about the Android UI. It's true, the emulator isn't groundbreaking. It doesn't have to. It exists solely to provide the functionality developers need to write apps. How many projects do you think are right now in the process of reskining that bad-boy? The iPhone interface is as inevitable as this MS Messenger skin. The shipping UI is irrelevant, it's the flexibility of the SDK to create a new UI that's important.

Despite Scoble not knowing "...a single developer who has had his/her hands on Android" there are more than 4,500 members on the Android developer forums and more than 4,000 messages. Even if only 1% of them come up with a useful mobile application that's still about 30 more useful mobile applications than I've ever come across for Symbian.

The Android phone won't have the iPhone's consumer appeal. It's very true, but it's also entirely beside the point.

Read enough articles and you'd think that if Google doesn't immediately grab 30% of the mobile market at launch they Fail. That's short term thinking. Developers will write applications for Android phones because they literally can't write them for other platforms. One will get you ten that the iPhone SDK won't have nearly the level of phone access that Android provides.

Eventually people will be buying Android phones because the applications they *need* only run on Android phones. Don't believe me? Do you think people run Windows for the pleasure of it? Worst case scenario? Android forces people like Apple and Symbian to offer the same SDK access in order to keep their market. I'll take that and still call Android a net win.

Google's strategy seems to be 'make it open' -- with 'make it popular' a distant second.

People probably won't be lining up around the block on the release day for the first Android mobile but just like Google search and just like GMail, Android is going to change the way we think of mobile phones.

What made the PC so popular? Why has the web taken off? Because *anyone* with the inclination could bring their vision to life at minimal cost. If you've ever tried programming for a mobile phone you'll know it's expensive and difficult -- that's why there's so few *good* mobile phone applications, and very few for free. The Android platform is going to get thousands of developers playing around with new applications for mobiles, in the same way early IBM compatible PCs got thousands of electronics hobbyists interested in programming computers.

Eventually the availability of popular apps on Android phones is going to encourage more phone makers to release Android versions and networks to release Android phones. It costs them nothing in licensing.

People love iPhones, companies love options.

I don't run Windows because I like it, I run it because 75% of the applications I use every day only run under Windows; plus I can write powerful software for myself really easily.

Corporations will start buying Android phones for the same reason almost every company that's not a graphic design house runs Windows -- it's a more universal development environment with deeper access to the underlying hardware. I work for an investment bank, they'd never dream of writing corporate software for the iPhone; do you think the 300 Java developers here might be able create something useful with Android?

Google Android SDK Released

The SDK for Google's mobile phone platform, Android, has been released today.

A series of YouTube videos gives us our first look at what the Android phone OS actually looks like -- and it looks phenomenally cool.

The 'preview' SDK has everything you need to create and test your Android apps, along with an emulator that will let you see what your phone apps will look like when deployed.


The development is done in Java (they suggest Eclipse but it's not required), and Google have provided tight integration with all the phone features (including GPS, phone, camera, ...) as well as Google services like XMPP and Google Maps.

Along with the SDK, documentation, discussion group, and developer blog; Google has also announced a 'Developers Challenge', where the top 50 in development apps share up US$10million in prizes. Shit, there go my weekends for the next 6 months.

I'll post more once I've had a chance to play with the SDK. The power and ease of use of this development environment is going to be a big factor in the future success of any future 'gPhones'. Certainly this free and open approach to phone app development, with total access to the phone's resources, is a giant step away from what's been available up until now.

Using Google Apps with the Google Mashup Editor

The thing I like most about Google's ever expanding lineup of online applications is the corresponding set of programming services. RSS, ATOM, JSON, and Gdata feeds ensure there's plenty of ways to access your data from stored in a Google app. At Hit For Six (source code), three of the tabs are populated with information from a Google data source - Spreadsheets, Calender, and Reader. Here's how to use these feeds as data sources within Google Mashup Editor (GME) to create interactive web applications.

One of the most common mashup tasks is geocoding a location to place a marker on a Google map

One of the coolest new features in the GME is the dynamic geocoder. When your creating a maps mashup it's inevitable that you'll be geocoding a location to put a corresponding marker on a map. The gm:map tag in GME lets you specify 'lat' and 'long' fields in your atom / RSS feed.

gm:map id="liveMap" data="${liveList}" latref="geo:lat" lngref="geo:long"

But what if you only have a named location? Previously you had to handle this manually, either pre-geocoding the location (as I did using Yahoo Pipes), or using JavaScript to handle it client side. The latest release of GME automates this step by supporting a geolocationref parameter that takes a field from your feed and places a marker on your map based on the result from the Google Geocoder.

gm:map id="calendarMap" data="${calendarList}" geolocationref="gd:where/@valueString"

This is perfect for a Google Calendar source where you have a location but not the literal lat/long coordinates; like the 'upcoming fixtures' tab at Hit For Six. The dynamic geocoder is not the same as the Google Maps search bar, and you can't limit its scope. To get the best results you need to include as much location context as possible when passing values (city, state, countryS). Some countries (like India) return locations for certain named locations (like sporting venues) in Maps, but won't work when using the geocoder.

A calendar is useful as a database but the Calendar UI has been designed specifically with appointments in mind

A calendar is a perfect database for time based information. I use Google Calendar to track upcoming book releases, store sporting fixtures, and record timesheets. But the UI is designed with appointments in mind and none of these use cases are appointments. Instead we can use the GME to produce a custom GUI that's right for our data, and the best way to leverage the data stored in a Google Calendar in the GME is using the ATOM feed. You can pass query parameters in to your calendar feed to filter and sort the returned entries.

http://www.google.com/calendar/feeds/radioactiveyak.com_7qt1thddqotp3eic9lud1jelq8@group.calendar.google.com/public/full?futureevents=true&orderby=starttime&sortorder=ascending&max-results=100

Start with a feed that returns only the items we're interested in. Limit by date (show future events only) and cap the maximum results (no more than 100). Then sort (by start time) on the server side. Next create your UI using the GME tags, custom JavaScript, and HTML. In Hit For Six I want to see these events listed and plotted on a map. Using the map tag and the runtime geocoder we can display the calendar entries on a map with a single line of code.

gm:map id="calendarMap" data="${calendarList}" geolocationref="gd:where/@valueString"

It's worth noting that the calendar service is relatively slow, so it's worth the effort to limit the number of returned events to prevent any timeouts. If you're interested in writing data to the calendar as well as reading it, Google's recently released Javascript client might be what you're after.

Publishing your spreadsheets with ATOM lets you create a custom database with an XML feed that updates in real time

I love the idea of using Spreadsheets as an online database. Publishing your Google Spreadsheets lets you specify an arbitrary data source that updates in real time based on spreadsheet changes. Using the ATOM output makes using spreadsheet data in GME pretty painless.

Set up and populate your spreadsheet, select publish and grab the ATOM feed address, make sure you choose 'list feed'.


The default action for entry labels is gsx:columnname, but it's worth pasting your feed into the GME feed browser to confirm. You can set up 'structured queries' to filter your datasource, and it's good practice to do these sorts of filters 'server side'.

A nice trick with spreadsheets is using a 'table of contents' worksheet that provides the feed location of other worksheets that you will use as data sources. In the Hit For Six 'Venues' tab I provide a list of countries which, when selected, populates a country specific ground list based on the corresponding worksheet.

http://spreadsheets.google.com/feeds/list/o01765357489133287312.3601895615788609870/od7/public/values

I can then add new countries and only have to update the spreadsheet, the website will reflect this change automatically.

It's not all beer and skittles

There are a couple of things you need to keep in mind when using Google data feeds rather than 'regular' RSS feeds.

• You can't spoof the feed requests to force frequent updates. Google services require specific feed request parameters (you can't add 'fake' parameters like &random=12354 or &datetime=20071022 to force the GME feed cache to update the data deterministically). That said, the GME team have negotiated a deal with the team that handles the feed caching to provide more frequent updates (in the order of 10mins rather than 6hrs). If that's still not fast enough, you can funnel your feeds through Yahoo Pipes.


• GME expects RSS feeds rather than XML data feeds. RSS feeds tend to add new items rather than modifying or removing existing ones. If you have data that changes often you may want to pipe it through Pipes first. That will let you change the calling string (by adding a random or time based parameter to the feed address) and force GME to refresh it completely.


• It's all open. Note that if you're using Google services as backends you're making that backend public. Once you set it up for your GME application to use, everyone has access to the underlying data. If that's not open enough, your GME code is an open source project by default (and requirement), so nothing's secret.

Google Goes Open Social

John Battelle appears to have scooped Google by releasing a draft of Google's Open Social press release. Google Operating System gives a pretty good rundown of what it's all about so I won't rehash that here. What I do think is interesting is the defacto social network that Google's just created.

The launch partners (Orkut, Hi5, Ning, Friendster, LinkedIn, ...) are an impressive collection of social networks that aren't Facebook or MySpace, but the biggest launch partner hasn't been listed.

Google already has a massive social graph, it's all your contacts in GMail and friends in GoogleTalk. Google already uses this social graph to show you a news feed created by your 'friends' in Shared Stuff. Google have said that the GMail contact manager is going to be migrated into Google's other services, and your Shared Stuff profile has already been re-used in Google Maps.

Now we have Open Social, and it doesn't take too much imagination to see iGoogle supporting Open Social widgets. Suddenly you can create an iGoogle tab that displays Shared Stuff feeds and Facebook style social apps that use your GMail contacts as friends. Want to know more about a friend? Just view their 'social profile', and with Open Social you've got a world of 3rd party developers ready to go.

Without having to release a 'new' social network Google already have. Friends, profiles, social apps, picture albums, news feeds, IM, inbox messaging -- just by adding a social layer on top of their existing properties, Google has scooped Facebook.