By Dan Holevoet, Developer Programs

We're happy to announce the launch of the canvas view feature to iGoogle users in the U.S., rolling out over the course of the day.  The canvas view feature allows gadget developers to build richer content, games, and UI for iGoogle's tens of millions of users by allowing them to build powerful full-page applications. In addition, canvas view provides developers with the opportunity to monetize their gadgets.



To get started, check out the documentation and examples on the iGoogle developer website. The site includes detailed information about iGoogle as well as information on upcoming OpenSocial functionality.

Try out the updated version of iGoogle and check out some of the great canvas view gadgets developers have already built.

By Jacob Lee and Ali Pasha, Google Code

Gadgets and Google Code have always had a special relationship, as many developers use Google Code to host their gadgets. We are, therefore, happy to announce that you can now add gadgets to any wiki page (including the project homepage) on Google Code using the <wiki:gadget> syntax shown below.

<wiki:gadget url="http://www.ohloh.net/projects/gwt/widgets/project_cocomo.xml" border="0">

To show you how powerful this is, we created a page of gadgets we found useful. See MarkMail's announcement and Ohloh's announcement for more details about their gadgets.

While gadgets are a great way to bring content to Google Code, they are also a great way to take a little piece of Google Code with you. Take the google-web-toolkit issue tracker as an example:



They enable you to create your own personal dashboard. In fact, this is how I track my various projects. To enable this, new Google Code project hosting gadgets are now available for each project on Google Code. They can be discovered under the feeds link in the project homepage.

http://code.google.com/p/google-web-toolkit/feeds
http://code.google.com/p/wikia/feeds

Let us know what you think! We'd love to hear your ideas on how to make the Gadgets integration on Google Code even better!

As always, we look forward to your feedback.

By Dion Almaer, Google Developer Programs



We have so much respect for the Zoho team here at Google. They produce great software, and they do it regularly! Their latest accomplishment has been getting their email product, Zoho Mail, working offline.

Brad Neuberg sat down with the guys to chat about this new release. He delves into the offline flow of the product, and then into the architecture behind it. How do they handle syncing? What features do they turn off when you are offline? How explicit to you have to be? Listen in to hear their thoughts!

By Jacob Moon and Jacob Lee, Google Code

We are happy to announce that we just launched project update streams (and feeds) for each open source project on Google Code. The new project updates page, which is linked to from each project homepage, shows the updates that are occurring in the project.

One of the benefits of open source software development is that you can watch how the software is built. Take a look at the updates of some popular open source projects:

• http://code.google.com/p/google-web-toolkit/updates/list
• http://code.google.com/p/fbug/updates/list
• http://code.google.com/p/digg/updates/list
  

These updates are also available as feeds. Here are the feeds for the urls above:

• http://code.google.com/feeds/p/google-web-toolkit/updates/basic
• http://code.google.com/feeds/p/fbug/updates/basic
• http://code.google.com/feeds/p/digg/updates/basic

By Steve Lamm, Member of Technical Staff

Let's say you figured out a wicked-cool way to speed up how quickly your website loads. You know with great certainty that the most popular web page will load much, much faster. Then, you remember that the page always loads much, much faster in your browser with the web server running on your development box. You need numbers that represent what your users will actually experience.

Depending on your development process, you may have several measuring opportunities such as after a live release, on a staging server, on a continuous build, or on your own development box.

Only a live release gives numbers that users experience--through different types of connections, different computers, different browsers. But, it comes with some challenges:

• You must instrument your site (one example tool is jiffy-web).
• You must isolate changes.
  • The most straight-forward way to do that is to release only one change at a time. That avoids having multiple changes altering performance numbers--for better or for worse--at the same time.
• Consider releasing changes to a subset of users.
  • That helps safe-guard against real-world events like holidays, big news days, exploding hard drives, and, perhaps the worst possible fate of all: a slashdotting.

Measuring real traffic is important, but performance should also be measured earlier in the development process. Millions of users will not hit your development web server--they won't, right?! You need a way to measure your pages without that.

Today, Steve Souders has released Hammerhead, a Firefox plug-in that is just the ticket for measuring web page load times. It has a sweet feature that repeatedly loads pages both with and without the browser cache so you can understand different use cases. One thing Hammerhead will not do for you is slow down your web connection. The page load times that you measure on your development machine will likely be faster than your users' wildest dreams.

Measuring page load times with a real DSL or dial up connection would be ideal, but if you cannot do that, all hope is not lost. You can try the following tools that simulate slower connection speeds on a single box:

• Firefox Throttle (Firefox plug-in, windows-only, free)
• Fiddler: Web Debugging Proxy (free)
• Charles: Web Debugging Proxy (shareware, $50)

Please share your own favorite tools in the comments. Each of these tools is super easy to install and setup options to simulate slower connections. However, they each have some caveats that you need to keep in mind.

Firefox Throttle hooks into the WinSock API to limit bandwidth and avoids using proxy settings. (If you use it, be sure to disable "burst-mode".) Right now, Firefox Throttle only limits bandwidth. That means it controls how much data arrives in a given time period after the first bits arrive. It does not limit latency. Latency controls how long it takes packets to travel to and from the server. See Wikipedia's Relationship between latency and throughput for more details. For certain webpages, latency can make up a large part of the overall load time. The next Firefox Throttle release is expected to include latency delays and other webmaster friendly features to simulate slower, less-reliable connections. With these enhancements, Firefox Throttle will be an easy recommendation.

Fiddler and Charles act as proxies, and, as a result they make browsers act rather differently. For instance, IE and Firefox drastically limit the maximum number of connections (IE8 from 60+ to 6 and FF3 from 30 to 8). If you happen to know that all your users go though a proxy anyway, then this will not matter to you. Otherwise, it can mean that web pages load substantially differently.

If you have more time and hardware with which to tinker, you may want to check out tools like dummynet (FreeBSD or Mac OS X), or netem (Linux). They have even more knobs and controls and can be put between the web browser hardware and the serving hardware.

Measurements at each stage of web development can guide performance improvements. Hammerhead combined with a connection simulator like Firefox Throttle can be a great addition to your web development tool chest.

By Nir Bar-Lev, Google Visualization Team

We recently came across a great use of the Visualization Platform. In fact, this is something that we never thought the platform would be used for.

Steve Aitken, a developer contributing to the Visualization Developer Group, created a simple graphics calculator for Javascript-supported math functions that plots functions using the Google Visualization Scatter Chart. Here is a screenshot of a simple calculation of -sin(2x):



Steve has been kind enough to share the code with us (even though it was originally written for his girlfriend). A slightly modified version is pasted below:

<html>
  <head>
    <script type="text/javascript" src="http://www.google.com/jsapi"></script>
    <script type="text/javascript">
      google.load("visualization", "1", {packages:["scatterchart"]});
      function drawChart(equation,xmin,xmax, numPoints, pointSize) {
        var data = new google.visualization.DataTable();
        data.addColumn('number', 'x');
        data.addColumn('number', 'y');
        data.addRows(numPoints);
        var step = (xmax-xmin) / (numPoints-1);
        for(var i = 0; i < numPoints; i++)
        {
          var x = xmin + step * i;
          data.setValue(i,0,x);
          with(Math) {
            var y = eval(equation);
          }
          data.setValue(i,1,y);
        }
        document.getElementById("chart_div").innerHTML = "";
        var chart = new google.visualization.ScatterChart(
            document.getElementById('chart_div'));
        chart.draw(data, {width: 600, height: 400, titleX: 'X',
            titleY: 'Y', legend: 'none', pointSize: pointSize});
      }
    </script>
  </head>

  <body>
      equation: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
      <input id="txteq" type="text" value="-sin(2*x)" />
      <br />
      minimum value(x): &nbsp;<input id="txtmin" type="text" value="-3.14" />
      <br />
      maximum value(x): &nbsp;<input id="txtmax" type="text" value="3.14"/>
      <br />
      Precision (number of points): &nbsp;<input id="precision" type="text" value="1000"/>
      <br />
      Point size: &nbsp; <input id="pointSize" type="text" value="2"/>
      <br />
      <input id="Button1" type="button" value="Draw Graph"
          onclick="javascript:drawChart(
              document.getElementById('txteq').value,
              parseFloat(document.getElementById('txtmin').value, 10),
              parseFloat(document.getElementById('txtmax').value, 10),
              parseInt(document.getElementById('precision').value, 10),
              parseInt(document.getElementById('pointSize').value, 10))" />

    <div id="chart_div"></div>
  </body>
</html>

We thank Steve for the inspiration and would love to see more creative uses of the platform from you.

The Visualization Team

By Venu Vemula, Google Book Search Team

Since I joined Google, I've been working on Book Search, our project to help users discover what's inside all the world's books.

Today we are happy to include the developer community in this historic effort with the announcement of two new APIs:

• An Embedded Viewer API, which allows you to embed book previews on your site and control them programmatically using JavaScript.
• A robust Data API, which allows you to access full-text search results and access with users' book reviews, ratings, and individual My Library collections.
  

By allowing anyone to integrate with the complete Google Book Search index, we hope this broader community will find new ways to connect users with books that are interesting and relevant to them.

To learn more about the sites already using these APIs — including Books-A-Million, Worldcat, and GoodReads — check out our post on the Book Search Blog.

Or, if you want to dig right in, go straight to our newly revamped developer site.

By Alyssa England, Google Developer Programs

We are excited to open registration for one last Google Developer Day this year, to be held on November 2 in Tel Aviv, Israel.

At this Google Developer Day, developers will learn about the latest with our APIs and developer tools, ranging from App Engine and OpenSocial to Google Chrome, plus more. The topics will vary so you can be sure to discover new and interesting best practices. And don't forget to socialize with fellow developers and Google engineers.

If you are in Europe, registration for some of the October Google Developer Days is still open, including Italy and Czech Republic, though space is running out fast. We hope you can join us for one of our upcoming events.

By Eric Sachs, Product Manager, Google Security

Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.

On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.



We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.

By Yaniv Shuba and Nir Bar-Lev, Google Visualization Team

Visualizations are usually nifty, small pieces of code that make our data come alive. In order to live in peace on the web, they need to be streamlined and compact.

At times, these visualization applications are a product of a creative designer who publishes their work for free for all of us to use. Often these designers do not have the time and resources to deal with data input structures.

Therefore, when integrating with a specific visualization, we often need to format the DataTable just right, so it fits the way the visualization expects to get the data. Say as an example, a first column needs to be of type date, the second a number and the third a text comment. What if our DataTable is not in that exact format? What if we want to create several visualizations over the same data source? To date this required manipulating the DataTable to fit the particular visualization and made the API a bit less flexible.

To make fitting data to the visualization even easier and simpler, and the Visualization API even more flexible, we've borrowed from the well-known SQL concept of Views and created our own DataView. Today, with Google Visualization's DataView you can reorder columns and "hide" a column such that the view includes only the columns you need to visualize. And, the DataView stays fully synchronized with the DataTable at all times, so any change to the underlying DataTable is reflected in the DataView.

Let's see a simple example that demonstrates this.

The following code creates three charts from a DataTable. The data displayed is yearly results for the imaginary Acme Rail company. We display a table, a bar chart and a BarsOfStuff chart. The BarsOfStuff chart is used because we are showing data for Acme Rail, and we thought it'd be cool to use the little trains in the chart:

<html>
  <head>
    <script type="text/javascript" src="http://www.google.com/jsapi"></script>
    <link rel="stylesheet" type="text/css" href="http://visapi- gadgets.googlecode.com/svn/trunk/barsofstuff/bos.css"/>
    <script type="text/javascript" src="http://visapi- gadgets.googlecode.com/svn/trunk/barsofstuff/bos.js"></script>
    <script type="text/javascript">

      google.load("visualization", "1", {packages:["barchart","table"]});

      google.setOnLoadCallback(drawData);

      // Initialize the DataTable
      function drawData() {
        var data = new google.visualization.DataTable();
        data.addColumn('string', 'Line');
        data.addColumn('number', 'Revenue');
        data.addColumn('number', 'Expenses');
        data.addColumn('number', 'Commuters');
        data.addRows(4);
        data.setValue(0, 0, 'NorthEast');
        data.setValue(0, 1, 38350);
        data.setValue(0, 2, 15724);
        data.setValue(0, 3, 1534);
        data.setValue(1, 0, 'Cross-Pacific');
        data.setValue(1, 1, 25740);
        data.setValue(1, 2, 12613);
        data.setValue(1, 3, 1170);
        data.setValue(2, 0, 'Midwest');
        data.setValue(2, 1, 11550);
        data.setValue(2, 2, 4389);
        data.setValue(2, 3, 660);
        data.setValue(3, 0, 'Pan-America');
        data.setValue(3, 1, 21720);
        data.setValue(3, 2, 9774);
        data.setValue(3, 3, 362);

        //Draw the charts
        var table = new google.visualization.Table(document.getElementById('table_div'));
        table.draw(data, {showRowNumber: true});

        var chart = new google.visualization.BarChart(document.getElementById('chart_div'));
        chart.draw(data, {width: 400, height: 240, is3D: false, title: 'Acme Rail Yearly Performance'});

        var stuffoptions = {title: 'Acme Rail Commuters by Line'};
        var stuffchart = new BarsOfStuff(document.getElementById('stuff_div'))
        stuffchart.draw(data, stuffoptions);

      }
    </script>
  </head>

  <body>
    <div id="table_div"></div>
    <div id="chart_div"></div>
    <div id="stuff_div" style="width: 400px"></div>
  </body>
</html>

The result looks like this:



The problem is that BarsOfStuff is a cool chart, but it is very simple. It can only accept a single data series in the format: [Series Title; Series Value].

Notice that right now the chart compares revenue per rail line, but we wanted it to display the number of commuters per line (as the title suggests).

How can we fix this? With DataView it is a simple matter of adding two lines of code and pointing the BarsOfStuff chart to the DataView instead of the DataTable. We add:

        var view = new google.visualization.DataView(data);
        view.setColumns([0,3]);

And initialize the BarsOfStuff chart with the DataView:

        stuffchart.draw(view, stuffoptions);

And we get:



Voila! The BarsOfStuff chart now shows the data we wanted it to visualize - commuters per rail line.

Yet another new feature to make developing complex dashboards with Google Visualization even easier is the clone() method, used to clone a DataTable instead of constructing a new copy from scratch.

We're working on making the DataView even more powerful, and of-course, working on other features and additions to the Visualization platform.

For more information on Google Visualization, check out our developer documentation pages.

Happy visualizing!