Saturday, December 25, 2010

[Gd] Sending Video Sitemaps Q&A holiday cheer

| More

Official Google Webmaster Central Blog: Sending Video Sitemaps Q&A holiday cheer

Webmaster Level: Intermediate to Advanced

To the fabulous, savvy audience that attended our Video Sitemap webinar several months ago, please accept our re-gift: a summary of your questions from the Video Sitemaps Q&A!

To those who were unable to attend the webinar, please enjoy our gift of the summarized Q&A -- it’s like new!

Either way, happy holidays from all of us on the Webmaster Central Team. :)

Our entire webinar covers the basics of Video Sitemaps and best practices -- nearly everything you’d need to know when submitting a video feed.

  1. Can the source/content of the video (perhaps a third-party vendor) be hosted on another site? For example, can I host my videos on YouTube and still be eligible for Video Search traffic?

    Yes, you can use a third party to host videos. Only the play page--the URL within the <loc> tag--needs to be on your site. <video:content_loc> and <video:player_loc> can list URLs on a different site or subdomain.

    For example, here’s a snippet from a valid Video Sitemap that shows content hosted on a different subdomain from the play page:

          <video:title>Grilling steaks for summer</video:title>
          <video:description>Alkis shows you how to get perfectly done steaks every time</video:description>
          <video:player_loc allow_embed="yes" autoplay="ap=1"></video:player_loc>

  2. If I’m using YouTube to host my videos, can Google verify that I’m the legitimate owner?

    Currently, there doesn’t exist functionality that allows you, as the uploader, to verify that you’re the owner of a video. The issue of authorship is a hard problem on the web, not just for videos, but nearly all types of content.

  3. Because Google owns YouTube, should users who embed YouTube videos still submit Video Sitemaps or is it unnecessary?

    Google treats YouTube as just another source for video content -- though you don’t need to submit a Video Sitemap if you only want your YouTube-hosted videos indexed. If, however, you’re using YouTube as a online video platform (i.e., with play pages on your own site), then we do recommend Sitemap submission.

  4. How long does it take for Google to accept and verify a Video Sitemap?

    Video Sitemap submission is a two-part process:

    1. We fetch the Sitemap and parse it for syntax errors. This happens within minutes.

    2. We fetch the assets referenced in the Sitemap, perform checks, validate metadata, do more cool stuff, and last, index the video. This step can require varied amounts of time depending on your site and our system load.

  5. What tags and categories are most important in Video Sitemaps or mRSS? Should I create my own categories or is there a list that I should conform to?

    Currently, the most important metadata to include is title and description -- both are required. The category tag is optional, and there isn’t a list from which to select.

  6. Do I have to use HTML5 to use Video Sitemaps?
    Does HTML5 help with discovery?
    Or, if my site is HTML5 compliant, do I still need to submit a Video Sitemap?

    None of the Video Search principles change with HTML5. We still recommend using a Video Sitemap regardless of the markup on your site. HTML5 can be helpful, though, because tags like <video> make it easier for our systems to verify that video exists on the page.

  7. If I use an iframe rather than embedding my videos, can Google still find it?

    We do not recommend using iframes to embed video content on your pages.

  8. Can I have multiple videos on one URL?

    You can. We’ve found, however, that users may not consider it the best experience. When users click on a video search result, they most often don’t like being forced to locate the correct video among multiple videos on the resulting page.

  9. Do I need to specifically create a robots.txt file that allows Googlebot, or do I just need to make sure Googlebot isn’t blocked?

    Just make sure that Googlebot isn’t blocked.

  10. I provided a thumbnail, but it’s not being used. Does Google create their own thumbnails from my videos?

    We try to use the thumbnail you provide if it’s valid. If not, we’ll try to generate a thumbnail ourselves. We recommend that you provide thumbnails that are at least 120x90 pixels. We also accept many thumbnail formats, such as PNG and JPEG.

  11. Any video filesize limitations?

    At this time, there aren’t video filesize limitations on content submitted through VIdeo Sitemaps.

  12. Is there any way to indicate a transcript or closed captioning for a video?

    Currently there isn’t, but perhaps down the road.

  13. What if I’m using Lightbox or a popup to display a video; can it still be indexed?

    Depends on the use case and how it’s rendered, but if indexing by search engines is important to you, it’s not the safest method. In the Webmaster Help Center, we explain that “When designing your site, it's important to configure your video pages without any overly complex JavaScript or Flash setup.” Most often, for bots, simpler is safer.
Have a safe and happy holiday!

Written by Maile Ohye, Developer Programs Tech Lead

Friday, December 24, 2010

[Gd] Improving our help content: stocking stuffers in our Help Center

| More

Official Google Webmaster Central Blog: Improving our help content: stocking stuffers in our Help Center

Webmaster Level: All

We provide lots of information for webmasters across many different channels — you can stay up to date with the latest features here on our blog, browse articles in our Help Center, have discussions in our forums (in 17 languages!), watch videos on our YouTube channel, or even read in-depth interviews (in English, Portuguese, and other languages).

There’s no shortage of useful information, but sometimes the relevant bits may be a bit difficult to locate, especially for novice webmasters. We see the same questions popping up over and over again, so we’ve tried to make our most frequently searched information as accessible and visible as possible:
We analysed the questions asked over the past year and a half and identified the issues you are most interested in. We then picked out the relevant bits from across our different resources and collected the answers to those questions in one new convenient FAQ page in our Help Center (available in 20 languages).

We also frequently get questions on how to get in touch with us, so we’ve put together all the different ways you can:
...tell us about a page you want to remove from our search results;
...tell us about spam you found;
...let us know when you’ve fixed issues on your website;
...and many more! All of these contact channels are now listed conveniently in one article with direct links to the relevant forms: Webmaster help and contacts (available from the homepage of our Help Center, also in 20 languages).

Now isn’t that a nice stocking stuffer (-:?
Happy webmastering in 2011, and keep the feedback coming!

Posted by Mariya Moeva, Search Quality Team, Dublin

Thursday, December 23, 2010

[Gd] A Chrome Extension for YouTube Activity Feeds

| More

YouTube API Blog: A Chrome Extension for YouTube Activity Feeds

Slave Jovanovski, an engineer at YouTube, has put together a Google Chrome extension that should be of interest to the YouTube API community. It’s called YouTube Feed, and after installing and authenticating with your YouTube account, it automatically will fetch your YouTube social activity stream (both subscriptions and friends’ actions) while you use Google Chrome. When a new event, like a YouTube friend uploading or commenting on a video, takes place, the extension will notify you and provide details on the activity, as well as links to view the actual video. You have control over which types of activities you’d like to be notified about, as well as how frequently you’d like the extension to check for updates.

While you’ll hopefully find the extension useful on its own merits, the fact that the source code has been released as part of an open source project means that the extension’s code can serve as inspiration (or a jumping off point) for writing your own JavaScript code that interacts with the YouTube API. Curious as to how to use OAuth to authenticate YouTube accounts from a Chrome Extension? Or request JSON data with a JavaScript callback? The answers await you in the source code!

–Jeff Posnick, YouTube API Team

[Gd] Webinar and GTAC Followup

| More

Google Testing Blog: Webinar and GTAC Followup

By James Whittaker

I've given all the talks I am going to give and said all that I am going to say for 2010. Breath a sigh of relief and raise your glasses to the sweet sound of silence.

The aftermath of the uTest webinar is here. Thanks to uTest for hosting and putting up with me.

My GTAC 2010 talk is here. But far better is my introduction by Testivus. If imitation is the sincerest form of flattery, I hereby declare insults to be out-and-out envy. To our female readers, you may need to have some understanding of the male penchant for funny insults - it's a weird guy thing. But I don't care who you are ... this stuff is funny! And to answer your question: NO I did not see Alberto's video of me before I spoke. It was all new to me.

Hope to see you next year in the blog-o-sphere and at a couple of conferences. I'll be (at least) at GTAC 2011 which is in Mountain View and Euro STAR in Manchester, England (will lecture for a ticket to a Premier League football match).

Much more to come in the new year. Peace to all.

[Gd] Video Sitemaps & mRSS vs. Facebook Share & RDFa

| More

Official Google Webmaster Central Blog: Video Sitemaps & mRSS vs. Facebook Share & RDFa

Webmaster Level: Intermediate to Advanced

What are the benefits of submitting feeds like Video Sitemaps and mRSS vs. the benefits of Facebook Share and RDFa? Is one better than the other? Let’s start the discussion.

Functionality of feeds vs. on-page markup

Google accepts information from both video feeds, such as Video Sitemaps and mRSS, as well as on-page markup, such as Facebook Share and RDFa. We recommend that you use both!

If you have limited resources, however, here’s a chart explaining the pros and cons of each method. The key differentiators include:
  • While both feeds and on-page markup give search engines metadata, Video Sitemaps/mRSS also help with crawl discovery. We may find a new URL through your feed that we wouldn’t have easily discovered otherwise.

  • Using Video Sitemaps/mRSS requires that the search engine support these formats and not all engines do. Because on-page markup is just that -- on the page -- crawlers can gather the metadata through organic means as they index the URL. No feed support is required.

(Video Sitemaps & mRSS)
On-page markup
(Facebook Share & RDFa)
Accepted by Google
Helps search engines discover new URLs with videos (improves discovery and coverage)
Provides structured metadata (e.g. video title and description)
Allows search engines without sitemap/mRSS support to still obtain metadata information (allows organic gathering of metadata)
Incorporates additional metadata like “duration”

If you’re further wondering about the benefits of specific feeds (Video Sitemaps vs. mRSS), we can help with clarification there, too. First of all, you can use either. We’re agnostic. :) One benefit of Video Sitemaps is that, because it’s a format we’re actively enhancing, we can quickly extend it to allow for more specifications.

All this said, if you’re going to start from scratch, Video Sitemaps is our recommended start.

 Video SitemapsmRSS
Accepted by Google
Been around for a long, long time and pretty widely accepted
Extremely quick for Google Video Search team to extend

“Starving” to start conversation about feeds or on-page markup? Join us in the Sitemaps section of the Webmaster discussion forum.

Written by Maile Ohye, Developer Programs Tech Lead

[Gd] Ring in the new year with accessible content: Website clinic for non-profits

| More

Official Google Webmaster Central Blog: Ring in the new year with accessible content: Website clinic for non-profits

Webmaster level: Beginner

Cross-posted on the Google Grants Blog

In our previous post, we did some source code housekeeping -- just in time for the holidays. But once users have landed on your site, how can you make sure they’ll know how to get around?

As it turns out, easily accessible content on your site can make a big difference. Users tend to have a better experience when a site helps them find and understand its content. Having an accessible site not only empowers users, it also helps search engines understand what your site is really about.

So if you’ve resolved to boost your site’s user experience and online presence for the new year, improving your content accessibility is a great way to start. Thankfully, there are tons of features you can add to make your site more accessible. In this post, we’ll highlight three of them:
  • Intuitive navigation
  • Concise, descriptive anchor text for links
  • Unique, accurate page titles throughout the site
Intuitive navigation
Help users avoid confusion by providing them with intuitive navigation, so that when they arrive at your site, they’ll know where to click to find the information they’re looking for.

Here are three features you can implement in order to lead your users down the right path:
  • Navigational menu: Having a menu with links to the site’s most important pages is the fastest, easiest way to show users where to click next.
  • Text-based links: While drop-down menus, image-based links, and animation-based links can be appealing, keep in mind that users on text-only devices and some search engines may not be able to see or understand these links. Thus, many users prefer text-based links, which are also easier for search engines to crawl and interpret.
  • User-viewable site map: 59% of our submissions did not have a user-viewable site map. By providing one, you display the structure of your site and give the user easy one-click navigation. If users are having trouble finding specific pages on your site, a site map can help them find their way. Don’t send your users into the wild without a map!
Let’s explore how these features can make a site’s navigation more intuitive by looking at one of our submitted sites, Philanthropedia.

Thanks to this site’s clean navigational menu, users can find all of the site’s important pages within a few clicks. Wherever users end up on the site, they can always click on the “Home” button to return to the main page, or on any of the links in the menu to return to the site’s important subpages. Like all of the links on this site, the links in the navigational menu are text-based links, which make it easier for both search engines and users to access the site’s content. Finally, Philanthropedia has included a user-viewable site map, shown below, in case visitors are looking for a specific page not listed in the main menu.

Concise, descriptive anchor text for links
Anchor text -- the clickable text of a link -- can help users quickly decide which links they want to click on and find out more about. Meaningful anchor text makes it easier for users to navigate around your site and also helps search engines understand what the link’s destination page is about.

20% of our submissions could improve their sites by improving the anchor text used in some of their internal links. When writing anchor text, keep two things in mind:
  • Be descriptive: Use words that are relevant to the destination page, avoiding generic phrases like “click here” or “article.” Make sure the user can get a snapshot of the destination page’s overall content and functionality by reading the anchor text.
  • Keep it concise: Anchor text that contains a few words or a short phrase is more attractive and convenient for users to read than a sentence or paragraph-long link.
Let’s take a look at how anchor text played out in two user-submitted examples:

OrganizationAnchor Text ExamplesUser FriendlinessAnchor Text Behavior
The Mosaic ProjectWork for Mosaic

Order Our Curriculum Guide

Outdoor School
High: Users can get an accurate idea of the content on the links’ destination pages just by reading the anchor text.Active verb phrases and rich nouns accurately describe the pages that the links are pointing to.
Asian Liver CenterLearn more

Low: The anchor text is too generic and does not give users an idea of what the linked-to content is. Generic phrases give little insight into the pages that the links are pointing to.

You can learn more about anchor text and internal linking strategies by checking out this blog post on the importance of link architecture.

Unique, accurate page titles throughout the site
Each page on your site is different, so flaunt your site’s diversity by giving a unique title to each page. Giving each page a unique title lets search engines know how that page is distinct from others within your site. In our analysis, over 28% of sites could have improved their site quality by adding unique page titles.

Let’s check out a few more examples to see what a difference unique, accurate page titles can make:

OrganizationPage Title ExamplesUser FriendlinessPage Title Behavior
VAMS InternationalUpcoming Events | VAMS International

Request Service | VAMS International

FAQ’s | VAMS International

High: Each page’s content is relevant to its title, and the user can get a good idea of each page’s unique offerings and functionality.Concise, rich language joined with the organization’s name accurately describes the corresponding pages. The titles show how each page is unique while also acknowledging that they are all associated with one organization.
MHCD Evaluation and ResearchMHCD Evaluation and ResearchLow: This site contains a lot of diverse content and rich functionality; however, the uniform page titles do not convey these strengths.This page title is too general and does not accurately describe the content on each page. The same title is used across all the pages on this site.

Wrapping things up
We hope that this blog post has given you some ideas on how to ring in the new year with improved content accessibility, which can boost the user experience and online presence for your site.

To learn more about the features discussed here and in our previous two site clinic posts, check out our SEO Report Card and SEO Starter Guide.

This blog post wraps up our website clinic for non-profits. We send our warmest regards to all the great non-profit causes you are working on, and thanks to everyone who took the time to submit their sites and read our posts!

Posted by Jen Lee and Alexi Douvas, Search Quality Evaluation Team
Contributors: Aditya Goradia, Brandon Falls, Charlene Perez, Diara Dankert, Michael Wyszomierski, and Nelson Bradley

Wednesday, December 22, 2010

[Gd] More Payment Options in Android Market

| More

Android Developers Blog: More Payment Options in Android Market

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

A key to a great purchasing experience is providing users with simple and fast payment methods. The Android Market team has been working hard to deliver more forms of payment to further reduce purchase friction.

Today, I am pleased to announce the availability of AT&T Direct Carrier Billing for Android users on the AT&T network. AT&T Android users can now easily charge their Android Market purchases to their monthly accounts with only a few clicks. With the combination of Android Market’s new app discovery features and a carrier-backed frictionless payment method, users will find it significantly easier to discover and purchase applications of their choice.

We’ve been rolling out Direct Carrier Billing to all AT&T users over the past several days, as part of a general update to the Market service. Also in the update, please watch for the arrival of new features we announced recently, including the 15-minute refund window, dynamic Wallpaper and Widget categories, new 50MB max .apk size, and more. In addition, we’ve added even more categories to make it easier to find great apps in popular categories, such as “Media & Video”, “Music & Audio”, “Business”, “Sports” (in "Games"), and more. If you have one or more published apps on Android Market, please take a look at these new categories and decide if they are more suitable for your products.

We strongly believe carrier billing is a great way to make it easy for users to purchase and pay for applications. In addition to the availability of AT&T and T-Mobile US carrier billing, we’ll continue to to partner with more carriers to offer carrier billing options for their subscribers.

2010 has been an awesome year for Android due in large part to your support. We have seen tremendous growth in Android Market both in terms of application volume and quality. In 2011, we remain committed to making Android Market the best mobile application store possible. As always, please don’t hesitate to continue giving us feedback through Market Help Center.

Best wishes for the new year!


[Gd] Integrating your Rails application with Google Apps and the Apps Marketplace

| More

Google Apps Developer Blog: Integrating your Rails application with Google Apps and the Apps Marketplace

Editor’s note: Vincent Van Gemert is a software engineer at Floorplanner, an online floor planning application which launched in June on the Google Apps Marketplace.

In this article you will find a step-by-step guide to integrating your Ruby on Rails application with Google Apps and launching it on the Google Apps Marketplace. The Google Apps Marketplace is a great platform to get new clients, show off our product and integrate Floorplanner with the services Google provides. At the beginning of the summer we tried to launch our application on the Marketplace. We found out that a lot of people were struggling with the existing Rails libraries and the OAuth authorization method, therefore we would like to provide this tutorial to help other developers. I would like to thank Dušan Maliarik for building this implementation with me and finding the solution for using the two-legged OAuth authorization.

1. The initial setup

Before you start programming there is some required setup. You first have to add a new application on the Google Apps Marketplace. You will need a Vendor Profile for this and a Google account. Sign In to the Marketplace with your Google account and go to your Vendor Profile using the link at the top-right of the Marketplace homepage.

After you enter some information about your company, there will be a list of your applications called “Listings.” You need to create a new listing to develop and test your application. When you create a new listing, check the box which says “My product may be directly installed into Google Apps domains.” This is necessary if you want the application to have an “Add it Now” button on the listing page, and allows you to add a Manifest to describe the application.

A Manifest describes all the settings of your application, like the name, URL’s and required permissions. Below you can find an example manifest. You will need to change all fields surrounded by brackets [ ].
<?xml version="1.0" encoding="UTF-8" ?>
<ApplicationManifest xmlns="">


<!-- Administrators and users will be sent to this URL for application support -->
<!-- URL for application setup as an optional redirect during the install -->
<Link rel="setup" href="[ApplicationSetupUrl]?domain=${DOMAIN_NAME}" />

<!-- URL for application configuration, accessed from the app settings page in the control panel -->
<Link rel="manage" href="[ApplicationAdminUrl]?domain=${DOMAIN_NAME}" />

<!-- URL explaining how customers get support. -->
<Link rel="support" href="[ApplicationHelpUrl]" />

<!-- URL that is displayed to admins during the deletion process, to specify policies such as data retention, how to claim accounts, etc. -->
<Link rel="deletion-policy" href="[ApplicationPolicyUrl]" />

<!-- Show this link in Google's universal navigation for all users -->
<Extension id="navLink" type="link">
<!-- Used API's -->
<Scope ref="contactFeed"/>
<Scope ref="spreadsheetFeed"/>
<Scope ref="doclistFeed"/>

<!-- Declare our OpenID realm so our app is white listed -->
<Extension id="realm" type="openIdRealm">

<Scope id="doclistFeed">

<Scope id="contactFeed">


You should decide whether you want to create a setup page. During the installation process of the application you will be redirected to the URL you specified in the manifest under “setup”. This is useful for collecting additional information necessary for configuring the app, or setting up a new umbrella account for the company. The umbrella account allows you to use other users of the domain as sub-users. You can also retrieve other information, like the administrators of the domain, the logo of the Google Apps account, or the domain name of the Google Apps account. If you don’t want to redirect customers to your site during the installation process, then just remove the line from your manifest.

2. Rails libraries and OpenID

The code you’re going to use relies on several Rails plugins and gems. The plugins/gems needed for this tutorial are listed below.
After installing these, you will be able to use OpenID, OAuth and the Google Data APIs in your Rails application. First you are going to authenticate the user with OpenID. This way you can retrieve the user’s email address and other information like First and Last name. The OpenID implementation is straight-forward. When using OpenID, a connection will be made to Google’s OpenID service and will check if the user granted access to your application. In typical OpenID, a ‘grant access’ page or login page is presented if the user hasn’t granted access to the app, though this won’t happen if you have a Google Apps Marketplace application installed with a properly configured realm as access is granted by the administrator for all of their users. This process can be found in the example code below.

def login

# The domain needs to be set. For example with params[:domain]
{ :required => [""], :return_to => '/login'}) do |result, identity_url, registration|

if result.successful?
# Succesfully logged in, retrieve email address
email = get_email(registration)
# Failed to login


def get_email(registration)

ax_response = OpenID::AX::FetchResponse.from_success_response(


After reviewing this code sample you can alter it for using it with the setup page. Authenticate with OpenID when a user goes into the setup procedure and redirect them to the actual setup page after they are authenticated.

After your setup page is complete you can add your Google Apps Marketplace listing to your Google Apps account. Note that administrator privileges are necessary to add the application to your Google Apps account. You can add the application from the Vendor Profile when you click on your newly created application. A big blue button will appear on the right side of the listing’s information page. More information on this process can be found on the Creating a Listing page in the Marketplace developer documentation.

3. Using the Google Data APIs

When using the Google Data APIs outside of the Apps Marketplace you have to get access to a user’s data using three-legged OAuth, AuthSub or ClientLogin. These authorization methods require your application to redirect the user to Google’s site to request authorization. Because you’ve already authenticated the user by using OpenID and an administrator has granted authorization to the user’s data when they added your application to their Google Apps domain, you don’t want to use these methods.

For the Google Apps Marketplace there is another option-- two-legged OAuth. Two-legged OAuth allows your application to use a single consumer key and secret (available from the Vendor Profile) to access the data for all your customers who have installed the Marketplace app and granted the appropriate permissions. Because the administrators have granted permission on behalf of their users, each user does not need to be prompted individually.

The first thing you should try is to retrieve a contact list of a user. You could use it for auto completion on forms, or you can let users quickly add friends to your application.

CONSUMER_KEY = "Your-consumer-key"
CONSUMER_SECRET = "Your-consumer-secret"

def get_contacts

# Retrieve contacts
email = ""
url = "{email}"
contacts = gdata_request(url, :get)


def gdata_request(url, method, headers = {}, data = "")

uri = URI.parse(url)

# Setting up two-legged-oauth
consumer =, CONSUMER_SECRET)
oauth_params = {:consumer => consumer, :method => method, :request_uri => uri.to_s}

# Set Net:HTTP connection
http =, uri.port)
http.use_ssl = (uri.port == 443)

if method == :post
req =
req.body = data
req =

# Set authorization header
oauth_helper =, oauth_params)
req.initialize_http_header(headers.merge({'Authorization' => oauth_helper.header}))

# Execute request
response = http.request(req)


The feature we struggled with the most during the integration of Floorplanner was the two-legged OAuth authorization. There was no documentation available for the gems and it took some attempts to get it right. We turned to the OAuth Playground to find out the differences between our own request and the working request. After numerous tries we found out that we need to specify the HTTP method in order to get it working. It was important to use the Net::HTTP::Post request when sending information and Net::HTTP::Get request when retrieving information. This sounds logical, but it also needed to be done when retrieving the authorization header in the OAuth Client Helper, as well as in the Net HTTP request. Now we have this code, we can generate a request for almost every call in the Google Data API’s.

In the next example, you will use the Google Docs API to send a CSV file to a user’s Google Docs account. You need to do a POST request to the Google Docs feed. The request is almost the same as in the previous example, only you need to add two more headers. One is the Content-Type where you specify the MIME type you want to send. In this case, you’re uploading a CSV file so “text/csv” will do. Another header you need to send is the Slug. This value specifies the name you want for the document in Google Docs. Another way of doing this is adding meta-data to the body of the request. More information on this method can be found in the the Google Docs documentation.

def submit_csv_to_gdocs

email = ''
url = '{email}'

# Create new CSV
csv =

CSV::Writer.generate(csv, ',') do |line|
line << ["Example 1", "Example 2"]


# Send request
gdata_request(url, :post,
{ 'Content-Type' => 'text/csv',
'Slug' => 'test.csv',
'GData-Version' => '3.0' },


Now, this is all you need to get started with the Google Data API’s. Be sure to check out the Google Apps Marketplace Developer overview for more information and to see which API’s you could use and how to use these. I would advise to check out the OAuth Playground if you have any problems with authorization. Using the playground with two-legged OAuth is very easy. Just follow these steps:
  1. Set the signature method to HMAC-SHA1
  2. Type in your consumer key and consumer secret (these can be found in your Vendor Profile)
  3. Set your Feed URL (step 6)
  4. Set GData-version to 3.0 unless the API only supports 2.0
  5. Click execute
Since the OAuth playground traffic isn’t over SSL, I’d only recommend using it with the consumer key and secret for a test application installed on test domains.

Thank you for reading this tutorial. I know this isn’t the best approach on using two-legged OAuth but it will give you some insight. The best way would be to build in two-legged OAuth support in the Google Data APIs Ruby Utility Library. I haven’t done that yet but am planning to look into that soon. If you have any questions or comments, I would love to hear from you. You can email me at

One last note: These code snippets are just examples of how to use the Google Apps Marketplace with Rails. I would advise you not to use these examples in a production environment.

Want to weigh in on this topic? Discuss on Buzz


Tuesday, December 21, 2010

[Gd] Holiday source code housekeeping: Website clinic for non-profits

| More

Official Google Webmaster Central Blog: Holiday source code housekeeping: Website clinic for non-profits

Webmaster Level: Beginner

Cross-posted on the Google Grants Blog

As the holiday season comes around, we all have a bit of housekeeping to do. This is precisely why we wanted to focus the second post in our site clinic series on cleaning up your source code. Throughout our analysis of submitted non-profit websites, we noticed some confusion about what HTML markup, or tags, to use where, and what content to place within them, both of which could have significant impact on users and how your website looks on the search results page.

Before you deck the halls, deck out your <title> elements
Out of all the submitted non-profit websites, 27% were misusing their <title> elements, which are critical in letting both Google and users know what’s important to your website. Typically, a search engine will display ~60 characters from your title element; this is valuable real estate, so you should use it! Before getting into the actual code, let’s first take a look at how a great title element from one of our submitted sites, Sharp, will appear in the search results page:

Ideally, a great <title> element will include the name of the organization, along with a descriptive tag line. Let’s take a look at some submitted examples:


<title> source code

User Friendliness

Tag Behavior


<title>Top San Diego Doctors and Hospitals - Sharp HealthCare</title>


Includes organization’s name and a descriptive tag line


<title>Interieur 2010 - 15-24 October Kortrijk, Belgium</title>


Includes the organization’s name and a non-descriptive tag line

VAMS International

<title>Visual Arts and Music for Society | VAMS International</title>


Includes only the organization’s name

If you don’t specify a <title> tag, then Google will try to create a title for you. You can probably do better than our best guess, so go for it: take control of your <title> tag! It’s a simple fix that can make a huge difference. Using specific <title> tags for your deeper URLs is also important, and we’ll address that in our next site clinic post.

Keep an eye on your description meta tags
Description meta tags weren’t being utilized to their full potential in 54% of submitted sites. These tags are often used to populate the two-line snippet provided to users in the search results page. With a solid snippet, you can get your potential readers excited and ready to learn more about your organization. Let’s take another look at a good example from among the submitted sites, Tales of Aussie Rescue:

If description meta tags are absent or not relevant, a snippet will be chosen from the page’s content automatically. If you’re lucky and have a good snippet auto-selected, keep in mind that search engines vary in the way that they select snippets, so it’s better to keep things consistent and relevant by writing a solid description meta tag.

Keep your <h> elements in their place
Another quick fix in your housekeeping is assuring your website makes proper use of heading tags. In our non-profit study, nearly 19% of submitted sites had room for improvement with heading elements. The most common problem in heading tags was the tendency to initiate headers with an <h2> or <h3> tag while not including an <h1> tag, presumably for aesthetic reasons.

Headings give you the opportunity to tell both Google and users what’s important to you and your website. The lower the number on your heading tag, the more important the text, in the eyes of Google and your users. Take advantage of that <h1> tag! If you don’t like how an <h1> tag is rendered visually, you can always alter its appearance in your CSS.

Use alt text for images
Everyone is always proud to display their family photos come holiday season, but don’t forget to tell us what they’re all about. Over 37% of analyzed sites were not making appropriate use of the image alt attribute. If used properly, this attribute can:
  • Help Google understand what your image is
  • Allow users on text-only browsers, with accessibility problems, or on limited devices to understand your images
Keep in mind, rich and descriptive alt text is the key here. Let’s take another look at some of our submitted sites and their alt attribute usage:


Source Code

User Friendliness

Tag Behavior

Sponsor A Puppy

<img alt="Sponsor a Puppy logo" src=...

Best: the alt text specifies the image is the organization’s main logo

Uses rich, descriptive alt text to describe images, buttons, and logos


<img alt="Logo" height=...

Good: the alt text specifies the image is a logo, but does not further describe it by the organization or its behavior

Uses non-descriptive alt text for images, buttons, and logos, or uses alt text only sporadically

Coastal Community Foundation

<img src="...”>

Not ideal: alt text not present

No use of alt text, or use of text that does not add meaning (often seen in numbering the images)

A little window shopping for your New Year’s resolution
Google has some great resources to further address best practices in your source code. For starters, you can use our HTML Suggestion Tool in Webmaster Tools. Also, it’s always a good practice to make your site accessible to all viewers.

Posted by Alexi Douvas and Jen Lee, Search Quality Team
Contributors: Aditya Goradia, Brandon Falls, Charlene Perez, Diara Dankert, Michael Wyszomierski, and Nelson Bradley

[Gd] Introducing the Ubuntu Font Family to the web

| More

Google Web Fonts: Introducing the Ubuntu Font Family to the web

Google and the Ubuntu project have today released the Ubuntu Font Family to the world through the Google Font Directory. The new Ubuntu Font Family debuted in the current Ubuntu 10.10 release of the Ubuntu operating system and is also available for download from

The main site features the Ubuntu Font Family in-use from today (screenshot below). Through the magic of the Google Font API any web designer can now pick Ubuntu from the Google Font Directory and bring the beauty and legibility of the Ubuntu fonts to their websites too.

The Ubuntu typeface family is a set of new fonts in development throughout 2010–2011. The development is being funded by Canonical Ltd on behalf the wider Free Software community and the Ubuntu project, with the skilled font work being undertaken by Dalton Maag. Like everything else in Ubuntu, the fonts are free to use and legal to share, sell, bundle and build upon. The included “source code” allows remixing, improvement and expansion by anyone with the skills or an interest. This release includes Latin, Cyrillic and Greek support, and future versions will be automatically rolled out to everyone using the Google Font API.

Mark Shuttleworth, founder of the Ubuntu project, commented: "Our focus on design and usability in Ubuntu led us to create a font which is at once beautiful and readable. We're delighted to share the Ubuntu Font Family with web designers around the world who want their websites to be stylish and readable in as many languages and browsers as possible. The publication of the Ubuntu font on the global Google Font Directory is an appropriate treat for the festive season, and we wish all those who contribute to, and enjoy the benefits of, free software and open content a very happy and healthy solstice and New Year."

Bruno Maag of the Dalton Maag type foundry, who have been working with Canonical on the design and technical implementation of the typeface commented, “It is unique in our company’s history to work on such a comprehensive high-quality font and to have it given to the World to use for free. The creativity and expertise that is available in the open source world, in particular the insight into language and script requirements, ensures that the fonts are a useful tool for everyone. The right font used correctly can increase accessibility to information and increase productivity. With today’s gift, we expect to see widespread adoption of the Ubuntu fonts from today, as it combines design at its best with simple distribution through the Google Font API.”

Google is excited to be providing such a high quality font to the world, with all of the benefits of web fonts including amazing searchability and accessibility. Web fonts demonstrate the true power of the web, as web pages can be translated and still preserve a rich visual presentation - something not possible with any other technology, especially baking text into images. The Canonical Design blog has a history of the fonts’ development and as the language coverage increases throughout 2011, users will automatically get those improvements along with the performance and reliability they can expect from Google. I hope that people have fun over the holidays adding the Ubuntu web fonts to their sites!

Posted by Raph Levien, Google Fonts


Monday, December 20, 2010

[Gd] It’s not “rooting”, it’s openness

| More

Android Developers Blog: It’s not “rooting”, it’s openness

[This post is by Nick Kralevich, an engineer on the Android Security Team. — Tim Bray]

“Nexus S has been rooted, let the madness commence!” proclaims Engadget. “This is only possible because Android's security is crap and it's exploited easily to gain root priviledges [sic]” adds a commenter.

You’ll have to excuse me if I strongly disagree.

The Nexus S, like the Nexus One before it, is designed to allow enthusiasts to install custom operating systems. Allowing your own boot image on a pure Nexus S is as simple as running fastboot oem unlock. It should be no surprise that modifying the operating system can give you root access to your phone. Hopefully that’s just the beginning of the changes you might make.

Legitimately gaining root access to your device is a far cry from most rooting exploits. Traditional rooting attacks are typically performed by exploiting an unpatched security hole on the device. Rooting is not a feature of a device; rather, it is the active exploitation of a known security hole.

Android has a strong security strategy, backed by a solid implementation. By default, all Android applications are sandboxed from each other, helping to ensure that a malicious or buggy application cannot interfere with another. All applications are required to declare the permissions they use, ensuring the user is in control of the information they share. And yes, we aggressively fix known security holes, including those that can be used for rooting. Our peers in the security community have recognized our contribution to mobile security, and for that, we are extremely grateful.

Unfortunately, until carriers and manufacturers provide an easy method to legitimately unlock devices, there will be a natural tension between the rooting and security communities. We can only hope that carriers and manufacturers will recognize this, and not force users to choose between device openness and security. It’s possible to design unlocking techniques that protect the integrity of the mobile network, the rights of content providers, and the rights of application developers, while at the same time giving users choice. Users should demand no less.


[Gd] A helping holiday hand: Website clinic for non-profits

| More

Official Google Webmaster Central Blog: A helping holiday hand: Website clinic for non-profits

Webmaster Level: Beginner

Cross-posted on the Google Grants Blog

A New Year’s resolution
In the spirit of the holidays, here at Google we wanted to take the time to help out those who spend their days making our world a better place: non-profit organizations. A few weeks back, we asked webmasters of non-profits to submit their organization’s site to our Search Quality team for analysis. After some number crunching and trend analysis, we’re back to report on general areas for improvement and to guide you towards some useful resources!

Making our list, checking it twice
First, we’d like thank all of the amazing organizations who participated by submitting their sites. We got some great results, and are excited about all the diverse non-profit causes out there.

Our analysis will take place in the following two posts. The first post will focus on cleaning up HTML tags in your source code, while the second will examine improving user experience via better content accessibility.

Visions of... URLs... dancing in our heads
The great news is, every single site submitted had at least one or two areas to tweak to make it even better! So this information should be helpful to everyone out there, big or small. Just to whet your appetites, here’s a quick list of items that will not be addressed in our following posts, but that had some room for improvement in a large percentage of submitted sites:
  • Keep an eye on proper canonicalization: 56% of analyzed non-profit sites could improve their canonicalization practices. You can read more about canonicalization in this blog post from a previous site clinic.
  • Make sure your volunteer/support sections are visible: 29% of our submissions could improve their sites by making their support, volunteer, or donation sections easier to find. A great way to accomplish this is to add a donations tab to your navigation bar so it’s just one click away at all times.
  • Protect your confidential information: Lots of non-profits, especially those in the medical industry, deal with some very important and confidential information. Read up on how to control your crawled and indexed content, and remember to protect confidential content through proper authentication measures.
  • Make your Flash sites search engine friendly: We saw some beautiful sites running on Flash. Search engines have a hard time understanding Flash files, and we’re working to improve Flash comprehension on our end, but here are some discussion points on how you can help us understand your Flash content.
Posted by Alexi Douvas and Jen Lee, Search Quality Evaluation Team
Contributors: Aditya Goradia, Brandon Falls, Charlene Perez, Diara Dankert, Michael Wyszomierski, & Nelson Bradley

Sunday, December 19, 2010

[Gd] Dive deeper with the reference documentation sidebar

| More

AdWords API Blog: Dive deeper with the reference documentation sidebar

There are a wide variety of resources available for those learning about the AdWords API, but since they’re spread out across multiple sites it’s not always easy to find the information you’re looking for. While we acknowledge the need for these multiple sources, we knew we could do more to bring together our content from Blogger, YouTube, Google Code, and Twitter. We saw the official reference documentation as a good home for the information, and so we’ve added a new sidebar to the service-level pages that displays related material.

The code examples are pulled from our client libraries, and they provide concrete examples of the services in action. The blog posts are pulled from this blog, and contain deep dives into the services, explaining the behaviors and use cases they are suited for. The videos are pulled from our YouTube playlist, and feature recordings from our developer workshops across the world. The tweets are pulled from our @adwordsapi account, and often contain short tips on how to use the services more efficiently.

The sidebar uses the Google Feeds API to pull data from our multiple repositories, meaning that new content will be automatically displayed as soon as it becomes available. We hope that this sidebar leads to more efficient and effective development against the AdWords API, and if you have feedback or further ideas please reach out to us on the forum.

- Eric Koleda, AdWords API Team