Friday, May 15, 2009

[Gd] Let visitors recommend your content

| More

Official Google Webmaster Central Blog: Let visitors recommend your content

Webmaster Level: All

We recently posted about some of the engaging gadgets you can add to your site with Google Friend Connect. Here's one more that may be of interest if you're looking for another way to get feedback from your site's visitors:

The new Recommendation gadgets make it easy for your visitors to let you and the world know which parts of your site they like best. By placing recommendation buttons next to photos, articles or other content, visitors can recommend specific items to others with the click of a button. Your most popular items will surface to the top of the recommendation list.

To install a recommendation gadget on your site, or to check out the other gadgets that are available, please visit

Posted by Mendel Chuang, Product Marketing Manager

[Gd] announces the launch of its OpenSocial Container

| More

OpenSocial API Blog: announces the launch of its OpenSocial Container

Hola! My name is Alvaro Teijeiro and I am Sonico’s development manager.

I’m happy to announce that Sonico has recently launched its OpenSocial developer sandbox! is one of the leading social networks in Latin America with more than 35 million registered users. Positioned as the second largest social network in Brazil, Sonico is available in English, Spanish and Portuguese. We’re currently looking for select launch partners that can work with us to provide valuable engaging apps for our upcoming June production launch.

To request access to the developer sandbox, visit

Sonico is a social communication platform launched in July 2007 that merges social utility and entertainment to communicate and keep in touch with friends, family and co-workers. Sonico has been developed with a strong emphasis in user legitimacy, privacy and personalization, and is being widely adopted across Latin America.

In addition to popular features such as photo and video sharing, we’ve recently launched a virtual currency system that can be used to purchase a wide variety of goods and services, such as virtual gifts, greeting cards and profile skins. We’re very excited to allow app developers to tap into this new economy and will be working towards it during the next couple of months!

Detailed specs on Sonico’s features, growth and OpenSocial implementation can be found in the following presentation:

Implementation Overview: OpenSocial v0.8.1
Sonico's OpenSocial platform includes the following:
  • Full support for the core Opensocial APIs:
    • AppData
    • People/Person
    • Activities
  • Gadget rendering of home, profile, preview and canvas views
    • Dimensions for views are the same as used by Orkut
  • Viral features:
    • requestCreateActivity
    • requestShareApp
    • requestSendMessage
  • RESTful APIs
    • RESTful and RPC protocols
Upcoming Supported Features
  • Access to PhotoAlbum API by July
  • Access to Virtual Currency API by August
For further implementation details and future updates, please see:

Developer Sandbox – Available now! (since April)
Consumer Launch - June 2009

We’re really excited to work with app developers to deliver engaging, value added applications to millions of users!

For more information regarding OpenSocial platform, please visit and/or contact us at

Posted by Alvaro Teijeiro, CIO, Sonico

[Gd] Closing the Loop - Version Control and Issue Tracker Integration

| More

Google Code Blog: Closing the Loop - Version Control and Issue Tracker Integration

If you are a developer on an open source project hosted on Google Code, and you are committing a change that fixes a known defect or adds a requested enhancement, you will want to update the associated issue. You could do that by first committing the change, and then using the web UI to update the issue. But, now there is a more convenient way to close the loop: you can update an issue by putting an issue tracker command in your commit-log message.

There are commit-log commands to:
  • Easily set an issue's status to Fixed.
  • Update any aspect of the issue, and add a comment.
  • Enter a new issue.
  • Request a code review.
The most common case is to close the issue as Fixed. For example, your commit-log message might be:

Now, your commit links to the issues, the issues are closed, and a back-link is added from each issue to the revision.

Updating an issue, without closing it, can be useful when a commit partially resolves the issue. And, opening a new issue is useful when you know that follow-up work will be needed. For more information and examples, see our issue tracker documentation.

By Jason Robbins, Google Code Team

Thursday, May 14, 2009

[Gd] The importance of being unsociable

| More

iGoogle Developer Blog: The importance of being unsociable

A lot of the content we post on this blog is about social. Social is new, social is big, social is better (all true!) ... but, non-social is important too, and gadgets should behave gracefully when users have not enabled social features, or they aren't available. Not only is a large part of iGoogle's userbase not signed in, but when users add a new gadget to their pages, for the first time, it is always added without social features enabled. Users enable the social ACLs in a separate step, after the gadget has been added to the page.

Until they do that, the gadget will be rendered without social access - meaning that every single user will see your gadget without social access at least once. Plan for it! Make sure you can handle that case, even if you only display a message prompting users to sign in and enable social access so that your gadget can operate correctly.

For help with detecting whether a user's social functionality has been enabled and other iGoogle-specific OpenSocial questions, check out the Testing iGoogle State gadget. This cribsheet builds on the OpenSocial tutorial to provide a rapid way to look up example code for common social gadget tasks.

Many of the folks who contribute to OpenSocial and iGoogle will be at Google I/O in San Francisco on May 27-28. We love to talk about this stuff, so check out the Google I/O site to sign up and join us.

Posted by Tyler Odean, Associate Product Manager, iGoogle

[Gd] Beta Update: Bug fixes and translations

| More

Google Chrome Releases: Beta Update: Bug fixes and translations

Google Chrome has been released to the Beta channel. This release adds translations for all new features in all supported languages. We've made a number of fixes to improve reliability and updated the version of Gears to

You can install the current Beta channel release from

Mark Larson
Google Chrome Program Manager


[Gd] Client Library Updates: Part 1

| More

AdWords API Blog: Client Library Updates: Part 1

There are a lot of changes going on with the AdWords API lately and we'd like to take a minute to talk about what else we have in store. In recent news, we released the API v2009 Sandbox and we appreciate all the great feedback we are getting (keep it coming!). With the release the v200902 API, we also have begun updating the client libraries for each of the supported languages. The client libraries have always made it simple for both first time developers and experts to use our API and we are now adding even more features to improve your API experience.

Above all, we want to allow you to experiment with the API v2009 Sandbox while still being able to make production calls to the v13 version. To that extent, each client library now has cross-version compatibility so that v200902 code and v13 code can be run together. It still stands, though, that v200902 can only operate within the Sandbox. Included in each client library are some examples showing you how to use the v13 code along with v200902 to supplement your learning.

In addition to our existing list of supported client libraries, a new Perl client library, found here, has been developed specifically for use with v200902. This library does not include support for the v13 services, but it does offer most of the functionality that our other client libraries offer.

The support for v200902 in the APIlity (PHP) client library is in the works as well.

Here's some other features that you'll find in the new refresh of each client library:

  • Improved logging support.
  • Reports can now be downloaded through the client library.
  • Full support for UTF-8 encoding.
  • Thread-safe architecture.

As always, you can find a list of supported client libraries here:

We'll be releasing more features as the client library update continues, so stay tuned!

-- Adam Rogal, AdWords API Team


[Gd] Yahoo! Pipes and <canvas>

| More

Google Code Blog: Yahoo! Pipes and <canvas>

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Paul Donnelly and Jonathan Trevor of the Yahoo! Pipes team.

Yahoo! Pipes is a free online service that lets you remix popular feed types (json, xml, rss, and atom) and create data mashups using a visual editor. You can use Pipes to run your own web projects, or publish and share your own web service without ever having to write a line of code. Pipes also allows you to create feeds from web sites that don't provide RSS/XML by extracting data straight from the HTML document. In this post, we'll talk about how the Pipes editor uses the HTML5 canvas tag extensively, challenges we faced using the canvas tag and a few solutions we came up with to address said challenges.

Pipes is widely known for its visual editor that allows you to drag pre-configured modules onto its canvas and wire them together:

We use the canvas tag to create the fluid, draggable wiring to connect modules. The thumbnails of Pipes on the Browse and My Pipes sections aren't jpegs - we use canvas to "draw" them dynamically from the Pipe definition.

Since the iPhone's web browser supports the canvas tag, we were able to use the same code to generate the thumbnails for our iPhone version.

The Pipes editor is where all the visual programming is done. By dragging modules to the workspace, you can set up a visual workflow of what you want processed. To complete the flow, you need to connect the modules in the sequence you want. At the bottom or top of the modules are terminals, where you connect the wires from one to the other. The terminals are typed, meaning you can only connect an output to an input that has the same type.

The canvas tag is a HTML tag that provides a fixed drawing area that can be used to draw graphics. The tag is manipulated using Javascript to create 2D drawing primitives such as lines, circles, polygons and even gradients. While many browsers support the canvas tag natively, some do not. For example, IE does not support canvas natively. To address this, IE uses a canvas wrapper, excanvas (created by Google) to ensure full cross-browser compatibility.

The canvas tag enabled us to leverage the built-in capabilities of CSS and the DOM for the rest of the interface while still providing us with 2D drawing capabilities. We observed a few issues with the canvas tag that developers should be cognizant of when considering to use it in their applications:
  • There are cross-browser issues related to resizing the canvas tag once it's been created. In Firefox you're ok. In Safari, you need to destroy and re-create the region to get the canvas to draw properly. With IE, the region doesn't clear and redraw automatically.

  • In the canvas element you can't say, "this line being drawn should be this class". There is no separation between the presentation and the markup. It has to be programmatically done and it's cumbersome to keep tweaking JS code to change the look and feel of what is being rendered. So how do you tell the canvas what style of wire to draw? We chose to use the styles of the source and target terminals to infer the wire styles in their CSS. We put the configuration of the wire style (color, width, thickness etc..) into the background image filename of each terminal which the JavaScript could parse to create a compatible render style for our canvas wires.

  • Performance rapidly decreases with size, especially with other overlapping DOM elements such as many transparent elements and other canvas tags. There is a tradeoff therefore between using one canvas tag with many wires or one canvas for each wire. The latter worked better for our usage within the Pipes editor.

  • There are no "canvas" events about the "inside" of the canvas, It's just a 2D layer, and mixing DOM elements with canvas has significant event occlusion issues. Even if you are only drawing a wire within the canvas rectangle, anything under the canvas won't see events (mouseover, click etc) as the bounding box acts like any other element. This issue involved the most iterations in our interaction design. Initially we wanted the wires above the modules, but because of the event occlusion that the canvas tag created, we couldn't do a drag/drop (since the targets were always "under" the canvas). Since the wires had to be on the bottom, we then tried making the Pipes' modules themselves semi-transparent. Not only does this give a faded out look to the whole page, but many transparent elements create significant rendering performance issues. We finally picked a solution that kept the wires under the modules and when mouse-overing the canvas containing the wire bounding box, we made the modules connected to either end of the wire in the canvas semi-transparent using animation. This allows parts of the UI to show the wiring flowing around and under modules when the user focuses (by moving the mouse over) on a wire.

If you would like to learn more and talk with us about the pros and cons of canvas and some of the interesting challenges above, visit us at the Developer Sandbox at Google I/O coming up in a couple weeks.

By Paul Donnelly and Jonathan Trevor of the Yahoo! Pipes Team

[Gd] Google OpenID API - taking the next steps

| More

Google Code Blog: Google OpenID API - taking the next steps

Six months ago, we announced our first step in supporting single sign-on using OpenID. Well, we wanted to share with you what we have been working on since. As a strong supporter of open standards such as OpenID, Google's top priority in this area has been to join the OpenID community in its efforts to increase the adoption of the protocol by both Relying Party websites and end users. In order to achieve that goal, we have been experimenting with new ways to improve OpenID usability and extend its functionality.

Our first enhancement, announced in January 2009, was to introduce the "Hybrid Protocol" API - combining OpenID's federated login with the OAuth access authorization. The Hybrid Protocol allows websites to ask Google to authenticate a user through their Google Account, while at the same time requesting access to information available via OAuth - enabled APIs such as the Google Data APIs. By combining the two protocols together, the Relying Party provides a better overall user experience and significantly reduces latency by cutting down the number of browser redirects and roundtrips. Plaxo, one of the websites using the Hybrid Protocol, published a presentation pointing out an amazing 92% success rate while experimenting with the API.

We are happy to announce today two new enhancements to our API - introducing a new popup style UI for our user facing approval page, and extending our Attribute Exchange support to include first and last name, country and preferred language.

The new popup style UI, which implements the OpenID User Interface Extension Specification, is designed to streamline the federated login experience for users. Specifically, it's designed to ensure that the context of the Relying Party website is always available and visible, even in the extreme case where a confused user closes the Google approval window. JanRain, a provider of OpenID solutions, is an early adopter of the new API, and already offers it as part of their RPX product. As demonstrated by UserVoice using JanRain's RPX, the initial step on the sign-in page of the Relying Party website is identical to that of the "full page" version, and does not require any changes in the Relying Party UI.

Once the user selects to sign in using his or her Google Account, the Google approval page is displayed. However, it does not replace the Relying Party's page in the main browser window. Instead it is displayed as a popup window on top of it. We have updated our Open Source project to include a complete Relying Party example, providing code for both the back-end (in Java) and front-end (javascript) components.

Once the user approves the request, the popup page closes, and the user is signed in to the Relying Party website.

Note that the popup style UI does not replace Google's existing full-page version, nor does it change the current behavior of our existing Relying Parties. It is up to the Relying Party to decide which of the two available formats they prefer, and modify their OpenID request accordingly as defined in the Google API Documentation.

As you can see in the screenshots provided, the user is not just signing in using her Google Account, but is also sharing specific information from her Google Account with the Relying Party website. This information may be either static fields (using Attribute Extension) such as the user's email, first and last name, preferred language and country, or allowing access to any available Google Data API such as the user's Contacts List, Web Albums, or Calendar (using OAuth). Google strongly believes that the data our users trust us with belongs to them and should always be available for them to use. By providing users with more secure means to share their data, they can benefit from a much more streamlined, personalized and socially relevant experience when they log in to trusted websites. At the same time, Relying Parties can significantly simplify their account creation and sign-in flows, resulting in happier users and higher successful registration rates.

If you want to know what's coming next and impact what the future advancements are, you are welcome to join the OpenID and OAuth mailing lists.

By Yariv Adan, Google Security Team

Wednesday, May 13, 2009

[Gd] Java SDK version 1.2.1 now available

| More

Google App Engine Blog: Java SDK version 1.2.1 now available

Version 1.2.1 of the App Engine SDK for Java is now available to download. This was the first update to our new Java language support and includes a number of bug fixes and feature additions including:

  • Support for unindexed datastore properties of arbitrary types
  • Embedded UTF-8 characters in JSPs now render correctly
  • Increase in response size limit from 1MB to 10MB
  • Support for Thread.setContextLoader()

There are a host of updates for the JDO/JPA layer as well. The project wiki has a full list of fixes and new features.

As always, we're very interested in your feedback with the SDK, especially during this early look period -- please feel free to share your experiences in the Java runtime discussion group.

Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.

Posted by Jason Cooper, App Engine Team


[Gd] Gmail for mobile HTML5 Series - Part 3: Using AppCache to Launch Offline

| More

Google Code Blog: Gmail for mobile HTML5 Series - Part 3: Using AppCache to Launch Offline

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. In the last two posts, we covered everything you need to know in order to make effective use of AppCache. This week, we'll be having some fun and trying to disect the inner workings of AppCache by looking at the database it uses to store its resources. Before we start though, I'd like to point out one tip that can be useful while debugging AppCache related problems on the iPhone: how to clear your Application Cache.

There are two steps involved here:
  1. Go to Settings->Safari and tap "Clear Cache".
  2. Open Safari and terminate it by holding down the home screen button for 10 seconds.
The first step is pretty intuative. The problem is that the browser does not immediately notice that the cache has been cleared, and so needs to be restarted.

Now onto the fun stuff! There is no way to inspect the application cache from within the browser. However, if you are using the iPhone Simulator to develop your webapp, you can find all of the Application Cache resources and metadata in a SQLite3 database located at:

~/Library/Application Support/iPhone Simulator/User/Library/Caches/

Let's have a look at what is contained within this database.

$ sqlite3 ApplicationCache.db
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .mode column
sqlite> .headers on
sqlite> .tables
CacheEntries CacheResourceData CacheWhitelistURLs FallbackURLs
CacheGroups CacheResources Caches SchemaVersion
sqlite> select * from CacheGroups;
id manifestHostHash manifestURL newestCache
---------- ---------------- ------------------------------------------------- -----------
1 906983082 1

The CacheGroups table holds an overview of what manifests exist. A manifest is identified by its URL and the manifestHostHash is used to track when the contents of a manifest changes.

sqlite> select * from Caches;
id cacheGroup
---------- ----------
1 1

Here you can see that I have only one cache in my database. If the Application Cache was in the middle of updating the cache, there would be a second entry listed here for the cache currently being downloaded.

sqlite> select * from CacheEntries limit 1;
cache type resource
---------- ---------- ----------
1 2 1

The CacheEntries table holds a one-to-many relationship between a cache and resources within it.

sqlite> select * from CacheResources where id=1;
id url statusCode responseURL
---------- ------------------------------------------- ---------- -----------------------
1 200

mimeType textEncodingName headers data
------------------- ---------------- --------------
text/cache-manifest utf-8

sqlite> .schema CacheResourceData

This shows what information is stored for each resources listed in a manifest. As you can see the CacheResources and CacheResourceData tables contain everything that is needed in order to simulate a network response to a request for a resource. Let's see exactly what is stored in the database for Mobile Gmail's database.

sqlite> select type,url,mimeType,statusCode from CacheEntries,CacheResources where resource=id;
type url mimeType statusCode
---------- ---------------------------------------------- ------------------- ----------
2 text/cache-manifest 200
4 image/gif 200
4 image/gif 200
4 image/gif 200
4 image/gif 200
4 image/gif 200
4 image/gif 200
1 text/html 200
4 image/gif 200
4 image/gif 200
4 image/gif 200
4 image/gif 200

From this list, it is fairly easy to see what the meaning of the type field is. A host page has type 1, a manifest has type 2, and a normal resource has type 4. In order to know whether or not to load a page using AppCache, the browser checks this list to see if there is a URL of type 1 within it.

This concudes our three-part series on HTML5's Application Cache. Stay tuned for the next post where we will explore other areas of how we use HTML5 in Gmail. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.

The HTML5 working draft:

Apple's MobileSafari documentation:

Webkit Source Code:

By Andrew Grieve, Software Engineer, Google Mobile

[Gd] AdWords Downtime: May 16, 10am-2pm PDT

| More

AdWords API Blog: AdWords Downtime: May 16, 10am-2pm PDT

We'll be performing routine system maintenance on Saturday, May 16 from approximately 10:00am to 2:00pm PDT. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

-Jeffrey Posnick, AdWords API Team

Tuesday, May 12, 2009

[Gd] Dev Channel Updated with Bug Fixes

| More

Google Chrome Releases: Dev Channel Updated with Bug Fixes

Google Chrome has been updated to on the dev channel.

Version Changes:


Visible changes:
  • [r14827] Support PgUp/PgDn in Omnibox for "first entry/last entry." (Issue: 6857)
  • [r15115] Tell the user if Chrome is not the default browser. (Issue: 9049)
  • [r15702] You can choose to allow pop-ups from a site. (Issue: 11440)
Other changes of note:
  • [r14891] Fix for crashing when zoomed into street level on (Issue: 2044)
  • [r14731] Patch from Mohamed Mansour for systems without an installed printer. (Issue: 6835)
  • [r15020] Stop the location bar from flashing white when navigating from one HTTPS site to another. (Issue: 11157)
  • [r15214] Fix for common issues around opening a new window. (Issues: 63776192835)
  • Lots of work around Extensions.  (See r15417, r15271, r15310)
The release notes are available as well as a detailed list of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

--Jonathan Conradt
Google Chrome Program Manager

[Gd] Spring time design refresh!

| More

Official Google Webmaster Central Blog: Spring time design refresh!

We've been listening to you at conferences, user studies, forums and blogs and we decided to start from the ground up with a brand new Webmaster Tools design! It was much needed, and the end result is beautiful in our eyes:

  • One-stop Dashboard: We redesigned our dashboard to bring together data you view regularly: Links to your site, Top search queries, Sitemaps, and Crawl errors.
  • More top search queries: You now have up to 100 queries to track for impressions and clickthrough! In addition, we've substantially improved data quality in this area.
  • Sitemap tracking for multiple users: In the past, you were unable to monitor Sitemaps submitted by other users or via mechanisms like robots.txt. Now you can track the status of Sitemaps submitted by other users in addition to yourself.
  • Message subscription: To make sure you never miss an important notification, you can subscribe to Message Center notifications via e-mail. Stay up-to-date without having to log in as frequently.
  • Improved menu and navigation: We reorganized our features into a more logical grouping, making them easier to find and access. More details on changes.
  • Smarter help: Every page displays links to relevant Help Center articles and by the way, we've streamlined our Help Center and made it easier to use.
  • Sites must be verified to access detailed functionality: Since we're providing so much more data, going forward your site must be verified before you can access any features in Webmaster Tools, including features such as Sitemaps, Test Robots.txt and Generate Robots.txt which were previously available for unverified sites. If you submit Sitemaps for unverified sites, you can continue to do so using Sitemap pings or by including the Sitemap location in your robots.txt file.
  • Removal of the enhanced Image Search option: We're always iterating and improving on our services, both by adding new product attributes and removing old ones. With this release, the enhanced Image Search option is no longer a component of Webmaster Tools. The Google Image Labeler will continue to select images from sites regardless of this setting.
Go ahead, get started

The new user interface is available at The old user interface will continue to be available for a couple of weeks to give you guys time to adjust and provide feedback.

We did our best to get the product localized; however, you may notice a few missing translations in some areas of the user interface. We apologize for the inconvenience and when we switch everyone over in a couple of weeks, we'll fully support 40 languages. The one exception will be our Help Center, which will be available in 21 languages going forward.

We're really excited about this launch, and hope you are as well. Tell us what you think and stay tuned for more updates!

Posted by Sagar Kamdar, Product Manager, and Josh Teague, Interaction Designer, Webmaster Tools Team

[Gd] SVG Open 2009: “SVG coming of age”

| More

Google Code Blog: SVG Open 2009: “SVG coming of age”

Scalable Vector Graphics (SVG) is starting to pop up over all the place. It's showing up natively in browsers (including Firefox, Safari, Opera, Chrome and more). It's natively supported on the iPhone, and work is happening in various open source communities to create options for Internet Explorer. Google uses it under the covers in Google Maps (to create vector line drawings showing where to go); Google Docs (for drawing into presentations); and more. Wikipedia has a huge repository of SVG images, while many tools such as Inkscape, Illustrator, and Visio can either export to SVG or work with it natively. Vector graphics support through SVG and Canvas is consistently one of the top voted requests by developers.

Since we use and support SVG we thought it would be great to work with the community to host the SVG Open 2009 conference this fall. SVG Open will be in Mountain View at the Google campus from October 2-4, 2009. The theme this year is "SVG coming of age".

We are looking for contributors to present papers or teach courses. Presenters are asked to submit an extended abstract in English with an approximate length of 400 to 800 words by May 15. The abstracts are reviewed by a reviewing committee and presenters will be informed about acceptance on or before June 26. If your abstract is accepted, you will be asked to submit your full paper by August 31, according to instructions that will be sent to you.

Come and join us in the fall at SVG Open!

By Brad Neuberg, Open Web Advocacy Team

[Gd] Enabling Rich Snippets in Custom Search

| More

Google Custom Search: Enabling Rich Snippets in Custom Search

Posted by: Rajat Mukherjee, Group Product Manager and Nicholas Weininger, Software Engineer

Today, we announced Rich Snippets for Google web search, a new presentation of snippets that highlight structured data embedded in web pages. Rich Snippets provide summary information, including important page-specific attributes, to help you quickly identify the relevance of your results. Experiments on Google have shown that people find this additional data valuable -- if they see useful and relevant information from a webpage, they are more likely to click through to it. Our web search team is currently experimenting with a limited set of attributes for reviews and user profiles that webmasters can provide through in-line markup in their web pages by using open standards such as microformats or RDFa.

Since Custom Search sits on top of the Google web search platform, we're enabling Rich Snippets for custom search engines too. In fact, Custom Search provides support for richer snippets; you can define your own custom attributes that we'll index and return with your custom search results. In addition to microformats and RDFa, you can also provide custom metadata within your web pages via special markup called page maps. A page map identifies specific attributes that are recognized and preserved by Google at index time, and returned along with search results for presentation.

So, if you're using Custom Search or Site Search on your website, you can now control further how your content appears in search results. You can showcase key information -- such as image thumbnails, summaries, ratings, and prices -- in your result snippets if you provide the appropriate markup on your pages. As in the example shown below, displaying specific attributes can make the snippet more useful for shoppers.

At this time, Rich Snippets attribute information for Custom Search is only returned in XML (via <PageMap> tags), so you can use your own customized presentation controls. We're looking to make this easier for you in the future. Indexing of the rich snippets information can have unspecified latency, as some pages are indexed and refreshed more frequently than others, and page map attributes may not be indexed from all web pages.

As an illustration, the web page featured in the following example provides custom information about an image thumbnail that is displayed in the rich snippet of the result along with date, author and category information.

A sample page map for the above example defines custom attributes that are encoded in DataObject tags via the following markup:

<dataobject type="image">
<attribute name="image_src" value="">
<dataobject type="publication">
<attribute name="author" value="John Tagliabue">
<attribute name="date" value="March 14, 2009">
<attribute name="category" value="Business/World Business">

If you are getting results back via XML, then the custom attributes are returned in the results within the PageMap tag, as shown below. You can parse the DataObjects within the PageMap tag and provide customized presentation of the relevant attributes.

<r n="1">
<u> </u>
<t> In Italy, a Vending Machine Even Makes the <b>Pizza</b> </t>
The European vending machine industry has annual sales of about #33 billion, much of it coming from factories and offices.
<dataobject type="image">
<attribute name="image_src" value="">
<dataobject type="publication">
<attribute name="author" value="John Tagliabue">
<attribute name="date" value="March 14, 2009">
<attribute name="category" value="Business/World Business">

Let us know if you have feedback about custom Rich Snippets. For more information, join us for a discussion on Advanced Custom Search Configuration at Google I/O on May 27.

[Gd] Introducing Rich Snippets

| More

Official Google Webmaster Central Blog: Introducing Rich Snippets

Webmaster Level: All

As a webmaster, you have a unique understanding of your web pages and the content they represent. Google helps users find your page by showing them a small sample of that content -- the "snippet." We use a variety of techniques to create these snippets and give users relevant information about what they'll find when they click through to visit your site. Today, we're announcing Rich Snippets, a new presentation of snippets that applies Google's algorithms to highlight structured data embedded in web pages.

Rich Snippets give users convenient summary information about their search results at a glance. We are currently supporting data about reviews and people. When searching for a product or service, users can easily see reviews and ratings, and when searching for a person, they'll get help distinguishing between people with the same name. It's a simple change to the display of search results, yet our experiments have shown that users find the new data valuable -- if they see useful and relevant information from the page, they are more likely to click through. Now we're beginning the process of opening up this successful experiment so that more websites can participate. As a webmaster, you can help by annotating your pages with structured data in a standard format.

To display Rich Snippets, Google looks for markup formats (microformats and RDFa) that you can easily add to your own web pages. In most cases, it's as quick as wrapping the existing data on your web pages with some additional tags. For example, here are a few relevant lines of the HTML from Yelp's review page for "Drooling Dog BarBQ" before adding markup data:

and now with microformats markup:

or alternatively, use RDFa markup. Either format works:

By incorporating standard annotations in your pages, you not only make your structured data available for Google's search results, but also for any service or tool that supports the same standard. As structured data becomes more widespread on the web, we expect to find many new applications for it, and we're excited about the possibilities.

To ensure that this additional data is as helpful as possible to users, we'll be rolling this feature out gradually, expanding coverage to more sites as we do more experiments and process feedback from webmasters. We will make our best efforts to monitor and analyze whether individual websites are abusing this system: if we see abuse, we will respond accordingly.

To prepare your site for Rich Snippets and other benefits of structured data on the web, please see our documentation on structured data annotations.

Now, time for some Q&A with the team:

If I mark up my pages, does that guarantee I'll get Rich Snippets?

No. We will be rolling this out gradually, and as always we will use our own algorithms and policies to determine relevant snippets for users' queries. We will use structured data when we are able to determine that it helps users find answers sooner. And because you're providing the data on your pages, you should anticipate that other websites and other tools (browsers, phones) might use this data as well. You can let us know that you're interested in participating by filling out this form.

What about other existing microformats? Will you support other types of information besides reviews and people?

Not every microformat corresponds to data that's useful to show in a search result, but we do plan to support more of the existing microformats and define RDFa equivalents.

What's next?

We'll be continuing experiments with new types (beyond reviews and people) and hope to announce support for more types in the future.

I have too much data on my page to mark it all up.

That wasn't a question, but we'll answer anyway. For the purpose of getting data into snippets, we don't need every bit of data: it simply wouldn't fit. For example, a page that says it has "497 reviews" of a product probably has data for 10 and links to the others. Even if you could mark up all 497 blocks of data, there is no way we could fit it into a single snippet. To make your part of this grand experiment easier, we have defined aggregate types where necessary: a review-aggregate can be used to summarize all the review information (review count, average/min/max rating, etc.).

Why do you support multiple encodings?

A lot of previous work on structured data has focused on debates around encoding. Even within Google, we have advocates for microformat encoding, advocates for various RDF encodings, and advocates for our own encodings. But after working on this Rich Snippets project for a while, we realized that structured data on the web can and should accommodate multiple encodings: we hope to emphasize this by accepting both microformat encoding and RDFa encoding. Each encoding has its pluses and minuses, and the debate is a fine intellectual exercise, but it detracts from the real issues.

We do believe that it is important to have a common vocabulary: the language of object types, object properties, and property types that enable structured data to be understood by different applications. We debated how to address this vocabulary problem, and concluded that we needed to make an investment. Google will, working together with others, host a vocabulary that various Google services and other websites can use. We are starting with a small list, which we hope to extend over time.

Wherever possible, we'll simply reuse vocabulary that is in wide use: we support the pre-existing vCard and hReview types, and there are a variety of other types defined by various communities. Sites that use Google Custom Search will be able to define their own types, which we will index and present to users in rich Custom Search results pages. Finally, we encourage and expect this space to evolve based on new ideas from the structured data community. We'll notice and reach out when our crawlers pick up new types that are getting broad use.

Written by Kavi Goel, Ramanathan V. Guha, and Othar Hansson

Monday, May 11, 2009

[Gd] Bespin: an experiment in giving developers a productive and fun environment on the Open Web

| More

Google Code Blog: Bespin: an experiment in giving developers a productive and fun environment on the Open Web

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Dion Almaer of Mozilla's Bespin project

It feels good to be posting on the Google Code blog again. Since moving down the road from Google to Mozilla I have been busy working with my partner in crime, Ben Galbraith, in a new Developer Tools Lab.

The first product of our new team's endeavors was an experiment code named the Bespin project. Ben and I have been talking about the great things that you can do on the Web platform for quite some years. We feel like there is a big sea change happening right now as the various browsers kick into a new gear with fantastic features. The core runtimes on the Web (the browsers) are getting serious horse power. With technologies such as Web Workers, Canvas, advanced caching (application cache), local storage, native video / audio, and screaming fast JavaScript VMs, we feel that a new world of possibilities is going to hit the Web.

It wasn't too long ago that we saw this before, when Ajax hit the Internet and we went from simple applications to richer ones such as Google Maps and Gmail.

We wanted to test out this theory, so we set about creating a new age application that uses the great new technologies stated earlier. Since we are a developer tools lab, would it not make sense for this experiment to be a developer tool? And, what is the grand daddy of all developer tools? The coding environment that developers use to build applications. How "meta" :)

Being Mozilla, we released a very early version of Bespin that is 100% open source, so the community could form. It has been a fantastic ride even in the short opening months. The editor is fully Web based, and "by the Web, on the Web." Being a former Emacs Lisp hacker, I have known how powerful it is to have an environment that you can change for your own work flow, using a language that you know and love. Why shouldn't today's world of Web developers be able to have a great tool that they can change using Web technology? Yet another reason for Bespin.

We have just released version 0.2 of Bespin, and it has features such as version control built in, rich syntax highlighting, real-time code analysis, a command line that that you can create your own commands for, and a fancy dashboard. We are proud of where we are in short order, but there is much to be done. In the lab we have collaboration support in place and will be deploying soon. We are incredibly excited about some exciting use cases. Wouldn't it be interesting if:
  • You could "follow" a developer and see how he codes? I would love to follow Brendan Eich, the creator of JavaScript, as he hacks on TraceMonkey!
  • You could do a live code review with someone, and both edit the code in place, a la SubEthaEdit or Google Docs?
  • Have a chat session that associates itself with the code files, so you can go back and see the conversations around a bit of code?
  • You were told that someone else is editing in the same file so you can quickly commit the code so they have to do the merge :P
  • You could search and subscribe to others commands, which will then be automatically updated for you
  • And much much more, as you can see on our Roadmap
To see more about Bespin, check out our video, or visit our community home:


This is the first of many tools that will come out of our lab. It is important to note that these tools are for the Open Web as a whole. Just because we are at Mozilla doesn't mean that we only care about Firefox, far from it. Bespin itself runs on multiple bleeding edge browsers!

I am very excited to have been asked back to Google I/O (May 27-28) to speak not only about Bespin, but about the Open Web platform itself. I can't wait to share more of our community's work pushing the Open Web forward, and would love feedback on our projects and what you really need from us as developers. Hope to see you in May!

By Dion Almaer, Developer Tools Lab at Mozilla

[Gd] web2py support, new datastore backend for apps, and more!

| More

Google App Engine Blog: web2py support, new datastore backend for apps, and more!

It has been an exciting month and a half for App Engine since the last community update. In addition to two SDK updates, Cron support, new Java runtime, etc., there have been a host of noteworthy community developments as well, only a few of which are mentioned below.

web2py Python framework now supports App Engine
We are always interested in frameworks that natively support App Engine, and the web2py framework recently came to our attention. Completely written in Python, web2py is described as a "free and open source full-stack enterprise framework for agile development of fast, secure and portable database-driven web-based applications." If your framework has native App Engine support let us know and we'll include you in a future blog post.

Alternative datastore backend for App Engine applications released
bdbdatastore is an alternative datastore backend for App Engine applications. Now at version 0.2, bdbdatastore has complete feature parity with the App Engine's production datastore, meaning you can run your App Engine application on your own hardware with bdbdatastore as the storage backend without having to change any of the code written previously to access App Engine's native datastore. Intended primarily for developers who want to host their own App Engine-based apps, bdbdatastore manages to be far more robust and scalable than the datastore included with the development server while being more manageable than larger backends like HBase and HyperTable.

App Engine supports White House town hall meeting
In late March, the White House hosted an online town hall meeting, soliciting questions from concerned citizens directly through its website. To manage the large stream of questions and votes, the White House used Google Moderator, which runs on App Engine. At its peak, the application received 700 hits per second, and across the 48-hour voting window, accepted over 104,000 questions and 3,600,000 votes. Despite this traffic, App Engine continued to scale and none of the other 50,000 hosted applications were impacted.

For more on this project, including a graph of the traffic and more details on how App Engine was able to cope with the load, see the Google Code blog.

App Engine "Sprint" held in Taipei
The Taipei App Engine Sprint was a coding event at Google Taipei office in mid-March. Seventeen Python developers split into five teams and worked for 10 hours straight to build a new application from scratch. in 10 hours. The winning application, Sight History, is a Picasa search-based application which displays a time distribution chart, slide show links, and a Google Map for photos queried from Picasa Web Albums. Only one of the four developers on this team was an active web developer, which illustrates how easy it can be to turn a good idea into a working web application with App Engine and other Google APIs.

Earth Hour 2009 site hosted on App Engine
Earth Hour, an initiative of WWF, encourages individuals, businesses, and governments to turn off their lights for one hour to show their support for action on climate change. The site aims to raise awareness of climate change and to show people and companies how easy it is to take action to avoid global warming. After launching this past December on App Engine, the site was able to scale seamlessly to handle over 450 hits per second during the Earth Hour event on March 28, making it one of the top App Engine applications served that day.

Posted by Jason Cooper, Google App Engine Team