Friday, November 5, 2010

[Gd] An Ingredients List for Testing - Part Six

| More

Google Testing Blog: An Ingredients List for Testing - Part Six

By James Whittaker

The sixth ingredient is variation. Tests often get stale (i.e., they stop finding bugs) as they are run over and over on build after build as a product is being constructed. On the one hand, it is important to continue running tests to ensure the product still operates as specified. Indeed, I hesitate to throw any test away. However, becoming reliant on stale tests is too risky. Adding variation to existing tests can range from straightforward reordering of the sequence in which tests are run to more involved solutions of either modifying tests or adding new ones. Hopefully new tests will increase overall coverage and add to our confidence that we’ve tested the software in all the ways it needs to be tested.
URL: http://googletesting.blogspot.com/2010/11/ingredients-list-for-testing-part-six.html

[Gd] Introducing the Advocate Bios and Developer Events pages

| More

Google Code Blog: Introducing the Advocate Bios and Developer Events pages

We know that developers are always interested in learning about new APIs and best practices for existing ones. And, one of the best ways to learn is face to face interaction with an expert in the subject.

Your friendly neighborhood Google Developer Relations team members work everyday with the APIs you care about. We host, as well as attend, a number of events around the world to help as many developers as possible throughout the year. However, it hasn’t been easy for interested developers to find relevant events close to them.

We also realized that while many developers have met at least a couple of our Developer Advocates, it’s hard to tie an Advocate to their API expertise.

Enter the Advocate Bios and Developer Events pages.

The Advocates Bios page provides names, pictures and short descriptions of Developer Relations team members. You can filter them by what they work on and/or where they’re based out of.

The Developer Events page is a mashup of the Calendar and Maps APIs, running on an App Engine backend. Want to know about upcoming Android events in Prague? Or whether Patrick Chanezon is speaking at the GDD in Munich on Nov 9th? (He is!) You can do all of that and more with the Developer Events page.

Both the bios and the events pages are conveniently linked under the Developer Resources section on the Google Code home page.

We hope to see you at the events!

By Peng Ying and Swapneel Kshetramade, Google Developer Relations Team
URL: http://googlecode.blogspot.com/2010/11/introducing-advocate-bios-and-developer.html

[Gd] Update to the ClientLogin URL

| More

YouTube API Blog: Update to the ClientLogin URL

We want to let the developer community know about a change to the officially supported URL for YouTube API ClientLogin requests. Previously, developers who wanted to obtain authentication credentials via a username and password had to send their ClientLogin request to https://www.google.com/youtube/accounts/ClientLogin. The new URL that we encourage all developers to use is https://www.google.com/accounts/ClientLogin. This new URL has been functional for a while, and is the same URL that other Google APIs use for ClientLogin requests. Switching YouTube API ClientLogin traffic to the standard URL ensures that developers across all of Google’s APIs will see standard behavior when logging users in.

All of the details regarding this switch as well as best practices for performing ClientLogin requests can be found in our YouTube API documentation. There is one specific change in behavior that is worth calling out: responses from the new ClientLogin URL will not include the YouTube username of the authenticated user, which the old URL’s responses did provide. We encourage developers to take advantage of the username default when constructing YouTube API request URLs, which always refers to the currently logged in user.

We have no immediate plans to disable the old ClientLogin URL, but we do encourage developers to update their code at their earliest convenience to point to the new URL. We will post again with further details if and when the legacy URL is turned off.

Cheers,
-Jeff Posnick, YouTube API Team
URL: http://apiblog.youtube.com/2010/11/update-to-clientlogin-url.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Chrome Dev channel has been updated to 9.0.570.1 for Windows, Linux, and Chrome Frame. This release contains a new version of Flash. The Dev channel for Mac has been updated to 9.0.572.0 which has a new version of Flash and fixes one of the top crashers (Issue: 61446)

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

Want to change to another Chrome release channel? Find out how.

Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/11/dev-channel-update_04.html

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Chrome Beta channel has been updated to 8.0.552.28 for all platforms. 

This release contains a number of bug fixes, as well as features like our new bundled PDF viewer, more sync services, and improved plug-in handling. This release also contains a new version of Flash.

Full details about the changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.


Jason Kersey
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/11/beta-channel-update.html

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

Google Chrome has been updated to 7.0.517.44 for Windows, Mac, Linux and Chrome Frame on the Stable channel.  Along with the security fixes below, this build has an updated version of Flash.

Security fixes and rewards:

Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.

  • [51602] High Use-after-free in text editing. Credit to David Bloom of the Google Security Team, Google Chrome Security Team (Inferno) and Google Chrome Security Team (Cris Neckar).
  • [$1000] [55257] High Memory corruption with enormous text area. Credit to wushi of team509.
  • [$1000] [58657] High Bad cast with the SVG use element. Credit to the kuzzcc.
  • [$1000] [58731] High Invalid memory read in XPath handling. Credit to Bui Quang Minh from Bkis (www.bkis.com).
  • [$500] [58741] High Use-after-free in text control selections. Credit to “vkouchna”.
  • [$1000] [Linux only] [59320] High Integer overflows in font handling. Credit to Aki Helin of OUSPG.
  • [$1000] [60055] High Memory corruption in libvpx. Credit to Christoph Diehl.
  • [$500] [60238] High Bad use of destroyed frame object. Credit to various developers, including “gundlach”.
  • [$500] [60327] [60769] [61255] High Type confusions with event objects. Credit to “fam.lam” and Google Chrome Security Team (Inferno).
  • [$1000] [60688] High Out-of-bounds array access in SVG handling. Credit to wushi of team509.
Anthony Laforge
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/11/stable-channel-update.html

[Gd] Documents List API now supports more file types

| More

Google Apps Developer Blog: Documents List API now supports more file types

We are happy to announce that we have recently launched support for creating and managing revisions for arbitrary file types in the Documents List API. Prior to this, the Documents List API only allowed developers to create and query revisions of Google Docs files.

This opens up the API for a number of exciting use cases. For example, a developer could use Google Docs as the cloud-based back-end for a content-management system with versioning. Another possibility would be for developers to provide file history or file playback in their sync clients.

Please note, however, that while all users can use the API to query and manage revisions, currently only Google Apps Premier users can upload arbitrary file types via the API. All users are still able to upload arbitrary files types via the Google Docs web interface.

For more information on how to use this new feature, please see the updated release notes and updated documentation.

Posted by Russ Jorgensen, Google Docs Team

Want to weigh in on this topic? Discuss on Buzz

URL: http://googleappsdeveloper.blogspot.com/2010/11/documents-list-api-now-supports-more.html

Thursday, November 4, 2010

[Gd] How to help Google identify web spam

| More

Official Google Webmaster Central Blog: How to help Google identify web spam

Webmaster level: All

Everyone who uses the web knows how frustrating it is to land on a page that sounds promising in the search results but ends up being useless when you visit it. We work hard to make sure Google’s algorithms catch as much as possible, but sometimes spammy sites still make it into search results. We appreciate the numerous spam reports sent in by users like you who find these issues; the reports help us improve our search results and make sure that great content is treated accordingly. Good spam reports are important to us. Here’s how to maximize the impact of any spam reports you submit:

Why report spam to Google?

Google’s search quality team uses spam reports as a basis for further improving the quality of the results that we show you, to provide a level playing field for webmasters, and to help with our scalable spam fighting efforts. With the release of new tools like our Chrome extension to report spam, we’ve seen people filing more spam reports and we have to allocate appropriate resources to the spam reports that are mostly likely to be useful.

Spam reports are prioritized by looking at how much visibility a potentially spammy site has in our search results, in order to help us focus on high-impact sites in a timely manner. For instance, we’re likely to prioritize the investigation of a site that regularly ranks on the first or second page over that of a site that only gets a few search impressions per month. A spam report for a page that is almost never seen by users is less likely to be reviewed compared to higher-impact pages or sites. We generally use spam reports to help improve our algorithms so that we can not only recognize and handle this particular site, but also cover any similar sites. In a few cases, we may additionally choose to immediately remove or otherwise take action on a site.

Which sites should I report?

We love seeing reports about spammy sites that our algorithms have missed. That said, it’s a poor use of your time to report sites that are not spammy. Sites submitted through the spam report form are reviewed for spam content only. Sites that you think should be tackled for other reasons should be submitted to us through the appropriate channels: for example, for those that contain content which you have removed, use our URL removal tools; for sites with malware, use the malware report form; for paid links that you find on sites, use the paid links reporting form. If you want to report spammy links for a page, make sure that you read how to report linkspam. If you have a complaint because someone is copying your content, we have a different copyright process--see our official documentation pages for more info. There’s generally no need to report sites with technical problems or parked domains because these are typically handled automatically.

The same applies to redirecting legitimate sites from one top level domain to another, e.g. example.de redirecting to example.com/de. As long as the content presented is not spammy, the technique of redirecting one domain to another does not automatically violate the Google Webmaster Guidelines.


If you happen to come across a gibberish site similar to this one, it’s most likely spam.

The best way to submit a compelling spam report is to take a good look at the website in question and compare it against the Google Webmaster Guidelines. For instance, these would be good reasons to report a site through the spam report form:
  • the cached version contains significantly different (often keyword-rich) content from the live version
  • you’re redirected to a completely different domain with off-topic, commercial content
  • the site is filled with auto-generated or keyword-stuffed content that seems to make no sense
These are just a few examples of techniques that might be potentially spammy, and which we would appreciate seeing in the form of a spam report. When in doubt, please feel free to discuss your concerns on the Help Forum with other users and Google guides.

What should I include in a spam report?

Some spam reports are easier to understand than others; having a clear and easy-to-understand report makes it much easier for us to analyze the issue and take appropriate actions. Here are some things to keep in mind when submitting the spam report:
  • Submit the URLs of the pages where you see spam (not just the domain name). This makes it easy for us to verify the problem on those specific pages.
  • Try to specify the issue as clearly as possible using the checkboxes. Don’t just check every single box--such reports are less likely to be reviewed.
  • If only a part of the page uses spammy techniques, for example if it uses cloaking or has hidden text on an otherwise good page, provide a short explanation on how to look for the spam you’re seeing. If you’re reporting a site for spammy backlinks rather than on-page content, mention that.
By following these guidelines, your spam reports will be reproducible and clear, making them easier to analyze on our side.

What happens next?

After reviewing the feedback from these reports (we want to confirm that the reported sites are actually spammy, not just sites that someone didn’t like), it may take a bit of time before we update our algorithms and a change is visible in the search results. Keep in mind that sometimes our algorithms may already be treating those techniques appropriately; for instance, perhaps we’re already ignoring all the hidden text or the exchanged links that you have reported. Submitting the same spam report multiple times is not necessary. Rest assured that we actively review spam reports and take appropriate actions, even if the changes are not immediately visible to you.

With your help, we hope that we can improve the quality of and fairness in our search results for everyone! Thank you for continuing to submit spam reports and feel free to post here or in our Help Forum should you have any questions.

Written by Kaspar Szymanski, Search Quality Strategist & John Mueller, Webmaster Trends Analyst
URL: http://googlewebmastercentral.blogspot.com/2010/11/how-to-help-google-identify-web-spam.html

Wednesday, November 3, 2010

[Gd] Test your app from right to left

| More

Google Testing Blog: Test your app from right to left

Can you spot the error in the following webpage?


Unless you are one of the 56 million Internet users who read Arabic, the answer is probably no. But BidiChecker, a tool for checking webpages for errors in handling of bidirectional text, can find it:


Oops! The Arabic movie title causes the line to be laid out in the wrong order, with half of the phrase "57 reviews" on one side of it and half on the other.

As this example demonstrates, text transposition errors can occur even if your web application is entirely in a left-to-right language. If the application accepts user input or displays multilingual content, this data may be in one of the right-to-left languages, such as Arabic, Hebrew, Farsi or Urdu. Displaying right-to-left text in a left-to-right environment, or vice versa, is likely to cause text garbling if not done correctly. So most user interfaces, whether left-to-right or right-to-left, need to be able to deal with bidirectional (BiDi) text.

Handling BiDi text can be tricky and requires special processing at every appearance of potentially BiDi data in the UI. As a result, BiDi text support often regresses when a developer adds a new feature–and fails to include BiDi support in the updated code.

Called from your automated test suite, BidiChecker can catch regressions before they go live. It features a pure JavaScript API which can easily be integrated into a test suite based on common JavaScript test frameworks such as JSUnit. Here's a sample test for the above scenario:


// Check for BiDi errors with Arabic data in an English UI.
function testArabicDataEnglishUi() {



 // User reviews data to display; includes Arabic data.



 var reviewsData = [



 

 {'title': 'The Princess Bride', 'reviews': '23'},


 

 {'title': '20,000 Leagues Under the Sea', 'reviews': '17'},


 

 {'title': 'ستار تريك', 'reviews': '57'} // “Star Trek”



 ];





 // Render the reviews in an English UI.


 var app = new ReviewsApp(reviewsData, testDiv);


 app.setLanguage('English');



 app.render();







 // Run BidiChecker.



 var errors = bidichecker.checkPage(/* shouldBeRtl= */ false, testDiv);



 // This assertion will fail due to BiDi errors!



 assertArrayEquals([], errors);

}

We’ve just released BidiChecker as an open source project on Google Code, so web developers everywhere can take advantage of it. We hope it makes the web a friendlier place for users of right-to-left languages and the developers who support them.

By Jason Elbaum, Internationalization Team

URL: http://googletesting.blogspot.com/2010/11/test-your-app-from-right-to-left.html

[Gd] Make your websites run faster, automatically -- try mod_pagespeed for Apache

| More

Google Code Blog: Make your websites run faster, automatically -- try mod_pagespeed for Apache

Last year, as part of Google’s initiative to make the web faster, we introduced Page Speed, a tool that gives developers suggestions to speed up web pages. It’s usually pretty straightforward for developers and webmasters to implement these suggestions by updating their web server configuration, HTML, JavaScript, CSS and images. But we thought we could make it even easier -- ideally these optimizations should happen with minimal developer and webmaster effort.

So today, we’re introducing a module for the Apache HTTP Server called mod_pagespeed to perform many speed optimizations automatically. We’re starting with more than 15 on-the-fly optimizations that address various aspects of web performance, including optimizing caching, minimizing client-server round trips and minimizing payload size. We’ve seen mod_pagespeed reduce page load times by up to 50% (an average across a rough sample of sites we tried) -- in other words, essentially speeding up websites by about 2x, and sometimes even faster.

(Video comparison of the AdSense blog site with and without mod_pagespeed)

Here are a few simple optimizations that are a pain to do manually, but that mod_pagespeed excels at:

  • Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
  • Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
  • Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.

We’re working with Go Daddy to get mod_pagespeed running for many of its 8.5 million customers. Warren Adelman, President and COO of Go Daddy, says:

"Go Daddy is continually looking for ways to provide our customers the best user experience possible. That's the reason we partnered with Google on the 'Make the Web Faster' initiative. Go Daddy engineers are seeing a dramatic decrease in load times of customers' websites using mod_pagespeed and other technologies provided. We hope to provide the technology to our customers soon - not only for their benefit, but for their website visitors as well.”

We’re also working with Cotendo to integrate the core engine of mod_pagespeed as part of their Content Delivery Network (CDN) service.

mod_pagespeed integrates as a module for the Apache HTTP Server, and we’ve released it as open-source for Apache for many Linux distributions. Download mod_pagespeed for your platform and let us know what you think on the project’s mailing list. We hope to work with the hosting, developer and webmaster community to improve mod_pagespeed and make the web faster.

By Richard Rabbat, ‘Make the Web Faster’ initiative
URL: http://googlecode.blogspot.com/2010/11/make-your-websites-run-faster.html

[Gd] Make your websites run faster, automatically -- try mod_pagespeed for Apache

| More

Official Google Webmaster Central Blog: Make your websites run faster, automatically -- try mod_pagespeed for Apache

Webmaster Level: All

Last year, as part of Google’s initiative to make the web faster, we introduced Page Speed, a tool that gives developers suggestions to speed up web pages. It’s usually pretty straightforward for developers and webmasters to implement these suggestions by updating their web server configuration, HTML, JavaScript, CSS and images. But we thought we could make it even easier -- ideally these optimizations should happen with minimal developer and webmaster effort.

So today, we’re introducing a module for the Apache HTTP Server called mod_pagespeed to perform many speed optimizations automatically. We’re starting with more than 15 on-the-fly optimizations that address various aspects of web performance, including optimizing caching, minimizing client-server round trips and minimizing payload size. We’ve seen mod_pagespeed reduce page load times by up to 50% (an average across a rough sample of sites we tried) -- in other words, essentially speeding up websites by about 2x, and sometimes even faster.

Comparison of the AdSense blog site with and without mod_pagespeed


Here are a few simple optimizations that are a pain to do manually, but that mod_pagespeed excels at:
  • Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
  • Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
  • Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.
We’re working with Go Daddy to get mod_pagespeed running for many of its 8.5 million customers. Warren Adelman, President and COO of Go Daddy, says:
"Go Daddy is continually looking for ways to provide our customers the best user experience possible. That's the reason we partnered with Google on the 'Make the Web Faster' initiative. Go Daddy engineers are seeing a dramatic decrease in load times of customers' websites using mod_pagespeed and other technologies provided. We hope to provide the technology to our customers soon - not only for their benefit, but for their website visitors as well.”
We’re also working with Cotendo to integrate the core engine of mod_pagespeed as part of their Content Delivery Network (CDN) service.

mod_pagespeed integrates as a module for the Apache HTTP Server, and we’ve released it as open-source for Apache for many Linux distributions. Download mod_pagespeed for your platform and let us know what you think on the project’s mailing list. We hope to work with the hosting, developer and webmaster community to improve mod_pagespeed and make the web faster.

Richard Rabbat, Product Manager, ‘Make the Web Faster’ initiative
URL: http://googlewebmastercentral.blogspot.com/2010/11/make-your-websites-run-faster.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 9.0.570.0 for Windows, Mac, Linux and Chrome Frame

This release fixes several crashes as well as:

Mac
  • Make sure the dock icon is updated after closing an incognito window with an in-progress download (Issue 48391)
Linux
  • Fix incorrect border colors in incognito mode. (Issue 52815)
Security
  • Require a user gesture when opening file choose dialog and make sure file choose dialog from invisible windows can not be displayed (Issue 58319)
Known Issues
  • REGRESSION: Windows media player for Firefox doesn't load - Issue 61603
  • Regression:accelerated compositing slows down the whole machine - Issue 61520
  • google.com/wave : "Page Unresponsive" dailog box appears - Issue 61533
  • myspace.com : Cannot enter a character in Comments field - Issue 61513


More details about additional changes are available in the log of all revisions.

You can find out about getting on the Dev channel here: http://dev.chromium.org/getting-involved/dev-channel.



If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry
Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/11/dev-channel-update.html

[Gd] Introducing the Apps Ecosystem Marketing Test Kitchen

| More

Google Apps Developer Blog: Introducing the Apps Ecosystem Marketing Test Kitchen

The Google Apps Marketplace team is always looking for ways to help its vendors add new users and improve installation metrics. In order to help achieve these goals, we have launched the Apps Ecosystem Marketing Kitchen. Through experimentation, we want to collectively identify, test, and share best marketing practices for business web app.

The first initiative we cooked up is designed to help you, as a vendor, minimize the abandonment rate of Marketplace prospects as they bounce around your Marketplace property and various product pages without clear a “call to action”.


The Challenge:
The vendors who drive the most traffic and installs to their Marketplace listing page through their “Add to Apps” button between Nov 9th - 16th will be included in the front page Featured and Notable sections on the Apps Marketplace site.


Why participate in the challenge and use an “Add to Apps” button?
The “Add to Apps” button will improve your listing’s performance.
  1. Increase Conversions: Reduces the risk of users getting lost while navigating between the Marketplace and your website, which will result in a better experience for users and more installs for you.
  2. More Accurate tracking: Properly encoding the button URL using Google Analytics will enhance data-driven tracking so that we can better work together to understand and improve the user acquisition funnel.
  3. Bonus - Get a front page feature: The six (6) top traffic/install drivers during the challenge time-frame will be featured on the homepage. We will list:
    • The top two (2) traffic/installs drivers by pure volume.
    • The top four (4) in traffic/install growth from previous weeks.
If you already use an “Add to Apps” button, then you are one step ahead. If not, add one to get in on the challenge. We will start tracking on November 9th, so you’ll want to get started properly coding and testing your button.


How do I participate and succeed in this test kitchen challenge?
  1. Add the “Add to Apps” button properly.
  2. Make sure the page is the “Vendor product home page” link in your listing on the Marketplace
  3. Use marketing techniques to drive traffic through your landing page and potentially get featured on our front page.
  4. Use analytics to check visits made through the “button” medium, and see your traffic flowing to your app.

This test kitchen should be an exciting way to cook up some tasty campaigns. If you have any good ideas or suggestions, pass them along to marketing-test-kitchen@google.com. Check for new challenges on this blog. In order to stay on top of any news on initiatives, also follow our Buzz, Twitter, and subscribe to our email list.

Posted by Harrison Shih, Associate Product Marketing Manager, Google Apps Marketplace

Want to weigh in on this topic? Discuss on Buzz
URL: http://googleappsdeveloper.blogspot.com/2010/11/introducing-apps-ecosystem-marketing.html

Tuesday, November 2, 2010

[Gd] Rich snippets for shopping sites

| More

Official Google Webmaster Central Blog: Rich snippets for shopping sites

Webmaster Level: All

In time for the holiday season, we now support rich snippets for shopping (e-commerce) sites! As many of you know, rich snippets are search results that have been enhanced using structured data from your web pages. Our new format shows price, availability, and product reviews on pages offering a product for sale. Here’s a result for [office lava lamp]:


As a webmaster, there are two ways that you can provide the information needed for product rich snippets to show up for your site, both described on the Product rich snippets help page:

Option 1: Provide a Merchant Center feed.

Many sites already provide Merchant Center feeds for use in Google Product Search, which means that most of the work needed for rich snippets is already done. For Google to make use of Merchant Center feeds for rich snippets, you should also use the rel=”canonical” link element on your product pages. By adding rel=”canonical” to your pages, Google can match the URLs in your feed to the pages found by our crawler.

Option 2: Add markup to your site.

If prices for your products tend to change only infrequently, then adding markup is an alternative method to provide product data for rich snippets. We’ve updated our product markup format to allow a variety of different types of shopping sites to participate. In addition to the Google format, we support two other standards: the hProduct microformat and GoodRelations. You can use the rich snippets testing tool to test your markup and make sure it’s being parsed correctly.

This feature is currently available to merchants located in the US, but we will be rolling it out in more markets soon. Additionally, there are a number of rich snippets formats that can be used world-wide in various languages—make your snippets compelling and useful! Should you have any questions about the use of rich snippets, check out our FAQs and feel free to post in our Webmaster Help Forum.

Q&A

Which should I provide -- a Merchant Center feed or markup?

For most merchants, providing a Merchant Center feed is the best bet. That way your product prices and availability are updated quickly, and the data can be shown in rich snippets as well as in other applications like Google Shopping and Product Ads. If prices and availability change only infrequently, and you don’t want to set up a feed, then adding markup is also a valid option.

If I add markup to my site, will Google show product rich snippets for my pages?

We can’t guarantee that providing a feed or adding markup will result in rich snippets being shown. Note also that it may take a few weeks after providing data for rich snippets to be shown. If you mark up your pages, we encourage you to make sure that the data is parsed correctly by Google by using the rich snippets testing tool. The testing tool updates are rolling out over the next few days, so in this interim period the testing tool may not show previews for some types of markup.

I’ve already done reviews markup for my product offer pages. Should I add product/offer markup as well?

Yes, absolutely. Rich snippets are shown if the information provided accurately represents the main focus of the page. Therefore, for product pages you should add markup using the relevant offer/product fields which can include nested reviews.

Written by Nitin Shetti and Mircea Ciurumelea, Search Quality team
URL: http://googlewebmastercentral.blogspot.com/2010/11/rich-snippets-for-shopping-sites.html

[Gd] New Google APIs Console features a new Custom Search API

| More

Google Custom Search: New Google APIs Console features a new Custom Search API

Today, we announced the Google APIs console, a new tool to help you use our product APIs in your applications and on your websites. Included in the console is a new Custom Search API.

We’ve enhanced our Custom Search offering with the introduction of new output formats and a new API. Now, in addition to using the Custom Search element or the XML API, the new API offers search results using your choice of Atom or JSON syndication formats. For more information, please refer to our post on the Google Code blog.

Posted by: Adam Feldman, Product Manager and Rajat Mukherjee, Group Product Manager
URL: http://googlecustomsearch.blogspot.com/2010/11/new-google-apis-console-features-new.html

[Gd] A change to currency formatting in report downloads

| More

AdWords API Blog: A change to currency formatting in report downloads

If you're using the new AdWords API ReportDefinitionService, you may have noticed that monetary values in reports are returned as conventional currency instead of micros. At the request of the developer community, we'll be changing the format to micros on February 1, 2011 to make reporting more consistent with other AdWords API services.

A micro value is equal to one million times the conventional currency value, and is a standard we use throughout the AdWords API (including v13 reports) to represent money. For example, values currently returned as "1.50" (which would represent $1.50 for a USD account) will be returned as 1500000.

To help you with this change, we've introduced a new HTTP header flag (available immediately) that allows you to explicitly request the micros format. If you've written code that expects conventional currency values in reports, it's important that you update your code to expect micros and set the HTTP header "returnMoneyInMicros: true" when requesting a report download. Additionally, if you're just beginning to migrate from v13 reports, you should set this header on all your download requests.

Until February 1, 2011, conventional currency values will remain the default for report downloads that do not include this header. Subsequently, we'll ignore this header entirely and make micros the only available format; therefore, it's essential that you migrate your code as soon as possible.

To learn more about the new way to run reports via the API, see our blog post from this summer. As always, please post questions to the AdWords API Forum.

- Eric Koleda, AdWords API Team
URL: http://adwordsapi.blogspot.com/2010/11/change-to-currency-formatting-in-report.html

[Gd] Introducing the Google APIs Console and our latest API updates

| More

Google Code Blog: Introducing the Google APIs Console and our latest API updates

After a busy year of creating, curating, and re-organizing our APIs, we’re pleased to share that:
  • We’re announcing the Google APIs console, a new tool to help you use our APIs in your applications and on your websites.
  • We’re introducing a new and improved Custom Search API and the new Translate API, which replace the old Web Search API and the old Translate API respectively, which are being retired along with the old Local Search API.
  • We’ve reorganized and rewritten the documentation for some of your favorite APIs (read more on the AJAX APIs Blog).

New Google APIs Console Improves API Experience

The new APIs console helps you manage your API usage across all of your sites and apps. Key features include:
  • Log in with your Google account to see the API projects you’re working on.
  • Create and manage project teams for projects that are shared with your co-workers or friends.
  • Get developer credentials to track exactly how you are using each API.
  • View information about how your site or app is using the APIs, including which of your pages are making the most requests.



Initially, the console supports over a half dozen APIs – that number is expected to grow rapidly over time. Please take a look at the APIs console and get started using Google’s new APIs today.

New Custom Search API Delivers Better Integrated Search Experience


Google Custom Search helps you create a curated search experience, tailoring a custom search engine precisely to your specifications. This is the perfect tool for helping your visitors find exactly what they’re looking for on your site, and is especially useful for businesses that want to create a customized search experience across their public content without the expense or hassle of developing and hosting their own search infrastructure.
Today we are enhancing our Custom Search offering with the introduction of new output formats and a new API. Now, in addition to using the Custom Search element or the XML API, the new API offers search results using your choice of Atom or JSON syndication formats. To get started, click here to log into the API console and add this API to your project.

Retirement of Older APIs

As part of our ongoing housekeeping of our first-generation APIs, the legacy Web Search API and the Local Search API are being retired, to be phased out over the next three years as per our deprecation policies. We’ll also be tightening up our enforcement of the rate limits for these and the Translate API v1 over the next few months with an eye toward mitigating unauthorized usage, so we encourage everyone to migrate to the new APIs as available on the APIs console, or over to the Custom Search Element, the Translate Element, or the Maps API GoogleBar as your needs dictate.

Looking Forward

We’re excited about the opportunities that the new APIs console and this first batch of APIs built on our new API architecture will offer to developers. Even though we’ve been building APIs for several years now and are quickly approaching 100 tools, products, and APIs for developers, we still feel like we’re just getting warmed up. We’d love to hear your feedback on the new Google API console and our newest APIs — please let us know what you think.

By Adam Feldman, Adam Winer, David Gibson, and Louis Ryan, Google Developer Team
URL: http://googlecode.blogspot.com/2010/11/introducing-google-apis-console-and-our.html

[Gd] Fall Housekeeping

| More

Google AJAX APIs Blog: Fall Housekeeping

When we introduced this blog over four years ago, the term AJAX was only a year old, and Google had exactly one relevant API . Ajax has since become a mainstream part of the Web, and our family of APIs has grown. Like many growing families, we’ve accumulated a lot of cruft over the years, and have outgrown our first home. Time for some housekeeping.

API Documentation - Now easier to find and use
We’ve reorganized our documentation to make it easier to find what you’re looking for, based on what you want to do. We used to group our APIs based on technology - for instance, there were Google Data APIs and AJAX APIs. Now, you’ll see that each API has been given its own place, including its own documentation pages. This new documentation has been created from the ground up to provide a better experience for people coding against the APIs. We’ve also organized these more logically by product, such as moving the Book Search API into the Books family of APIs, and added many more samples to help you get started.

A fond farewell
In the spirit of consolidation, we’ll be retiring this blog in favor of the Google Code Blog. By concentrating on fewer blogs, we’ll be able to keep the blog fresher and help make sure that as wide an audience as possible is able to benefit from our posts. We’ll continue using tags, so that you can subscribe to your favorite APIs and focus on the content that most interests you (though we hope you’ll check in occasionally to see what new stuff you might be missing).

Show your support for the Code blog by hopping over to read about the new Google APIs console and Custom Search API, and also say good-bye to the Web and Local Search APIs, which are being deprecated. Full post here.

Posted by: Adam Feldman, Product Manager
URL: http://googleajaxsearchapi.blogspot.com/2010/11/fall-housekeeping.html

Monday, November 1, 2010

[Gd] Best practices for running multiple sites

| More

Official Google Webmaster Central Blog: Best practices for running multiple sites

Webmaster Level: All

Running a single compelling, high quality site can be time- and resource-consuming, not to mention the creativity it requires to make the site a great one. At times–particularly when it comes to rather commercial topics like foreign currency exchange or online gambling–we see that some webmasters try to compete for visibility in Google search results with a large
number of sites on the same topic. There are a few things to keep in mind when considering a strategy like this for sites that you want to have listed in our search results.

Some less creative webmasters, or those short on time but with substantial resources on their hands, might be tempted to create a multitude of similar sites without necessarily adding unique information to any of these. From a user’s perspective, these sorts of repetitive sites can constitute a poor user experience when visible in search results. Luckily, over time our algorithms have gotten pretty good at recognizing similar content so as to serve users with a diverse range of information. We don’t recommend creating similar sites like that; it’s not a good use of your time and resources.

If all of your sites offer essentially the same content, additional sites are not contributing much to the Internet.

While you’re free to run as many sites as you want, keep in mind that users prefer to see unique and compelling content. It is a good idea to give each site its own content, personality and function. This is true of any website, regardless of whether it’s a single-page hobby-site or part of a large portfolio. When you create a website, try to add something new or some value to the Internet; make something your users have never seen before, something that inspires and fascinates them, something they can’t wait to recommend to their friends.

When coming up with an idea for a website, scan the web first. There are many websites dealing with common and popular services like holiday planning, price comparisons or foreign exchange currency trading. It frequently doesn’t make sense to reinvent the wheel and compete with existing broad topic sites. It’s often more practical and rewarding to focus on smaller or niche topics where your expertise is best and where competition for user attention might be less fierce.

A few webmasters choose to focus their resources on one domain but make use of their domain portfolio by creating a multitude of smaller sites linking to it. In some situations these sites may be perceived as doorways. Without value of their own, these doorway sites are unlikely to stand the test of time in our search results. If you registered several domains but only want to focus on one topic, we recommend you create unique and compelling content on each domain or simply 301 redirect all users to your preferred domain. Think of your web endeavour as if it were a restaurant: You want each dish to reflect the high quality of the service you provide; repeat the same item over and over on your menu and your restaurant might not do so well. Identify and promote your strength or uniqueness. Ask yourself the following questions: What makes you better than the competition? What new service do you provide that others don’t? What makes your sites unique and compelling enough to make users want to revisit them, link to them or even recommend them to their friends?

We suggest not spreading out your efforts too broadly, though. It can be difficult to maintain multiple sites while keeping the content fresh and engaging. It’s better to have one or a few good sites than a multitude of shallow, low value-add sites. As always, we encourage you to share your thoughts via comments as well as by contributing to the Google Webmaster community.

Posted by Tomer Honen & Kaspar Szymanski, Search Quality Team
URL: http://googlewebmastercentral.blogspot.com/2010/11/best-practices-for-running-multiple.html

Sunday, October 31, 2010

[Gd] India Withdrawals

| More

Google Testing Blog: India Withdrawals

By James Whittaker

I told the crowd at GTAC during my talk: "I wasn't sure what to expect from India. I was not disappointed." Be careful how you quote me on this statement as getting it even a little wrong can make it seem like an insult. It is no such thing.

After spending a week there, I still am not sure what to expect. It's a country of such contrasts with extremes on both ends of pretty much every scale you can come up with. India must remain a mystery to me as I have seen so little of it.

The Indian people, on the other hand, I think I understand a little better now. Their hunger to contribute. Their hope for the future. Their determination to be part of the solution in every way, shape and form. This is no simple case of outsourcing we have here. That attitude is so last decade.

This was the best GTAC yet and the credit must go to the people who ran it and contributed the most to its success. This is a case of India stepping up and doing what London, New York, Seattle, Zurich (and next year Mountain View) did and then raising the bar that much more. Toe-to-toe with the world.

There are individuals who can take a bow for GTAC, but the credit has be be far more dispersed. India ... you nailed this one.

And I meant what I said at the end of my talk. I am very eager to return. Perhaps one day I will know India well enough to know what to expect. I am very sure I will not be disappointed.
URL: http://googletesting.blogspot.com/2010/10/india-withdrawals.html