By Christian Sonntag, Google Health Team

With the recent launch of Google Health, we also launched the Google Health Data API, which we hope will further contribute to the goal of making personal health management easier for people. The API can be used to create new medical records, request a list of medical records, and query for medical records that match particular criteria.

Learn the details from this announcement post on the Google Data APIs blog, and join the conversation in our discussion group. We look forward to seeing the apps you create with this new API!

By Nir Bar-Lev, Product Manager

We are excited to announce that we are opening up the Google Visualization API beyond Google Spreadsheets and adding more capabilities for developers. Earlier at the Google I/O developer conference, we launched several new features of the Google Visualization API:

• A JavaScript interface to create add-hoc data tables on the client. This way, visualizations are not limited to server-side data sources living on the Google cloud. Data from any source can now be visualized using the visualizations created by Google and the community.

• The new interface allows developers to create non Gadget-ized visualizations. With this new option, developers can embed visualizations directly into a web page and have those interact with the page. Of-course, Gadgets have significant advantages related to syndication. They are also the option of choice when looking to include visualizations in popular “containers”, such as Google Spreadsheets, iGoogle, etc. The Google Visualization API will continue to support both flavors of its API going forward. Visualizations can easily be created and then be wrapped by a thin Gadget wrapper. This allows for maximal exposure and use of the visualization in as many use cases as possible.

• The AJAX API introduces another cool new capability: we are introducing a common event model to allow for visualizations to communicate with their host web-page and with other visualizations. With this event model web page authors and developers can create complex dashboards from several visualizations, all associated and context-aware.

As part of the event model, we are introducing a generic select event. Developers can introduce their own events for their visualizations. We plan on adding more generic events that the community chooses and aligns around – ultimately creating a robust event model for visualizations and dashboards.

You can read more about these cool new additions on the Visualization API website. Browse the new visualization gallery to see the visualizations we have already posted over the new JavaScript interface and and take look at code examples to get started with your own.

We would love to hear more from you on these new additions. Tell us what you think and engage with the rest of the community on the API’s community group page.

By Nir Bar-Lev, Product Manager

When we launched the Visualization API we wondered, which new visualization types will the developers out there come up with? Which one will be successful? Will we quickly see the long tail of visualizations being developed?

Visualizations, as with many other things, follow a rule we know very well at Google: Their distribution is such that there are a few visualizations at the 'head', which get the majority of usages, and then there is a long tail of special visualizations, that by virtue of their subject matter or type, get little overall use.

Take for example the ubiquitous line chart vs the radar chart:




Line charts are extremely useful in visualizing continuous changes over time or other factors, and as such are used for data sets ranging from displaying financial results, to the growth of germs on petry-dishes to following presidential candidates' accumulation of votes. You'll find line charts in almost every type of presentation, even in cartoons:



On the other hand, radar charts are relatively rare and most people have never encountered one, unless they happened to have taken an advanced university course in Marketing, for example.

Obviously there are highly specialized visualizations that are extremely common. For example, the 2-hands clock view, is one of the most wide-spread used visualization to display time. Yet, many visualizations have been developed for specific use in specialized fields of study, or work.

As such, you can imagine we had a fun time betting on which visualization will come out and which will catch on. Some of the bets in the team were made on us first seeing specialized visualizations. Perhaps a network diagram. Others, had bet on seeing new, high end, pivoting and data drill-down, slice-and-dice wizardry. Who won? Apparently we all lost our bets.

It seems the common straightforward visualizations can be reinvented with a just few simple changes to make them immensely powerful - and fun - as visual tools. Enter, the Bar (or Column) Chart and the Piles of Money visualization:





By altering the standard visual design of the bars (or columns) as wide lines, or rectangles and simply converting them to an image of a growing pile of money, the Piles of Money chart has rocketed to the top five most popular visualizations used over the Visualization API. This simple change can provide the same insight as any bar chart, yet when used on data sets related to cost, revenue or any other financial measurement, it becomes a fun, engaging chart, not derogating in any way from its original purpose and actually adding additional emphasis that the subject matter is money.

The Bars of Stuff chart was added just after Piles of Money, and provides the same treatment to the horizontal bar chart as Piles of Money did to the vertical bar chart. Users can choose on of several cool visual designs, like chocolate, cute worms, etc to be used instead of the bars.

I can't wait to see someone take the idea behind Piles of Money and advance it to the next step: create a visualization in which the user can visualize bars of anything they want by choosing the image to be integrated into the visualization: Piles of Boxes, Piles of Shoes, Bars of Soap.

To see all of the Visualization API's current list of visualizations by Google and the community, check out our gallery.

By Benjamin Lynn, Google Developer Programs

Git is a popular member of the latest generation of version control systems. Learn why at our Open Source Blog, where we show how to use Git with Google Code Project Hosting.

By Peter Chane, Sami Shalabi, Mussie Shore

We figured you might be tracking the conversations about Google Friend Connect and Facebook. We want to help you understand a bit more about how it works on the Friend Connect side with respect to users' information.

People find the relationships they've built on social networks really valuable, and they want the option of bringing those friends with them elsewhere on the web. Google Friend Connect is designed to keep users fully in control of their information at all times. Users choose what social networks to link to their Friend Connect account. (They can just as easily unlink them.) We never handle passwords from other sites, we never store social graph data from other sites, and we never pass users' social network IDs to Friend Connected sites or applications.

The only user information that we pass from a social networking site to third-party applications is the user's public photo, and even that is under user control.

That's the high-level view. But what about the details? Here is more information on exactly how Friend Connect interacts with third-party social networks and applications.

1. Google Friend Connect puts users in control over whether they're connected to their data on Facebook.
2. Google Friend Connect only reads a small amount of user data from Facebook, and does so using Facebook's public APIs. We read the Facebook numeric id, friendly name, and public photo URLs of the user and their friends. We read no other information.
3. The only user information that we pass from Facebook to third-party applications is the URL of the user's public photo.
4. Google Friend Connect does not permanently store any user data retrieved from Facebook.

1) Google Friend Connect puts users in control over whether they're connected to their data on Facebook.

We behave like any other caller of the Facebook API. (See the Facebook developer api documentation for details.) When a user links their Facebook account with Google Friend Connect they must consent to this on Facebook itself. Here is the set of screens a user goes through:

First, the user must click "Link in Facebook friends":



Next a user sees this screen. This screen is from Facebook (notice the URL of the page shows facebook.com):



The user is then asked for their Facebook username and password on Facebook. (Note that Google Friend Connect does not have access to the user's Facebook username and password.) If the user logs in successfully, Facebook returns a session key to Google Friend Connect, and the user sees this screen:



This screen also comes from Facebook. On this screen the user is asked to consent to allowing Google Friend Connect to access some of their personal information. The user can choose to allow this access or not.

The user can easily unlink their Facebook account from Friend Connect. This can be accomplished in two ways:

From the Friend Connect settings dialog:



And from within Facebook's own Applications Privacy screen:



2) Google Friend Connect only reads a small amount of user data from Facebook, and does so using Facebook's public APIs. We read the Facebook numeric id, friendly name, and public photo URLs of the user and their friends. We read no other information.

If a user decides to link their Facebook account to Google Friend Connect, we ask Facebook for a small amount of user information. Here's an example of what might be returned:

Example data retrieved from Facebook (NOT passed to third-party apps):

500013789

  31415926535

  Peter Chane

  http://profile.ak.facebook.com/profile5/1038/101/s500013789_4207.jpg

  694454023

  Mussie Shore

  http://profile.ak.facebook.com/profile6/1933/85/s694454023_4271.jpg

  709611

  Sami Shalabi

  http://profile.ak.facebook.com/profile5/657/87/n709611_9673.jpg

This data is made up of the following fields:

• A Facebook user ID (e.g. 500013789) that is used when Google Friend Connect communicates with Facebook. The unique ID is a number assigned by Facebook -- it is NOT the user's username or their phone number. The unique ID contains no personal information.
• A session-key (e.g. 31415926535) which is a unique number provided by Facebook, that Facebook uses to track and control what data is exposed to Google Friend Connect for the logged-in user.
• The user's friendly name as they entered it in Facebook (e.g. "Peter Chane"). This is typically a first and last name.
• A URL to the user's public Facebook picture (e.g. http://profile.ak.facebook.com/profile5/1038/101/s500013789_4207.jpg). If the user set their picture to be private on Facebook then Google Friend Connect does not receive the picture. Again the picture used by Google Friend Connect is public and is easily viewed by anyone on the web.
• A list of Facebook user IDs for each of the user's friends on Facebook. For each friend, Google Friend Connect retrieves the friend's Facebook picture-URL and name.

3) The only user information that we pass from Facebook to third-party applications is the URL of the user's public photo.

Applications that run on Friend Connect sites (e.g. the iLike application that runs on www.ingridmichaelson.com) have access to a subset of the information that is requested by Friend Connect from social networks such as Facebook. Applications are passed the following data from Friend Connect:

• Your Google Friend Connect ID. This is a number. It is not a name, and it is not your ID from Facebook or any other social network.
• Your nickname that you entered in Friend Connect. (NOT your friendly name from Facebook or any other social network.)
• The URL to your public photo from Facebook or another social network. And only if you've chosen to make that photo public on the social network. (Note that Facebook includes the user's Facebook ID in the URL of their profile photo. We intend to obfuscate this URL in a future release of Friend Connect.)
• The Google Friend Connect IDs (and Friend Connect nicknames, and photo URLs from linked social networks) of any of your friends who are also members of this site. (Not all of your social network friends. Not their social network IDs.)

That's it. These apps have no access to additional profile data -- yours or your friends. The apps have no idea who else is on your friends list on your social network(s).

4) Google Friend Connect does not permanently store any user data retrieved from Facebook.

Google Friend Connect purges all of the data it receives from Facebook frequently. The Facebook terms state that application developers should do this every 24 hours; we do it more often (currently every 30 minutes) because we don't want to store this data any longer than we absolutely need it.

Thanks for your interest in Friend Connect!

Regards,

Peter, Sami, Mussie

By Dion Almaer, Google Developer Programs

With Google I/O around the corner on May 28-29th in San Francisco, you can feel excitement bubbling within the Google Developer Programs team and beyond.

We had another Campfire One this week, and this time the team introduced Friend Connect, a way to easily add social features to your website using open protocols such as OpenID, OAuth, and OpenSocial APIs. Below is a short walk through:



The previous Campfire One was held to announce Google App Engine, and the engines continue to roar. If you are a Mac user, you may be interested to view the native App Engine Launcher, which allows you to manage your work form a UI that you know and love.

You will want to be able to write a scalable application, and Ken Ashcraft has written up some tips to do just that.

Finally, Guido van Rossum wrote a version of Mondrian, the code review system that he wrote for Googlers, that works with Subversion.

The Geo teams also had some interesting releases. First we had the long awaited official Flash API, and then we saw the new ability to find photos and Wikipedia content right in the Maps UI.

If you really liked the My Map editing tools that were made available on the Google Maps destination site, you will be happy to know that a quick polyline.enableDrawing(); will turn it on for your own mashup, hanks to new API support.

Google Doctype is a bold new undertaking spearheaded by the prolific Mark Pilgrim. Doctype aims to build a test-driven reference to the Open Web. Mark "humbly offers this fledgling encyclopedia under a Creative Commons Attribution license, and we invite the web developers of the world to contribute to it."

When you think of developers around the world, you think of translation. The AJAX Language API can now piggy back on Google Translate adding 10 new languages.

I have been having a great deal of fun with the translation API; translating Twitter on the fly, and more importantly having bookmarklet that can translate any selected text on a page.

I will finish up with some interesting thoughts on ipv6 and the new Google Reader version for iPhone.

As always, listen in to the Google Developers channel, and I hope to see a bunch of you at Google I/O. If you can't make it, be sure to follow us on Twitter as we discuss the event in real-time.

By Mickey Kataria, Google Maps API team

We just released the Google Maps API for Flash, which gives developers access to Google Maps from Flash/Flex apps using ActionScript. For more details, check out the Google Maps API blog, and as always, let us know what you think.

By Mark Pilgrim, Google Code Team

The open web is the web built on open standards: HTML, JavaScript, CSS, and more. The open web is a beautiful soup of barely compatible clients and servers. It comprises billions of pages, millions of users, and thousands of browser-based applications. You can access the open web with open source and proprietary browsers, on open source and proprietary operating systems, on open source and proprietary hardware.

Google has built its business here, on the open web, and we want to help you build here too. To that end, we are happy to announce the formation of an encyclopedia for web developers, by web developers: Google Doctype.

In its current (beta) form, Google Doctype contains dozens of articles written by top Googlers on topics important to all web developers: security, performance, caching, DOM manipulation, CSS styling, and more. It contains over 8,000 lines of JavaScript code: Google's own battle-tested JavaScript library, released today under a liberal open source license. And it contains the beginnings of a test-driven reference of the open web: a reference of every element, every attribute, every DOM method, every CSS property, all backed up by test cases.

Well, not quite every property; at least, not yet. We're still working on filling in a few of the details about the world's largest development platform ever, and we need your help. And so we humbly offer this fledgling encyclopedia under a Creative Commons Attribution license, and we invite the web developers of the world to contribute to it. Sign in with your Google account and edit any page, any article, anywhere. Create new ones, update old ones, and help expand the world's understanding of the open web.

By Steve Souders, Member of Technical Staff

This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next month, we'll be highlighting sessions and speakers to give Google Code Blog readers a better sense of what's in store for you at the event. - Ed.

In April I announced that I'm starting another book. The working title is High Performance Web Sites, Part 2. This book contains the next set of web performance best practices that goes beyond my first book and YSlow. Here are the rules I have so far:

1. Split the initial payload
2. Load scripts without blocking
3. Don't scatter scripts
4. Split dominant content domains
5. Make static content cookie-free
6. Reduce cookie weight
7. Minify CSS
8. Optimize images
9. Use iframes sparingly
10. To www or not to www

I'm most excited about the best practices for improving JavaScript performance (rules 1-3). Web sites that are serious about performance are making progress on the first set of rules, but there's still a lot of room for improving JavaScript performance. Across the ten top U.S. sites approximately 40% of the time to load the page is spent downloading and executing JavaScript, and only 26% of the JavaScript functionality downloaded is used before the onload event.

In my session at Google I/O I'll present the research behind rules 1-3, talk about how the ten top U.S. web sites perform, demonstrate Cuzillion, and give several takeaways that you can use to make your web site faster.

By Dion Almaer, Google Developer Programs

Guido van Rossum, Python creator and member of the App Engine team, gave a talk on Mondrian which is the tool he created to work with the code review process at Google.



The Mondrian tool itself was tied to internal technology, but he took the time to built an inspired version on App Engine. Part of the work was having it work with Subversion as the SCM. The name of the tool is Rietveld, and here is what Guido said on the Python mailing list to announce it:

I've always hoped that I could release Mondrian as open source, but it was not to be: due to its popularity inside Google, it became more and more tied to proprietary Google infrastructure like Bigtable, and it remained limited to Perforce, the commercial revision control system most used at Google.

What I'm announcing now is the next best thing: an code review tool for use with Subversion, inspired by Mondrian and (soon to be) released as open source. Some of the code is even directly derived from Mondrian. Most of the code is new though, written using Django and running on Google App Engine.

I'm inviting the Python developer community to try out the tool on the web for code reviews. I've added a few code reviews already, but I'm hoping that more developers will upload at least one patch for review and invite a reviewer to try it out.

Brady Forrest has a nice write-up of the announcement and Joe Heck pointed out that this is not the same as another open source solution called Review Board.

For more details on the tool check out Guido's article.