Google announced Friend Connect today, a new service that will allow any web site to enable social networking features for their visitors. And the key piece of the strategy is that to do so only takes a few lines code, similar to the ease with which AdSense ads can be to any web page. By walking through a few steps in a web-based wizard, a site owner can get a snippet of code that can add functionality like “user registration, invitations, members gallery, message posting, and reviews, as well as third-party applications built by the OpenSocial developer community.” More information on the project will be available at http://www.google.com/friendconnect after the Campfire One event at Google’s Mountainview headquarters later tonight.
Leveraging emerging standards like OAuth, OpenID and OpenSocial, Friend Connect stitches together much of the social network plumbing found in most of today’s social networks. And by virtue of building on OpenSocial, it effectively makes any site that uses Friend Connect into a simple OpenSocial container, allowing them to include almost any OpenSocial application into their site (note that sites can still use projects like Shindig and their own code to build more elaborate social features, Friend Connect just looks to lower the bar to entry). As Google’s directory of engineering David Glazer describes:
“Google Friend Connect is about helping the ‘long tail’ of sites become more social,” said David Glazer, a director of engineering at Google. “Many sites aren’t explicitly social and don’t necessarily want to be social networks, but they still benefit from letting their visitors interact with each other. That used to be hard. Fortunately, there’s an emerging wave of social standards — OpenID, OAuth, OpenSocial, and the data access APIs published by Facebook, Google, MySpace, and others. Google Friend Connect builds on these standards to let people easily connect with their friends, wherever they are on the web, making ‘any app, any site, any friends’ a reality.”
More technical details will be available shortly, and in the meantime Google has release a few screenshots, one that shows an otherwise un-social page about Guacamole can gain social features and another showing the start page for their wizard-like setup process.
For good coverage of today’s announcement, which TechCrunch initially broke, see Dan Farber at ZDNet, ReadWriteWeb, O’Reilly Radar, VentureBeat, and the thread at Techmeme.
In late March, Google announced enhancements to their mapping API that gave developers programmatic access to their popular streetview feature. Streetview allows users to “virtually explore city neighborhoods by viewing and navigating within 360-degree scenes of street-level imagery.” The API enhancements provide the ability to embed panoramas in an app and to even pan them dynamically using JavaScript.
Since that release, developers have had a chance to create some very interesting mashups using streetview, and in a recent Maps API blog post, Google’s Pamela Fox highlighted some of these (3 of which are now cataloged in our directory: StreetView Adventure Game, Povo Boston, and Dual Maps):
And if you want more streetview mashup examples:
Also check out VegasVision, Ong Map V2 (Alpha), VPike, FlyRig, Street View Gadget, LotView, Street View SF Tour, RealBird, Glotter and a Street View Tour Gadget. And if you loved Trulia’s implementation (announced on Google LatLong last week), check out this demo that shows how to angle a street view panorama towards the side of the street that a building is on. (It involves math, but don’t worry, we’ve done it for you.)
Standardization, or lack thereof, around identity, authentication and authorization for open web APIs is one of the greatest challenges to mashup application developers today. So it’s quite notable that Google not only just quietly added OAuth support to their Google Contacts API but also stated that “This is our first step towards OAuth enabling all Google Data APIs.” With over a dozen GData APIs to date and more on the way, this is a significant endorsement of this relatively new standard.
OAuth, which we covered last fall, is an API access delegation protocol that has been described as your valet key for the web:
Like the feature on many cars today where you give the parking attendant a special key to your car that gives him some, but not all, access to your vehicle. On the Web you now have your own keys to dozens of sites but how to best handle the mashup-style case of site A wants you to grant them access to get some data from site B? Ideally you don’t want to give site A your password to site B. OAuth aims to simplify this problem: “It allows you the User to grant access to your private resources on one site (which is called the Service Provider), to another site (called Consumer, not to be confused with you, the User).”
This marks at least the second API from one of the major providers to now support OAuth: earlier this year, the innovative Yahoo Fire Eagle API integrated OAuth support.
iGoogle, Google’s personalized homepage is on its way to becoming a of social network thanks to their just announced adoption of the OpenSocial API. In particular, the just launched developer sandbox will allow gadgets on iGoogle will be able to access friends’ data and to create “activity streams” (akin to the Facebook news feed). Shown below is the Updates Gadget where using the OpenSocial API “you can post updates to the updates gadget. Users will be able to see updates generated from their friends’ gadgets, encouraging content sharing.”
As this is in ’sandbox’ mode, this feature set is available only to developers and is not yet rolled-out to the general iGoogle population.
The Google team have updated their iGoogle developer docs and FAQ with more details. There’s also a new video from Google demonstrating the new features.
Many are interpreting this as a hint of things to come. And as VentureBeat’s MG Siegler asks “Who needs to login to Facebook when all your friend’s updates are right there on your homepage?”.
In the beginning, there was the Google (SOAP) Search API. In December 2006, Google no longer issued any new keys for this API. Those with keys already could still use the API, but it was effectively deprecated.
Then came the Google Ajax Search API. This API was more fully fleshed out but was meant to be used only in browser-based JavaScript to display search results. In contrast, the old Google SOAP Search API had not been tied to browser-based JavaScript applications.
Now, earlier this month, via Google Blogoscoped and BadMagicNumber, comes word that Google added a RESTful supplement to the Ajax Search API to support “Flash and other Non-Javascript Environments:
For Flash developers, and those developers that have a need to access the AJAX Search API from other Non-Javascript environments, the API exposes a simple RESTful interface. In all cases, the method supported is
GETand the response format is a JSON encoded result set with embedded status codes. Applications that use this interface must abide by all existing terms of use. An area to pay special attention to relates to correctly identifying yourself in your requests. Applications MUST always include a valid and accurate http referer header in their requests. In addition, we ask, but do not require, that each request contains a valid API Key. By providing a key, your application provides us with a secondary identification mechanism that is useful should we need to contact you in order to correct any problems.
The example search given in the documentation should give you a quick sense of how to use this part of the API. The following command
curl -e http://www.my-ajax-site.com “http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=Paris%20Hilton”
returns a JSON object, which you can parse for titles, URLs, and short blurbs.
We can infer from the careful wording in the documentation that the RESTful interface to the the Google Ajax search API is still supposed to be used only for displaying Google search results on a website. Note the insistence on a proper HTTP referer header (implying that the call is from a web application) and the reference to the API’s terms of use.
In order words, we’ve come from a SOAP based search API that was limited to personal, non-commercial use that nonetheless wasn’t tied to web applications to the current manifestation of an Ajax and RESTful API that is open for restricted commercial use tied to displaying search results on the Web. What’s next?
Hardly a week goes by these days without an API or other developer-related announcement from Google. And given that they now have over 35 different APIs as well as whole platforms like Android, Google will be hosting their first multi-day developer event next month in San Francisco: Google I/O, May 28-29. Last year they had a successful, one day global Developer Day, and this year’s event looks to be a whole lot bigger and broader with 70 sessions covering:
Should be a great event and ProgrammableWeb has 10 free passes to give away: be among the first ten to reply in the comments here and receive a free pass to the two-day Google I/O conference in San Francisco (a $400 value). And of course you’re welcome to suggest what sorts of Google based mashups you’d like to see built next: perhaps using Google Calendar, or YouTube, or Google Book Search, or the new Google Visualization tools.
Update: The free passes have all been given away. Thanks for all the fast replies, ideas and comments.
Graphic, schematic maps can very useful in a wide range of charting scenarios and thanks to a recent upgrade, now you can use the Google Chart API to create them. As we reported earlier, Google’s Chart API is one of the simplest of all Google APIs. By passing parameters in the URL (i.e., HTTP GET), you can get images for various types of charts — bar charts, pie charts, line charts, etc — that you can embed on any web page. Plenty of mashups are already using the API including the 15+ mashups listed here.
The recent update adds this fun and useful capability as you can see in the docs. You can embed static maps that you can color by country or by US state. Here are a few simple examples of such maps, starting with a world map:
http://chart.apis.google.com/chart?cht=t&chs=440×220&chd=s:_&chtm=world
You’ll note that the parameters in the URL control the map, three of which are mandatory for any Google chart:
Compare the world map to the “Hello World” of Google Charts to see how the same API can be used to simple pie chart (click on the pie chart to see the full url/call):
Going back to the world map, see how changing the chtm parameter in the URL displays a map of Europe and using three additional parameters (chco, chld, and chd) highlight Hungary in green, while keeping other European countries an off-white:
Are people already using the Google Chart API to make maps? Take a look at the article Making maps with Google Chart API (listed in the ProgrammableWeb mashup database), which discusses the issues involved with generating the following fuller example of a world map:
Jeffrey Barke wrote a short tutorial for creating maps with the Google Chart API.
As others have noted, the maps one can create in this way are more demonstrations of what’s possible than fully developed functionality — so it’ll be interesting to see whether/how Google refines this feature of the Google Chart API.
For more on the Google Chart API at ProgrammableWeb check-out Google Chart Mashups: Love and Stats.
Google just significantly raised the stakes in the platform-as-a-service market with tonight’s launch of Google App Engine, a scalable, fault-tolerant web application environment that lets developers run their own apps on Google’s infrastructure. Naturally the new platform leverages Google’s expertise in building web-scale services including Big Table-type storage.
While in many ways this service competes with Amazon’s suite of on-demand infrastructure APIs including S3 storage, EC2 hosting and the SimpleDB database, the approach is different. In Google’s model you get all of these services bundled together in one package. This is a plus if you want to run your entire app under one roof versus the lower-level, individual services in Amazon’s model.
At a high level there are five pieces to App Engine:
One of the first questions from most developers will be: What’s the cost? Sign up is free and so is running your app as long as stay under quotas 500MB of storage, 200 million megacycles/day of CPU, and 10GB of total bandwidth. Google estimates this means there will be no cost for up to approximately 5 million pageviews a month. Once this initial preview period is over Google will introduce a billing model for additional resources at “competitive market prices.”
As you can see there’s a lot to this announcement. Google provides a lot of useful resources including What is Google App Engine?, an FAQ, and set of articles. Note that the preview release is limited to the first 10,000 developers that sign-up.
And finally, a note on today’s launch itself: just as they’d done with their OpenSocial announcement last fall, Google launched App Engine at a Campfire on Google’s Mountain View campus. For details on the event itself check-out TechCrunch’s coverage including videos from Robert Scoble.
It has been a busy stretch for Google APIs: besides the recently released new AJAX Translation API this month, Google also launched the Google Visualization API, a JavaScript API which lets you access multiple sources of structured data that you can display using a large selection of visualizations. The Google Visualization API also provides a platform that can be used to create, share and reuse visualizations written by the developer community at large. For more technical details there’s a new Visualization API profile here and a new mashup listing for Motion Chart, a dynamic Flash based chart to explore several indicators over time.
Digging into the documentation you’ll find a more detailed description of the API:
Google Visualization API is a JavaScript API for web developers and gadget developers to access and display tabular data from many sources, for example Google spreadsheets….The Visualization API addresses two common problems in data visualization: 1. How to read data from multiple data sources using a single API. 2. How to process the data without knowing about the data source implementation.
It’s important to realize that the only data source that can currently be read using the Visualization API (a “compliant data source”) is a Google Spreadsheet and the API doesn’t yet define how to implement a compliant data source. Since Google Spreadsheets already has a RESTful GData-based API (Google Spreadsheets API Profile), you might wonder what’s the point about having yet another API to access Google Spreadsheet. The point is: the Visualization API is meant for tabular data from any source, not just from Google Spreadsheets. In the specific case of visualizing data, you won’t need to know the details of the Google Spreadsheets API to get at data from a Google Spreadsheet.
The Visualization API can be used to display data from data sources in a variety of contexts, most prominently in Google Visualization Gadgets that can be displayed in iGoogle or a Google Spreadsheet (akin to embedding a chart inside an Excel spreadsheet). A quick way to see the Visualization API in action is Google Visualization API Gadget Gallery, a showcase for what people have done with these gadgets so far. Follow the instructions instructions on using Visualization Gadgets to apply these gadgets to your own Google Spreadsheet. To learn how to program with the Visualization API, start by working through “Hello World” example of the API and the tutorial on Gadget Extensions - Google Visualization API - Google Code.
In another big move for the OpenSocial inititive, Google, Yahoo and MySpace announced today the formation of OpenSocial Foundation. As reported earlier this month, Yahoo was expected to join OpenSocial, and indeed now it’s official: “It’s no longer a trial balloon — it’s for real. We are taking this opportunity to help ensure websites and developers feel confident using OpenSocial as the building blocks for their new social apps.” But clearly this news goes well beyond Yahoo’s participation, it’s another step in moving OpenSocial into the common fabric of the web.
Other details from the announcement:
Where’s Facebook on this news? CNET’s Caroline McCarthy reports on a statement from Facebook that “As the largest contributor to the memecached system, Facebook has long been a leader and supporter of open source initiatives but will not join the foundation. The company will continue to evaluate partnership opportunities that will benefit the 300,000 Facebook Platform developers while improving the Facebook user experience.”