Google Code Blog

Go: A New Programming Language

2009-11-10T15:40:00.000-08:00

Have you heard about Go? We released a new, experimental systems programming language today. It is open source and we're excited about sharing it with the development community. For more information, check out the Google Open Source blog.

By Robert Griesemer, Rob Pike, Ken Thompson, Ian Taylor, Russ Cox, Jini Kim and Adam Langley - The Go Team

Use compression to make the web faster

2009-11-09T12:00:00.000-08:00

Every day, more than 99 human years are wasted because of uncompressed content. Although support for compression is a standard feature of all modern browsers, there are still many cases in which users of these browsers do not receive compressed content. This wastes bandwidth and slows down users' interactions with web pages.

Uncompressed content hurts all users. For bandwidth-constrained users, it takes longer just to transfer the additional bits. For broadband connections, even though the bits are transferred quickly, it takes several round trips between client and server before the two can communicate at the highest possible speed. For these users the number of round trips is the larger factor in determining the time required to load a web page. Even for well-connected users these round trips often take tens of milliseconds and sometimes well over one hundred milliseconds.

In Steve Souders' book Even Faster Web Sites, Tony Gentilcore presents data showing the page load time increase with compression disabled. We've reproduced the results for three highest ranked sites from the Alexa top 100 with permission here:

Data, with permission, from Steve Souders, "Chapter 9: Going Beyond Gzipping," in Even Faster Web Sites (Sebastapol, CA: O'Reilly, 2009), 122.

The data from Google's web search logs show that the average page load time for users getting uncompressed content is 25% higher compared to the time for users getting compressed content. In a randomized experiment where we forced compression for some users who would otherwise not get compressed content, we measured a latency improvement of 300ms. While this experiment did not capture the full difference, that is probably because users getting forced compression have older computers and older software.

We have found that there are 4 major reasons why users do not get compressed content: anti-virus software, browser bugs, web proxies, and misconfigured web servers. The first three modify the web request so that the web server does not know that the browser can uncompress content. Specifically, they remove or mangle the Accept-Encoding header that is normally sent with every request.

Anti-virus software may try to minimize CPU operations by intercepting and altering requests so that web servers send back uncompressed content. But if the CPU is not the bottleneck, the software is not doing users any favors. Some popular antivirus programs interfere with compression. Users can check if their anti-virus software is interfering with compression by visiting the browser compression test page at Browserscope.org.

By default, Internet Explorer 6 downgrades to HTTP/1.0 when behind a proxy, and as a result does not send the Accept-Encoding request header. The table below, generated from Google's web search logs, shows that IE 6 represents 36% of all search results that are sent without compression. This number is far higher than the percentage of people using IE 6.

Data from Google Web Search Logs

There are a handful of ISPs, where the percentage of uncompressed content is over 95%. One likely hypothesis is that either an ISP or a corporate proxy removes or mangles the Accept-Encoding header. As with anti-virus software, a user who suspects an ISP is interfering with compression should visit the browser compression test page at Browserscope.org.

Finally, in many cases, users are not getting compressed content because the websites they visit are not compressing their content. The following table shows a few popular websites that do not compress all of their content. If these websites were to compress their content, they could decrease the page load times by hundreds of milliseconds for the average user, and even more for users on modem connections.

Data generated using Page Speed

To reduce uncompressed content, we all need to work together.

Corporate IT departments and individual users can upgrade their browsers, especially if they are using IE 6 with a proxy. Using the latest version of Firefox, Internet Explorer, Opera, Safari, or Google Chrome will increase the chances of getting compressed content. A recent editorial in IEEE Spectrum lists additional reasons - besides compression - for upgrading from IE6.
Anti-virus software vendors can start handling compression properly and would need to stop removing or mangling the Accept-Encoding header in upcoming releases of their software.
ISPs that use an HTTP proxy which strips or mangles the Accept-Encoding header can upgrade, reconfigure or install a better proxy which doesn't prevent their users from getting compressed content.
Webmasters can use Page Speed (or other similar tools) to check that the content of their pages is compressed.

For more articles on speeding up the web, check out http://code.google.com/speed/articles/.

By Arvind Jain, Engineering Director and Jason Glasgow, Staff Software Engineer

Introducing Closure Tools

2009-11-05T10:30:00.000-08:00

Millions of Google users worldwide use JavaScript-intensive applications such as Gmail, Google Docs, and Google Maps. Like developers everywhere, Googlers want great web apps to be easier to create, so we've built many tools to help us develop these (and many other) apps. We're happy to announce the open sourcing of these tools, and proud to make them available to the web development community.

Closure Compiler
Closure Compiler is a JavaScript optimizer that compiles web apps down into compact, high-performance JavaScript code. The compiler removes dead code, then rewrites and minimizes what's left so that it will run fast on browsers' JavaScript engines. The compiler also checks syntax, variable references, and types, and warns about other common JavaScript pitfalls. These checks and optimizations help you write apps that are less buggy and easier to maintain. You can use the compiler with Closure Inspector, a Firebug extension that makes debugging the obfuscated code almost as easy as debugging the human-readable source.

Because JavaScript developers are a diverse bunch, we've set up a number of ways to run the Closure Compiler. We've open-sourced a command-line tool. We've created a web application that accepts your code for compilation through a text box or a RESTful API. We are also offering a Firefox extension that you can use with Page Speed to conveniently see the performance benefits for your web pages.

Closure Library
Closure Library is a broad, well-tested, modular, and cross-browser JavaScript library. Web developers can pull just what they need from a wide set of reusable UI widgets and controls, as well as lower-level utilities for the DOM, server communication, animation, data structures, unit testing, rich-text editing, and much, much more. (Seriously. Check the docs.)

JavaScript lacks a standard class library like the STL or JDK. At Google, Closure Library serves as our "standard JavaScript library" for creating large, complex web applications. It's purposely server-agnostic and intended for use with the Closure Compiler. You can make your project big and complex (with namespacing and type checking), yet small and fast over the wire (with compilation). The Closure Library provides clean utilities for common tasks so that you spend your time writing your app rather than writing utilities and browser abstractions.

Closure Templates
Closure Templates grew out of a desire for web templates that are precompiled to efficient JavaScript. Closure Templates have a simple syntax that is natural for programmers. Unlike traditional templating systems, you can think of Closure Templates as small components that you compose to form your user interface, instead of having to create one big template per page.

Closure Templates are implemented for both JavaScript and Java, so you can use the same templates both on the server and client side.

Closure Compiler, Closure Library, Closure Templates, and Closure Inspector all started as 20% projects and hundreds of Googlers have contributed thousands of patches. Today, each Closure Tool has grown to be a key part of the JavaScript infrastructure behind web apps at Google. That's why we're particularly excited (and humbled) to open source them to encourage and support web development outside Google. We want to hear what you think, but more importantly, we want to see what you make. So have at it and have fun!

By the Closure Tools team

New personalization features in Google Friend Connect

2009-11-04T08:50:00.000-08:00

Today, we're excited to announce several new features for Google Friend Connect that make it possible for website owners to get to know their users, encourage users to get to know each other, and match their site content (including Google ads) to visitors' interests. Check out the Google Social Web Blog for an overview of these new features.

We also want to point out that there are APIs for developers who want to play with the interests data programmatically. With the new interest data described on the Social Web Blog, developers can write custom polls and access the interests data directly. Friend Connect provides API level access to both individual interests information as well as aggregate information for all users of a site. Interests information can be added programmatically for the signed-in user or via the poll gadget, and it can be accessed via both the JavaScript API and the OpenSocial REST API. The Guitar Universe example site should give you an idea of some of the things that are possible with this new launch.

As always, feel free to ask technical questions related to the Friend Connect APIs in the developer forum.

By Mussie Shore, Product Manager, Google Friend Connect

OAuth Enhancements

2009-11-03T09:05:00.000-08:00

Google has recently added three important enhancements to our OAuth support:

The ability to use OAuth without registration
Support for software apps installed on a computer or mobile phone
Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization

Below is an overview of each enhancement, or you can refer to our updated OAuth documentation.

1. The ability to use OAuth without registration

Based on consistent feedback from our developers, we added the ability to use OAuth without having to register the website ahead of time. This change is especially helpful for developers working on test servers that cannot be accessed directly from the Internet.

2. Support for software apps installed on a computer or mobile phone

Many of the larger enterprises that use the Google Apps service choose to run their own login system. They accomplish this by leveraging our support for the SAML protocol which defines a way for Google to redirect the user to the company's login system to be authenticated before accessing their mailbox at Google. However, in this situation Google normally does not have a password for the user — especially if the enterprise authenticates the user with a password and with a second factor of authentication (such as a token generator they carry on a keychain). Unfortunately, there are many installed software applications created by both Google and ISV developers that use Google's APIs, and those applications are hardcoded to ask a user for their email and password using Google's ClientLogin API. With this new OAuth feature, the software application can now launch a web browser and start a process that both logs the user in through their central SAML login system, and that also gets the user's consent to access their data hosted at Google. Because the user authentication is done in the web browser, it will work with the enterprise's existing login system. Google is encouraging any ISV that uses the ClientLogin API to add support for this new OAuth flow, enabling usage by the large enterprise customers described above. Google is also planning to enhance our Google Apps Sync for Microsoft Outlook to support this feature such that Outlook can be used with both Google Apps and an enterprise's central login system.

3. Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization

This feature for our Google Apps Premier customers enhances our existing OAuth for Google Apps domain administrators, also known as 2-legged OAuth. This feature enables domain administrators to allow specific IT apps or third party web services limited access to user accounts via a centralized permissions system under the control of the domain administrator. For example, with this new system, an administrator can use the Google Documents API to configure every user in the domain to have a Google Docs folder named "Human Resources" that is automatically populated with common employee forms. The company might also sign up with an Enterprise SaaS vendor such as Manymoon and specify that Manymoon can access the Google Calendars of all of their users, providing tighter integration with Manymoon's project scheduling features. Previously, this feature required giving the third party vendor access to all of the data that Google stored for that organization, but with this new feature, administrators can limit access to particular data sources (Calendar, Documents, etc). Refer to our documentation for more information.

By Eric Sachs, Product Manager, Google Security

Hybrid Onboarding

2009-11-03T09:00:00.000-08:00

Do you operate a website and wish you could increase the percentage of users who finish the registration process? As discussed on Google's main blog, Google has been working with Plaxo and Facebook to improve the registration success rate for Gmail users. We now see success rates as high as 90%, compared to the 50-60% rate that most websites see with traditional registration mechanisms. This result was achieved using a combination of our OpenID, OAuth and Portable Contacts APIs. While those APIs have been available for over a year, we have added a number of refinements based on our experience with Plaxo and Facebook. Our documentation now has information on those new features, including:

OpenID User Interface Extension 1.0 (including the ability to display the favicon of the website)
x-has-session, which is an enhacement to checkid_immediate requests via the UI extension. If the request includes "openid.ui.x-has-session," it will be echoed in the response only if Google detects an authenticated session
Support for the US Government's GSA profile for OpenID
PAPE (Provider Authentication Policy Extension) to support forced password reprompts
Support for not only Google Accounts, but also our Google Apps customers, as discussed on the Enterprise blog

For more details, please refer to our OpenID documentation.

While these technologies are all standards-based, the methods for how to combine them to achieve this success rate are not obvious, and took a while for the industry to refine. More information is available in the Hybrid Onboarding Guide, but below is a quick summary of some of the best practices for this hybrid onboarding technique:

The technique is primarily for websites with an existing login system based on email addresses.
It also assumes the website will send email to users who are not yet registered, whether it is through traditional email marketing or social network invitations.
The website owner then needs to choose a small set of email providers such as Yahoo and Google that support these standards.
Whenever the website sends email to a user at one of those providers, any hyperlinks that promote registration at the website should be modified to communicate the email address (or at least domain) of the user back to the website's registration page.
If the registration page detects a user from one of these domains, it should NOT start the traditional process of asking the user to enter a password, password confirmation, and email. Instead, it should prominently show a single button that says "Sign up with your Google Account" — where Google is replaced with the name of the email provider.
If the user clicks that button, the website should use the OpenID protocol to ask the email provider to authenticate the user, provide their email address, and optionally ask for access to their address book using the hybrid OpenID/OAuth protocol and the Portable Contacts API. More details about this flow are available on the OpenID blog.
Once the user returns to the website, it can create an account entry for the user. The website can also mark the email address as verified without having to send a traditional "email verification" link to the user. If the website received the user's permission to access their address book, it can now download it and look for information about the user's friends.

In the unusual case where an account already exists for that email address, the website can simply log the user into that pre-existing account.

For any newly registered user, the website should then display a page that confirms the user is registered and that indicates how they should sign in in the future.
To make the login process simple, the website should modify their login box to include a logo for each of the trusted email providers it supports, or use one of the other user experiences for Federated Login.
If a user clicks the email provider button, they can again be sent to that provider's site using the OpenID protocol. When the user comes back, the website can either detect that they previously registered, or if it is a new user, the website can create an account for them on the fly.

In some cases the account may already exist for that email address, but it was not initially registered using OpenID. In that case, the website can simply log the user in to that pre-existing account.

By Eric Sachs, Product Manager, Google Security

Google Analytics API on App Engine Treemap Visualization

2009-10-30T11:30:00.000-07:00

It's Friday, time for some fun!

Here is a captivating way to visualize your Google Analytics data in a Treemap visualization and you can visualize your own data with our live demo.
(note: IE currently not supported for visualization part)

The goal of this example was to teach people how to use the Google Analytics API on App Engine in Java. As well as demonstrating how to use both OAuth and AuthSub along with the App Engine's various services. The code looked great, but the output was a boring HTML table. So I used some open source tools to transform the table into a pretty tree map visualization!

All the code has been open sourced on Google Project hosting. I also wrote an article describing how this application works making it easy for developers to use this example as a starting point for new data visualizations and other Google Data projects.

For the data retrieval part, this example uses the App Engine Java SDK and the Google Analytics Data Export API Java Client Library to retrieve data from Google Analytics. The example code implements both unsigned AuthSub and registered OAuth authorization methods allowing developers to get up and running quickly in development environments and later switch to a secure authorization method in production environments. The application also uses the Model-View-Controller pattern, making it flexible and allowing developers to extend the code for new applications. (like adding support for other Google Data APIs)

For the visualization part, I used the open-sourced Protovis SVG Visualization Library to create the Treemap. This JavaScript library is maintained by the Stanford Visualization Group and excels at creating brand new visualizations from a data set (in this case a boring HTML table). To handle all of the interactions, including rollover, tooltips and slider controls, I used JQuery. Here is the JavaScript source to the visualization part of the sample.

Enjoy!

By Nick Mihailovski, The Google Analytics API Team

P.S. If you have created any cool new visualizations using the Google Analytics Data Export API, email us so we can highlight them as well.

Customize your results snippets with structured data

2009-10-26T15:40:00.001-07:00

Custom Search themes make it easy for you to customize the look and feel of your search results pages. And if you want to take the customization gig further, you can also customize the result snippet—a small sample of content that gives search users an idea of what's in the webpage—by using structured data.

When you are reading a webpage that reviews a film, you can figure out what the title is, what reviewers thought of the film, and how they rated it. You can even search for stores with the best prices for the DVD. Structured data can convey the meaning of such key information to computers.

Structured data formats—such as microformats, RDFa, and PageMaps—are semantic markup that you add to your HTML page. Structured data make web content more meaningful to machines. These attributes do not change the formatting of your website, they just make the text enclosed within the XHTML tags "understandable" by computers and influence what shows up in the result snippets.

When you tag your webpages with structured data, Custom Search indexes them and sends the metadata back in the XML results for your page. You can then take this XML feed and transform it into HTML results that showcase key information—such as image thumbnails, summaries, dates, authorship, ratings, and prices. Having the most relevant information in your search results makes the webpages in your site more compelling to your users.

You can, for example, create the following kind of rich snippets:

You can even add thumbnails and actions that let your users download files or make purchases.

To learn more, read the Custom Search Developer's Guide.

By Kevin Griffin Lim, Custom Search Team

Customize your search results page with themes

2009-10-26T15:40:00.000-07:00

If you can select headgear for your LEGO ® action figures, your search engine should let you customize the theme for your search results page, right? Darn tooting!

True, Custom Search already lets you customize the look and feel of your search results page, but we're making it easier. You can now go to the control panel and select one of the predefined themes that broadly matches the look and feel of your website.

If the standard themes are not quite what you want, you can make further changes. You can tinker with the page layout (Why stick with a single column of results, when you can have two?) and play with the font colors and types. The standard themes paired with the "Compact" layout option are optimized for mobile devices, so they work well on iPhone, Android devices, and Pre.

If you want a greater level of control than that, you can download the CSS, tweak it in a text editor, and host the CSS in your website. You can make your search results page blend with the style of the rest of your website.

To learn more, read the Custom Search Developer's Guide.

By Kevin Gnome Lim, Custom Search Team

Introducing the Website Optimizer Experiment Management API

2009-10-20T12:02:00.000-07:00

Today at the eMetrics conference in Washington DC we announced the new Website Optimizer Experiment Management API. The API allows for the creation and management of experiments outside of the Website Optimizer interface.

If you're not familiar with Google Website Optimizer, it's a free tool for running A/B and multivariate experiments on a website. Website Optimizer handles splitting a website's traffic, serving different variations, and crunching the numbers to find statistical significance.

Creating experiments with Website Optimizer usually involves a lot of back and forth between your website and the Website Optimizer interface. Using the API, you can integrate Website Optimizer into your platform. In short, you can create and launch experiments from whatever tool you use to edit your site.

You'll find more about the GWO API on its Google Code site: http://code.google.com/apis/analytics/docs/gwo/.

You can also join the Website Optimizer engineers for a webinar on the Website Optimizer Experiment Management API. The webinar will be held on October 28th at 10AM PDT. During the webinar, Website Optimizer engineers will walk you through how the API works. Additionally, two platforms that have already integrated using the API will demonstrate their integrations.

You need to register for the webinar, which you can do here. We'll record the webinar as well so you can reference it later.

We're very excited about the Website Optimizer API and what it means for website testing. Let us know your thoughts in the comments.

By Gary Kačmarčík and Erika Rice Scherpelz, Google Website Optimizer team

Let's make the mobile web faster

2009-10-16T18:11:00.000-07:00

This week, we've been celebrating all things mobile across Google. Of course, this wouldn't be complete without a component for mobile web developers! Two months ago we asked you to make the web faster. Now, we've asked the Google Mobile team for some best practices, tips, and resources for mobile web development, and we've come up with a few things we wanted to share. "Go Mobile!" with our Make the mobile web faster article.

By Jeremy Weinstein, Google Webmaster

Issue Tracker Data API for Project Hosting

2009-10-16T12:07:00.000-07:00

I'm excited to announce the Issue Tracker Data API for Project Hosting on Google Code! The Issue Tracker Data API is a Google Data API that you can use to programmatically add new issues, make changes to existing issues, or simply access issues for your open source project.

This means that the issue tracker data for your open source code is now liberated!

To get started with the API, please refer to the following documentation:

Issue Tracker Data API Overview

Issue Tracker Data API for Java

Issue Tracker Data API for Python

Issue Tracker Data API Reference

If you find yourself digging into the API and creating something useful that others can use, please let us know and we'll be sure to add it to our documentation. As always, your feedback is also welcome.

The team would also like to thank Joe LaPenna, who contributed the Python client for the Issue Tracker Data API in his 20% time.

By Jacob Moon, Google Project Hosting

Update: Net::Google::Code now supports the Issue Tracker Data API

"View Source" - a new series about sites using HTML5

2009-10-14T15:13:00.000-07:00

View Source is a new series where we crack open cool web sites and applications and detail how they were made, step by step. The series will be hosted on Ajaxian, but the Code blog will always carry a link to any new posts that come out in the series. We hope that the articles will help you understand how developers out there are using HTML5 and other Open Web technologies.

Here are links to two articles from this series that were published over the last few days:

"View Source Tutorial: Sticky Notes With HTML5 and CSS3"

"View Source Tutorial: Fancy Web Page Using HTML5, CSS, and SVG"

By Brad Neuberg, Google Developer Programs

Mark your calendars for Google I/O 2010

2009-10-12T10:03:00.000-07:00

We're excited to share the dates for Google I/O 2010! Mark your calendars:

Google I/O
May 19 - 20, 2010
Moscone Center, San Francisco

Here's a quick look back at this year's event:

Early registration for I/O 2010 will open in January. Until then, you can follow us on Twitter and check out code.google.com/io.

See you in May!

By Christine Tsai, Google Developer Team

Mercurial server-side clone support for Project Hosting on Google Code

2009-10-09T13:26:00.001-07:00

When we launched Mercurial support our goal was to get to a point where we could enable a social coding experience. Today, I am happy to announce that today we have support for both 'project' clones and 'user' clones.

Project owners can now create multiple repositories for their project, and they can choose to make any of those new repositories a clone of any of the project's other repositories. These project clones share the same commit access permissions as the original project and make it easier for project members to work together on new features. A common pattern in the Mercurial world is to place each "official" branch into a separate repository with naming conventions like "project-crew", "project-stable", and so on.

In addition to project clones, any user can visit any Mercurial repository and create a server-side user clone of that repository, without asking permission from the project owner. These personal user clones can be easily shared with other developers -- who also can make a clone of that clone. Once a user has finished her changes in a user clone, she can coordinate with the canonical project's contributors to review and incorporate her changes.

User clones aren't forks, in the traditional sense, where a fork has little intention to contribute back to the original project. Rather, the entire purpose of a user clone is to allow users to contribute to projects without requiring official commit access permissions. Because mercurial is a distributed (peer-to-peer) version control system, it excels at branching and merging. If the project maintainers like the new code, they just "pull" the changesets from the clone and merge them into an official project repository. It's all much more elegant than emailing patches back and forth, anonymous contributors get to use the same tools as core developers.

The instructions for creating a user clone can be found on the checkout page for any Mercurial project (e.g. twisty) and existing clones for a project can be found under the Clones sub-tab under Source.

Please let us know if you have any feedback or find any issues. Happy cloning!

By Nathaniel Manista and Jacob Lee, Project Hosting on Google Code

Refreshing code.google.com/speed

2009-10-05T15:39:00.000-07:00

Today, we're happy to share some updates on code.google.com/speed with you.

We launched code.google.com/speed in June, to give web developers access to tools and resources that help them improve the performance of their applications. Since then, the developer community provided us with plenty of suggestions on how to improve our site. Based on your feedback, we made the following improvements:

We added new content:

Four new best practice articles on topics such as optimizing JavaScript
Two new tech talks on new developer tools
A blog gadget that aggregates performance related posts from Google blogs.

We improved the layout to make navigation between different tutorials, tech talks and tools smoother.

Just as making the web faster is an ongoing process, we plan to continue updating and enhancing code.google.com/speed with more resources. Currently, we are focusing on increasing community involvement, such as adding more tutorials and tech talks from non-Google authors. So, as a first step, if you have recently written an interesting article on web performance, please let us know by filling in this form. Our team will evaluate all entries and may contact you for potential next steps.

Together, let's make the web faster!

By Yi Wang, Product Manager

SVG at Google and in Internet Explorer

2009-10-02T11:00:00.000-07:00

At Google we're excited about new web technologies like HTML 5, CSS 3, Web Fonts, SVG, faster JavaScript, and more. It's an exciting time to be a web developer, especially with the major advancements made in modern browsers like Firefox, Safari, Opera, and Chrome the last two years. In this blog post I want to share some of the work we've been doing with SVG in particular.

Today kicks off the start of the SVG Open 2009 conference, hosted at Google this year. The SVG Open conference is an annual conference where the SVG community comes together for three-days. Other sponsors of the conference this year include Microsoft and IBM.

What is SVG?

SVG, or Scalable Vector Graphics, is an open web standard that makes it easy to add interactive vector graphics to your web pages. Vector graphics, as opposed to bitmap graphics like JPG, GIF, or PNG files, describe the shapes on your screen with mathematical equations rendered by your computer rather than pixels. This allows vector graphics to stay beautiful and crisp whether displayed on a 40" monitor or a small mobile device.

Just as HTML gives you simple tags such as <form> or <table> to add to your web pages, SVG gives you such graphical tags as <circle> or <rect> for a rectangle that you can drop into your web page. Working with SVG is very similar to working with HTML - you use JavaScript to animate and make things interactive, CSS (Cascading Style Sheets) to add style, etc.

Why Google is Excited About SVG

We're excited about SVG for a host of reasons:

First, SVG is part of the HTML 5 family of technologies. One of the major new features of HTML 5 is the fact that you can now drop SVG tags into normal HTML, directly embedded into your page. We're excited about how this will empower developers. Here, for example, is a small code sample that embeds an SVG circle and rectangle right into an HTML 5 page:

<!DOCTYPE html>
<html>
  <body>
    <h1>SVG/HTML 5 Example</h1>
    <svg>
      <circle id="myCircle"
              cx="100" cy="75" r="50"
              fill="blue"
              stroke="firebrick"
              stroke-width="3" />
      <text x="60" y="155">Hello World</text>
        </svg>
  </body>
</html>

Produces:

Second, we like that SVG is composed of text and markup, just like HTML. Because it's markup, search engines have a much easier time working with SVG; server-side languages like PHP or Google App Engine can simply emit SVG just like they generate HTML; and users and developers can easily view the source just like a normal web page to learn and move things forward. It's also easy to import and export SVG into tools like the open source Inkscape drawing package or Adobe Illustrator.

Third, the compact size of SVG when combined with HTTP GZip compression can easily make the images on a page roughly an order of magnitude smaller, and when directly embedded into an HTML 5 page can decrease the latency of a page by reducing the number of fetches. Small and fast are definitely two things we like at Google, and we like that SVG helps enable both.

Fourth, SVG integrates with the rest of the web stack, including JavaScript, CSS, and the DOM (Document Object Model). Even better, developers can easily adapt the skills they already know when working with SVG.

Finally, SVG is an open standard that is vendor-neutral. It also has accessibility built in, so when screen readers start to work with SVG your content will be future-proofed with accessibility baked in. We also like that SVG is now natively supported on all modern browsers, including the iPhone.

What Are Some Places We Use SVG?

We use SVG ourselves in a range of products. In Google Docs, for example, you can insert drawings, illustrations, and diagrams using a built in drawing tool:

On all browsers we use SVG to build this user interface; on Internet Explorer we have to revert to an older technology named Vector Markup Language (VML) unfortunately.

Another example is the Google Visualization API, which lets you access multiple sources of structured data that you can display, choosing from a large selection of visualizations. Some of these visualizations (such as this one and this one) use SVG to do their drawing on all browsers except Internet Explorer.

Canvas Or SVG? Oh My!

A natural question is how SVG compares to the Canvas tag. In our opinion both are needed for the web and are suitable for different applications.

The Canvas tag can best be thought of as a scriptable image tag that you build up yourself using JavaScript. This means it is lower-level, requiring you to keep track of all objects you have placed on the canvas. This can be a benefit if you want to do a large degree of non-interactive animation, but can quickly become a burden if you need to build sophisticated user interfaces.

SVG, meanwhile, is higher-level, doing the bookkeeping necessary to keep track of where everything is, making things like mouse interaction much easier. If you don't need this interaction, however, the overhead imposed by SVG can get in the way of certain applications. Because SVG is markup, importing and exporting is much easier, including SEO and accessibility.

We believe that Canvas versus SVG is a false dichotomy. A great example of both technologies working together is the Firefox Download Tracker. This page shows real time updates across the world whenever a copy of Firefox is downloaded. SVG is used to draw the map of the world; this is an appropriate use, since we don't want thousands of lines of JavaScript for this but rather markup from a tool like Inkscape. Red circles are drawn on top of the SVG using the Canvas tag as copies are downloaded; this is perfect for Canvas as the circles are non-interactive and might number in the thousands if copies are being downloaded rapidly.

SVG In Internet Explorer and in Wikipedia

Now that you know a bit more about SVG, why we like it, and some of the places we use it, let me tell you a bit about some of the work we've been doing to support SVG lately.

In addition to hosting this years conference, we are also helping to address the fact that SVG can't be used on Internet Explorer. It's hard for developers to use new web technologies if they can't deploy them on IE. In response to this, we've been working with others in the open source community on a drop-in JavaScript library named SVG Web that brings SVG to Internet Explorer.

SVG Web cleverly uses existing facilities on Internet Explorer 6, 7, and 8 to instantly enable SVG support without the user having to download any new software or plugins. Using SVG Web plus native SVG support you can now target close to 100% of the existing installed web base, today. Before SVG Web you could only target about ~30% of web browsers with SVG.

Once dropped in SVG Web gives you partial support for SVG 1.1, SVG Animation (SMIL), Fonts, Video and Audio, DOM and style scripting through JavaScript, and more in about a 60K library. Your SVG content can be embedded directly into normal HTML 5 or through the OBJECT tag. If native SVG support is already present in the browser then that is used. No downloads or plugins are necessary other than Flash which is used for the actual rendering, so it's very easy to use and incorporate into an existing web site. Here's a quick one minute introduction to SVG Web:

SVG Web is currently in alpha and is a developer release. It's also important to note that it is a collaboration with many others in the open source community outside Google, including Rick Masters at F5 Networks and James Hight at Zavoo Labs. Google is just one participant in this open source project. Finally, a JavaScript library will never be as fast as native support; this doesn't take Internet Explorer off the hook for needing to implement SVG, but it does help developers in the here and now deploy their SVG today to get the wheel turning.

In addition to helping enable SVG on Internet Explorer, we've been working with Wikipedia. Wikipedia has an impressively large collection of SVG files that are under Creative Commons licenses. Every one of these files is available in the Wikimedia Commons; for example here is the Linux penguin Tux as SVG. We've been working with Wikipedia to enable interactive zooming and panning of these SVG files, similar to Google Maps; even better, this functionality works in Internet Explorer thanks to the SVG Web library on the sixth largest site on the web.

Today at the SVG Open show we are demoing a prototype of the Wikipedia SVG Zoom and Pan tool; deployment to the wider base of Wikipedia users will happen after the conference and an appropriate QA period. Here's a screencast showing the tool in action:

We hope you are as excited as we are about SVG and other new web technologies in the pipeline!

By Brad Neuberg, Google Developer Programs

Chris Anderson: CouchDB: Relaxing Offline JavaScript

2009-09-28T17:12:00.000-07:00

Last week I hosted Chris Anderson for a Google tech talk on CouchDB as part of the Web E^xponents speaker series. Chris is an Apache CouchDB committer. He is co-author of the forthcoming O'Reilly book CouchDB: The Definitive Guide and a director of couch.io.

Making web applications work offline is a hot topic. Google Gears blazed the trail, and Web Storage is part of HTML5. CouchDB is a NoSQL alternative that makes it easy for web apps to run offline. This is important because even as bandwidth grows, latency is still an issue for a significant number of users, and outages or zero-bars can and do happen. CouchDB makes this a non-issue by running your application close to the user, on their device or in their browser. Chris calls this "ground computing" - a refreshing counterpoint to the oft-used "cloud computing" label. Hear more from Chris in his video and slides.

Check out other videos in the Web Exponents speaker series:

By Steve Souders, Performance Evangelist

Google Sites: Now with an API!

2009-09-24T16:00:00.000-07:00

Today, we launched a new Google Data API for Google Sites. The API supports most of the functionality found in Google Sites, which includes the ability to:

Retrieve, create, modify, and delete pages and content.
Upload/download attachments.
Review the revision history across a site.
Display recent user activity.

To get started, see the full documentation, Java Developer's Guide, or dive into our code samples. We're also open-sourcing an import/export tool that uploads or creates a local back-up of an entire Google Site.

Visit us in our new developer forum if you have questions!

By Eric Bidelman, Google Sites API Team

Gmail for Mobile HTML5 Series: CSS Transforms and Floaty Bars

2009-09-23T12:42:00.000-07:00

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week, I'll talk about different ways to animate the floaty bar.

Even from the earliest brainstorming days for our new version of Gmail for iPhone and Android-powered devices, we knew we wanted to try something novel with menu actions: a context-sensitive, always-accessible UI element that follows conveniently as a user scrolls. Thus, the "floaty bar" was born! It took us a surprisingly long time, experimenting with different techniques and interactions, to converge on the design you see today. Let's look under the covers to see how the animation is achieved. You may be surprised to find that the logic is actually quite simple!

Screenshots of the floaty bar in action

In CSS:

.CSS_FLOATY_BAR {
 ...
 top: -50px;  /* start off the screen, so it slides in nicely */
 -webkit-transition: top 0.2s ease-out;
 ...
}

In JavaScript:

// Constructor for the floaty bar
gmail.FloatyBar = function() {
 this.menuDiv = document.createElement('div');
 this.menuDiv.className = CSS_FLOATY_BAR;
 ...
};

// Called when it's time for the floaty bar to move
gmail.FloatyBar.prototype.setTop = function() {
 this.menuDiv.style.top = window.scrollY + 'px';
};

// Called when the floaty bar menu is dismissed
gmail.FloatyBar.prototype.hideOffScreen = function() {
 this.menuDiv.style.top = '-50px';
};

gmail.floatyBar = new gmail.FloatyBar();

// Listen for scroll events on the top level window
window.onscroll = function() {
 ...
 gmail.floatyBar.setTop();
 ...
};

The essence here is that when the viewport scrolls, the floaty bar 'top' is set to the new viewport offset. The -webkit-transition rule specifies the animation parameters. (The 'top' property is to be animated, over 0.2s, using the ease-out timing function.) This is the animation behavior we had at launch, and it works just fine on Android and mobile Safari browsers.

However, there's actually a better way to achieve the same effect, and the improvement is particularly evident on mobile Safari. The trick is to use "CSS transforms". CSS transforms is a mechanism for applying different types of affine transformations to page elements, specified via CSS. We're going to use a simple one which is translateY. Here's the same logic, updated to use CSS transforms.

In CSS:

.CSS_FLOATY_BAR {
 ...
 top: -50px;  /* start off the screen, so it slides in nicely */
 -webkit-transition: -webkit-transform 0.2s ease-out;
 ...
}

In JavaScript:

// Called when it's time for the floaty bar to move
gmail.FloatyBar.prototype.setTop = function() {
 var translate = window.scrollY - (-50);
 this.menuDiv.style['-webkit-transform'] = 'translateY(' + translate + 'px)';
};

// Called when the floaty bar menu is dismissed
gmail.FloatyBar.prototype.hideOffScreen = function() {
 this.menuDiv.style['-webkit-transform'] = 'translateY(0px)';
};

Upon every scroll event, the floaty bar is translated vertically to the new viewport offset (modulo the offscreen offset which is important to the floaty bar's initial appearance). And, why exactly is this such an improvement? Even though the logic is equivalent, iPhone OS's implementation of CSS transforms is "performance enhanced", whilst our first iteration (animating the 'top' property) is performed by the OS in software. That's why the experience was unfortunately somewhat chunky at times, depending on the speed of the iPhone hardware.

You'll see smoother looking floaty bars coming very soon to an iPhone near you. This is just the first in a series of improvements we're planning for the mobile Gmail floaty bar. Watch for them in our iterative webapp, rolling out over the next couple of weeks and months!

By Joanne McKinley, Software Engineer, Google Mobile

Previous posts from Gmail for Mobile HTML5 Series:
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance
Cache pattern for offline HTML5 web application
Using timers effectively
Autogrowing Textareas
Reducing Startup Latency

Announcing the Google Sidewiki API

2009-09-23T09:06:00.000-07:00

Alongside the exciting release of Google Sidewiki today, we're also happy to announce the availability of the first version of the Google Sidewiki Data API. Google Sidewiki is a new feature of Google Toolbar (for Firefox and Internet Explorer) that lets everyone contribute helpful information next to any webpage. Our post over on the Google Blog goes into more detail and also has a video that shows Sidewiki in action. To start using it yourself, go to google.com/sidewiki and install Google Toolbar with Sidewiki.

On the developer side, we're releasing a Google Sidewiki Data API today that lets you work freely with the content that's created in Google Sidewiki. You can use it to retrieve all entries written about a particular webpage as well as all entries written by a given Sidewiki author.

So after you've played with Sidewiki in the browser, give it a whirl in your console too -- we have client libraries, documentation and code samples ready to go for you. We'll be excited to see what gadgets, projects and extensions you'll think of. A translation gadget that displays and translates Sidewiki entries on the fly? A Google App Engine-powered browser of all Sidewiki entries? Your own browser extension or Greasemonkey script?

The Google Sidewiki API is available in Google Code Labs and is read-only at the moment. We've set up a developer-oriented discussion group and issue tracker where you can discuss your experiences with the API and where we'd love to hear about your feedback and projects. Keep us posted!

By Roman Shuvaev, Google Sidewiki engineer

Video Introduction to HTML 5

2009-09-22T15:00:00.000-07:00

Are you interested in HTML 5 and what's coming down the pipeline but haven't had time to read any articles yet? We've put together an educational Introduction to HTML 5 video that goes over many of the major aspects of this new standard, including:

Web vector graphics with the Canvas tag and Scalable Vector Graphics (SVG)
The Geolocation API
HTML 5 Video
The HTML 5 Database and Application Cache
Web workers

In the video we also crack open the HTML 5 YouTube Video prototype to show you some of the new HTML 5 tags, such as nav, article, etc. It's chock full of demos and sample source code.

By Brad Neuberg, Google Developer Programs

Introducing Google Chrome Frame

2009-09-22T11:12:00.000-07:00

Today, we're releasing an early version of Google Chrome Frame, an open source plug-in that brings HTML5 and other open web technologies to Internet Explorer.

We're building Google Chrome Frame to help web developers deliver faster, richer applications like Google Wave. Recent JavaScript performance improvements and the emergence of HTML5 have enabled web applications to do things that could previously only be done by desktop software. One challenge developers face in using these new technologies is that they are not yet supported by Internet Explorer. Developers can't afford to ignore IE -- most people use some version of IE -- so they end up spending lots of time implementing work-arounds or limiting the functionality of their apps.

With Google Chrome Frame, developers can now take advantage of the latest open web technologies, even in Internet Explorer. From a faster Javascript engine, to support for current web technologies like HTML5's offline capabilities and <canvas>, to modern CSS/Layout handling, Google Chrome Frame enables these features within IE with no additional coding or testing for different browser versions.

To start using Google Chrome Frame, all developers need to do is to add a single tag:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

When Google Chrome Frame detects this tag it switches automatically to using Google Chrome's speedy WebKit-based rendering engine. It's that easy. For users, installing Google Chrome Frame will allow them to seamlessly enjoy modern web apps at blazing speeds, through the familiar interface of the version of IE that they are currently using.

We believe that Google Chrome Frame makes life easier for web developers as well as users. While this is still an early version intended for developers, our team invites you to try out this for your site. You can start by reading our documentation. Please share your feedback in our discussion group and file any bugs you find through the Chromium issue tracker.

(Cross-posted on the Chromium Blog)

By Amit Joshi, Alex Russell and Mike Smith, Google Chrome Frame Team

Registration Opens for fall 2009 Google Developer Days

2009-09-15T13:50:00.000-07:00

We are excited to open registration for our second round of Google Developer Day events this year:

November 6, 2009 -- Prague, Czech Republic
November 10, 2009 -- Moscow, Russia

Both events will offer opportunities to learn the latest about our APIs and developer tools, including Android, Google Chrome, Google Wave, App Engine, AJAX APIs and more. There will also be time for developers to socialize - whether at "office hours" or the "after hours". You'll be able to chat about your latest project or discuss that brain-busting question with fellow developers and Google engineers.

Similar to our Google I/O event in the US, the Developer Days will host a developer sandbox area, highlighting partners who have used Google developer products to build their own unique applications. You can also take the opportunity to share a project or coding experience during our lightning talks. We look forward to seeing what developers bring to the table this year!

Space is limited so register soon!

By Alyssa England Sachs, Google Developer Programs

Legacy gadget API deprecation

2009-09-14T15:57:00.000-07:00

If you're a gadget developer, you've probably used the gadgets.* API, a re-namespaced and improved version of the original legacy, or _IG_*, gadgets API. The gadgets.* API has gained wide acceptance, both on Google and non-Google gadget containers, and is the standard API for gadget development.

However, there remains a number of gadgets using the legacy API, primarily gadgets developed for iGoogle, and the time to upgrade those gadgets is now. As of today, the legacy gadgets API is officially deprecated. For a period of one year, gadgets using the legacy API will continue to be supported, and function. After that, the legacy API will be turned off for the majority of Google containers (such as iGoogle, orkut, Gmail, and Calendar).

For more specifics on how the deprecation affects iGoogle developers, and details on coming resources to help in the API transition, check out this post on the iGoogle developer blog.

By Dan Holevoet, Developer Programs