Google I/O: Gulp…

It’s that Google I/O time of year again, when Google releases more developer headf*ck APIs and code goodness in one go than it does at other times of the year (fanboy? me? Nah….. heh heh;-)

So what do we have this year? I’m guessing Liam will, if he hasn’t already, cover the Google TV announcement (and how much ad revenue with that bring them, if it takes off?), so I’ll take a look a the bits no-one’s been saying much about but that will (IMVHO), make a difference…

First up, the Google Prediction API (and who saw that one coming…?! Sigh ;-) I’ve been playing with AI on and off for that 15 years (if you want a quick techie way in, with code examples on tap, Programming Collective Intelligence: Building Smart Web 2.0 Applications is hard to beat) but the novelty of this for me is two-fold: first up, intelligence (in the form of supervised training) on tap, as a service/web app. The Google Prediction API will see a steady increase in the number of people considering how to make their applications more intelligent, or provide a playground, if nothing else, for people who want to be able to train over large data sets. However, because Google owns the training algorithm, you can’t necessarily tune it yourself… It’s worth bearing in mind that Google is a master of casting applications so that they can benefit from supervised training (see for example People Powered Supervised Training Algorithms: Google Does it Again?) so with their weight behind it, the Prediction API could be an early indicator of a path that will lead to the commoditisation of computational intelligence, via industrial scale paid for services (“In the future, we plan to launch a paid version of this API”). In the same way that Amazon started selling web services off the back of infrastructure developed for its core business, Google is just following a similar course of action. Of course, the prediction API may lead to nothing… although along the way it might encourage companies to start putting large amounts of their data into its Google Storage service (which in turn is opening up a front against Amazon S3, maybe?;-)

Secondly, the Google Latitude API. Some commentators are claiming that with the likes of Foursquare and Gowalla already fighting over location, Google is well behind the curve on this one. I’m not so sure… Several location related Google APIs are starting to require users to declare whether the data is coming from a sensor or not (e.g. Google Elevation API: Denoting Sensor Usage) so if you think past location as people related and start to think about telemetry and instrumentation in a wider sense, the Latitude API could be a place where the geo sensor data goes (cf. pachube. If Pachube is ahead of the curve, I wonder if Google will snap them up, maybe as a short term complement to Google PowerMeter?)

Also on the mapping front are Google Styled maps, which let you customise the appearance of Google Maps. CloudMade has been offering this sort of service for some time over OpenStreetMap content, so I hope that rather than sound a death knell for CloudMade, the Styled maps actually sees a wider uptake of CloudMade. (I wonder too if anyone will fire up an extension to Mapstraction, the library that abstracts over a wide variety of map APIs, to cover styling?) If the opportunity arose, would the CloudMade folks make the jump to Google, I wonder?

Third up are the creepy bits… AdSense for AJAX/Search Ads and Gmail contextual gadgets, now available to all developers. AdSense for AJAX lets you pull contextual AdSense ads into your own page, even if the page is filled with dynamic content, by providing you with “the ability to supply hints to help ensure that ads with high relevancy are shown to your users.” AdSense for Search Ads seems to let you pair a Google custom search results panel and an AdSense panel so that you can pull back relevant AdSense ads into a page based on corresponding search results. Way up on my to do list is looking at whether we can use adservers to serve contextual content, so here’s another possible route for trying that out… On the GMail front, if you want to push contextually relevant content to people based on the contents of their email folder, (and why wouldn’t you?!;-)

A Gmail contextual gadget is a gadget that is triggered by clues in Gmail, such as the contents of Subject lines and email messages. A Gmail contextual gadget can be triggered by content in any of the following parts of an email: From, To, CC, Subject, Body, Sent/received timestamps

The gadgets can be deployed either within an Enterprise environment (does this include Google Apps for Edu, I wonder?) or via the marketplace. On seeing these gadgets, my first thought was some sort of phishing like expedition. Could I send emails to people from a particular email address, and then pull in additional related content via the Gadget, or somehow build up a profile of someone via the content of their mailbox in a two pronged attack that identifies them through tracer emails and reconciles this with the results of the content analysis?

I have to admit the list of filter elements shocked me a little:

I can see this being hugely powerful if you think of your email as public goods, at least within the context of a public that exists within an enterprise, but more generally…? Err…? Let’s say I might have concerns… Or have I completely misunderstood how this all works? (See also: Personal Declarations on Your Behalf – Why Visiting One Website Might Tell Another You Were There. Suppose: I send you email, and you’re running a gadget…)

Anyway – thought for the day: what would a GMail learning environment look like?, where email messages sent to the user contained the course content, one (daily) chunk at a time, and the contextual widget pulled in additional materials based on the lesson/email the student was reading at the time? (NB I think it would be reasonable to assume that Google docs contextual gadgets might be a possibility some time soon?)

Finally, the big news… :-) Google Feed API supports PUSH and Google Apps script gains external triggers. First up – PUSH. You may have noticed that on certain Google search results pages, you get a small area with realtime web results that get pushed to the page almost immediately after they are created. What this means is that you can be pushed updates from a feed as soon as Google spots new content on that feed. What the Feed API now supports is this realtime PUSH updating. Complementing this, we have external triggers on Google Apps script. I haven’t found any documentation on this yet but the promise it that you can trigger Google apps scripts (for example, scripts associated with a spreadsheet?) from a third party site. The apps script documentation site is also announcing Installable Event Handlers which currently “support clock events which allow us to trigger a script based on the time”. For the serverless web developer, being able to run what are essentially cron jobs has always been a problem. But now it seems as if I should be able to run a script according to a particular schedule from with the Google Apps script environment. (I could probably do this in the Google App Engine environment, but I don’t see that as ever being a mass-user environment – it’s too coding programmer techie for mortals…) What does this mean? Well, it means I can tell my spreadsheet to go and grab some fresh data from some location at scheduled times of the day. Remember what I was saying about Pachube….?!

Okay, so that’s my take on this year’s Google I/O… a quirky perspective, maybe, but one that could have more consequences in terms of the way things are done, could be done and might be done (particularly in a realtime/live web environment) than a music store or leanback TV search app… As for the Android announcements… I still don’t have a good feeling for the movile ‘verse…

PS pound to a penny any OU newsletters on this only pick up on the TV bit;-)

PPS Oh yeah, forgot this one… WebM (i.e. video’s gonna change…;-) Gulp….