Julian's Blogtech

Some websites use the OpenID standard so that users don’t even need to type a password to sign in. While Google does not yet support the usage of OpenID for replacing passwords on its own sites, we are involved in the OpenID community’s efforts to research how to best implement that type of support.

As a next step in those community efforts, we announced today the use of OpenID for the Google signup process.

Currently, Google only offers this feature for Yahoo! users. However, as it is based on an Internet standard, we plan to use it in the future with other email providers that add support for this usage of OpenID and related standards like OAuth, such as in the Microsoft Live identity APIs.

Other websites that need to verify a user’s email address can also implement this technique using Yahoo!’s OpenID API. In addition, it can be used to verify the addresses of Gmail and Google Apps users because those email systems expose the necessary APIs for OpenID. For example, Plaxo is one of the many websites that takes advantage of this feature of Gmail and Yahoo! Mail.

By Tzvika Barenholz, Internet Identity Team

var sidebarElement = new google.elements.sidewiki.SidebarElement(window.location.href,true);sidebarElement.bindToElement("sidewiki-open-ui-button");

We are very pleased to announce a new Sidewiki “sidebar” web element. Google Sidewiki allows visitors to your website to contribute helpful information and read other visitors’ insights alongside the pages of the website. The new web element is a Sidewiki button, which, when clicked, displays a fully functional Sidewiki sidebar to the left of the page content. This means that your visitors can see the Sidewiki content for your page even if they don’t have Google Toolbar or the Sidewiki Chrome extension installed.

You can choose from several different look and feels created by Google or even create a new custom one. Use our wizard to choose the desired look and behavior, embed the generated code in your page, and you’re done. Here's a sketch of what it looks like when a visitor is looking at the Sidewiki content.

Go to http://www.google.com/webelements/sidewiki/ to get started. If you'll be using the element on your site, we’d love to hear about it via @googlesidewiki on Twitter.

By Roman Shuvaev, Sidewiki Team

(Cross-posted from Google Analytics Blog)

On the Google Analytics API Team, we’re fascinated with what people create using the Data Export API. You guys come up with some really amazing stuff! Lately, we’ve also been paying a lot of attention to how people use it. We looked at whether the API has stumbling points (and where they are), what common features every developer wants in their GA applications, and what tricky areas need deeper explanations than we can give by replying to posts in our discussion group.

As a result of identifying these areas, we’ve written a few in-depth articles. Each article is meant as a “Deep Dive” into a specific topic, and is paired with open-source, sample reference code.

In no particular order, the articles are as follows:

Visualizing Google Analytics Data with Google Chart Tools
This article describes how you can use JavaScript to pull data from the Export API to dynamically create and embed chart images in a web page. To do this, it shows you how to use the Data Export API and Google Chart Tools to create visualizations of your Google Analytics Data.

Outputting Data from the Data Export API to CSV Format
If you use Google Analytics, chances are that your data eventually makes its way into a spreadsheet. This article shows you how to automate all the manual work by printing data from the Data Export API in CSV, the most ubiquitous file format for table data.

Filling in Missing Values In Date Requests
If you want to request data displayed over a time series, you will find that there might be missing dates in your series requests. When requesting multiple dimensions, the Data Export API only returns entries for dates that have collected data. This can lead to missing dates in a time series, but this article describes how to fill in these missing dates.

We think this article format makes for a perfect jumping off point. Download the code, follow along in the article, and when you’re done absorbing the material, treat the code as a starting point and hack away to see what you can come up with!

And if you’ve got some more ideas for areas you’d like us to expound upon, let us know!

By Alexander Lucas, Google Analytics API Team

We are now ready to share the Google Developer Day agendas for Tokyo, Sao Paulo, Munich, Moscow and Prague. We have so much technical content to share but alas, Developer Day is a one-day event. There may still be changes to the agenda, but here is a sneak peek at where we are.

Globally, we will feature three major tracks:

• Android - With the continued momentum and growth of the platform, we would like to continue the conversation with you at Developer Day. We will feature sessions on Android performance, mobile user experience and best practices on building apps, and we will also deep dive on a new feature, Cloud to Device Messaging (C2DM).


• Chrome & HTML5 - We will discuss how to build an app for the Chrome Web Store and how to improve its development and performance. We’ll show which aspects of HTML5, Chrome Developer Tools and Native Client can be most useful to you. Finally, we will cover everything auth-related to show you when and where to use various authentication tools and how they integrate with our APIs and products.


• Cloud Platform - Building off of our series of announcements at Google I/O, we will feature sessions on App Engine, App Engine for Business, Spring integration, Google Web Toolkit, Google Storage for Developers, BigQuery and Prediction API. Be prepared for code samples, how to optimize performance and a glimpse into what else is on our roadmap.

We are happy to announce that Eric Tholome, Product Management Director for Developer Products, will be a keynote speaker in Sao Paulo, Munich, Moscow and Prague. In addition, we are happy to invite as our second keynote speaker:

• Sao Paulo, Brazil - Mario Queiroz, VP Product Management


• Munich, Germany - Dr. Wieland Holfelder, Engineering Director


• Moscow, Russia - Dr. Gene Sokolov, Head of Moscow Engineering

Due to the success of the Venture Capital sessions at Google I/O and the growing VC activity in our global markets, a new addition this year is Venture Capital panels at most of our Developer Days. Come hear from your local VCs on what they look for in startups.

The Sao Paulo and Moscow keynote presentations will have live translation, and for sessions, check the FAQ section of your Developer Day site. We will have savvy gurus available to answer your questions during Office Hours, and you will have a chance to meet Googlers and each other over Happy Hour.

Registration will open on September 15th for Sao Paulo and on September 22nd for Munich, Moscow and Prague. Tokyo’s registration is now closed.
In the meanwhile, please follow us on this blog and on Twitter to keep up-to-date with the latest news on Google Developer Day and other development topics: @googledevjp (Japan), @googledevbr (Brazil) and @gddru (Russia).
Hashtags: #gdd2010jp, #gddbr, #gddde, #gddru, #gddcz

By Susan Taing, Google Developer Team

This is a guest post by Owen Barton, partner and director of engineering at CivicActions. Owen has been working with Google's “Make the Web Faster” project team and the Drupal community to make improvements in Drupal 7 front-end performance. This is a condensed version of a more in-depth post over at the CivicActions blog.

Drupal is a popular free and open source publishing platform, powering high profile sites such as The White House, The New York Observer and Amnesty International. The Drupal community has long understood the importance of good front-end performance to successful web sites, being ahead of the game in many ways. This post highlights some of the improvements developed for the upcoming Drupal 7 release, several of which can save an additional second or more of page load times.

Drupal 7 has made its caching system more easily pluggable - to allow for easier memcache integration, for example. It has also enabled caching HTTP headers to be set so that logged out users can cache entire pages locally as well as improve compatibility with reverse proxies and content distribution networks (CDNs). There is also a patch waiting which reduces both the response size and the time taken to generate 404 responses for inlined page assets. Depending on the type of 404 (CSS have a larger effect than images, for example) the slower 404s were adding 0.5 to 1 second to the calling page load times.

Drupal currently has the ability to aggregate multiple CSS and JavaScript files by concatenating them into a smaller number of files to reduce the number of HTTP requests. There is a patch in the queue for Drupal 7 that could allow aggregation to be enabled by default, which is great because the large number of individual files can add anything from 0-1.5 seconds to page loads.

One issue that has become apparent with the Drupal 6 aggregation system is that users can end up downloading aggregate files that include a large amount of duplicate code. On one page the aggregate may contain files a, b and c, whilst on a second page the aggregate may contain files a, b and d - the “c” and “d” files being added conditionally on specific pages. This breaks the benefits of browser caching and slows down subsequent page loads. Benchmarking on core alone shows that avoiding duplicate aggregates can save over a second across 5 page loads. A patch has already been committed that means files need to be explicitly added to the aggregate, and fix Drupal core to add appropriate files to the aggregate unconditionally.

Drupal has supported gzip compression of HTML output for a long time, however for CSS and JavaScript, the files are delivered directly by the webserver, so Drupal has less control. There are webserver based compressors such as Apache’s mod_deflate, but these are not always available. A patch is in the queue that stores compressed versions of aggregated files on write and uses rewrite and header directives in .htaccess that allow these files to be served correctly. Benchmarks show that this patch can make initial page views 20-60% faster, saving anything from 0.3 to 3 seconds total.

The Drupal 7 release promises some real improvements from a front-end performance point of view. Other performance optimizations will no doubt continue to appear and be refined in contributed modules and themes, as well as in site building best practices and documentation. In Drupal 8 we will hopefully see further improvements in the CSS/JS file aggregation system, increased high-level caching effectiveness and hopefully more tools to help site builders reduce file sizes. If you have yet to try Drupal, download it now and give it a try and tell us in the comments if your site performance improves!

By Owen Barton of CivicActions

Just a heads up that it should now be easier for users to find SVG files when searching on Google. That’s right, we’ve expanded our indexing capabilities to include SVG. Feel free to check out our Webmaster Help Center for the complete list of file types we support, and our Webmaster Blog for more information on our SVG announcement.

By Maile Ohye, Google Developer Relations

This week, a lot.

Today we’re excited to announce the band Arcade Fire’s new project “The Wilderness Downtown,” an interactive HTML5 music experience that is being showcased on Google’s Chrome Experiments site. The project was created by writer/director Chris Milk with Arcade Fire and Google.

We put everything except the proverbial kitchen sink into this project: It features HTML5 audio, video, and canvas, animated windows with JavaScript controllers, mash-ups with Google Maps and Street View APIs, and an interactive drawing tool. You can take a look at how all this works by viewing the source code.

Check out the project or learn more about the techniques used to make it happen at www.chromeexperiments.com/arcadefire.

We hope you enjoy it.

By George Michael Brower, Google Creative Lab

Like many of you, every year we look forward to the workshops, conferences and events related to open source software. In our view, these are among the best ways we can engage the community, by sharing our experiences and learning from yours. So we’re sad to announce that we won't be able to present at JavaOne this year. We wish that we could, but Oracle’s recent lawsuit against Google and open source has made it impossible for us to freely share our thoughts about the future of Java and open source generally. This is a painful realization for us, as we've participated in every JavaOne since 2004, and I personally have spoken at all but the first in 1996.

We understand that this may disappoint and inconvenience many of you, but we look forward to presenting at other venues soon. We’re proud to participate in the open source Java community, and look forward to finding additional ways to engage and contribute.

By Joshua Bloch, Google Open Source Programs Office

Let's say you're really interested in coffee and tea and would like to know every time someone talks about them. You've been able to do that for the web with Google Alerts. Now you will be able to do the same thing for Google Buzz with our latest feature: Track. Plus, you can restrict your search to a specific geographic area! This API will allow you to enter a search query and from then on receive any new public Google Buzz posts—in real time—that match that query. It uses PubSubHubbub, which is the same open standard used by our fire and garden hoses.
To start receiving updates, you only need to send a query to the track endpoint, subscribe to the returned link, and then start receiving updates. If you'd like to take it for a quick spin, simply subscribe to a track endpoint via Google Reader (which happens to support PubSubHubbub). For example, if you’d like to receive all the new public Google Buzz posts about coffee or tea, simply open Google Reader, click "Add a subscription," and paste in the following URL:
https://www.googleapis.com/buzz/v1/activities/track?q=coffee+OR+tea
Two of our firehose partners, Gnip and SuperFeedr are already using this feature. Gnip was able to add the feature into their API aggregation service with only a couple hours of work; their service update should be live early next week.
We’re excited to see what you develop with this cool new feature. Please note that it’s experimental and we may make changes in response to its use.
Additionally, we’ve been looking for ways to make the development experience with the Google Buzz API easier. One of the things we think we can improve upon are error messages. So, over the next couple weeks we’ll be rolling out significantly improved error messaging.
For example, if you tried to read an activity without including the activity id before today, you’d receive an HTTP error code and nothing else. Starting today, you’d also get a detailed error message returned in the body of the response:

<errors xmlns="http://schemas.google.com/g/2005">
<error>
<domain>GData</domain>
<code>required</code>
<location type="parameter">postId</location>
<internalReason>Post ID is required.</internalReason>
</error>
</errors>

The count API we announced back in mid-July has been returning the the number of times a specified link was shared on Google Buzz. We have started including short links (e.g. tinyurl.com/runningwithfins) in the count as well. Now you can specify the long link or any corresponding short link to get the total available count. This will give developers a much more complete count of links to a certain URL, however indirect.
Please visit the Google Buzz API documentation site for more details on these updates and swing by the Developer Forum if you have any questions.
By Ivaylo Popov, Google Buzz Team

Over the months, we’ve had many requests to explain the way we rank applications in the orkut directory. Developers often wonder why one of their very popular apps doesn’t appear as high up in the directory as they believe it should. Well, it’s not exactly magic but simple math, and we wanted to share with you how our algorithm works out the rankings.
As you’d expect, we rely heavily on stats that tell us not only the number of users who have installed your app but also the number of users who actively use it. The number of installations is further broken down into the number of weekly as well as total installs. We hope you’ll agree that counting the number of users who uninstall your app is also crucial, since that is an indication of which apps didn’t live up to user expectations in some way and could be improved, and we lower the ranking score by a few points to account for the weekly uninstalls.
However, it’s not enough to judge the popularity of an application by the number of its installations alone – how often it actually gets rendered is a definite index of how addictive, useful and well-designed it is, and you can surely expect us to feed those numbers back into the formula, too!
Besides these, we think apps that users find good enough to put up on their home page should be given some weight, thus the number of weekly renders of those apps in profile view figures into our calculations too. We then add one last parameter to this equation: a popularity index that is a function of the weekly renders of each app over the number of it’s total installations.
In short, the formula looks something like this:
Total Score = Base Score + Popularity Score
whereBase Score = Score (total installs) + Score (weekly installs, adjusted for weekly uninstalls) + Score (weekly renders in canvas and profile views)
andPopularity Score = Score(weekly renders / total installs)
We hope this gives you a clue to the “mystery”. We look forward to hearing your comments and feedback on the forum!
By Prashant Tiwari and Tiago Silveira, orkut Team

Today, we released a developer preview of the Chrome Web Store. Besides brand new documentation, we now allow developers to upload their apps using the developer registration flow of the Google Chrome Extensions Gallery.



The Chrome Web Store will be launching later this year. In the meantime, we’ll continue to share news on apps and the store through blog posts on the Chromium and Google Code blogs. We also encourage you to join our discussion group for apps for updates on our efforts.

By Rahul Roy-chowdhury, Google Chrome Team

The Mobile Gmail team recently announced a new stacked cards interface for the iPad. In this interface we make use of CSS3 transitions and transforms to provide a more intuitive interface that has a look and feel that is similar to native applications. In this post we will describe CSS3 transitions and transforms and how they were used to develop this interface. All of the CSS and JavaScript examples currently work only in WebKit-based browsers, such as Safari on the iPad. However, Mozilla-based browsers have their own versions of WebKit-based extensions that use the ‘-moz’ prefix, and that should behave similarly.

CSS3 Transitions

CSS3 transitions allow the browser to animate the change of a CSS property from an initial value to a final value. A transition is configured by setting four CSS properties on an HTML element:

• -webkit-transition-property
• -webkit-transition-duration
• -webkit-transition-timing-function
• -webkit-transition-delay

The -webkit-transition-property property identifies the CSS properties where changes to the property will trigger a transition between the old value of the property and the new value. The -webkit-transition-duration property specifies, in milliseconds, the length of time over which the transition should take place. The -webkit-transition-timing-function property describes the speed at which the transition progresses over the duration of the transition. For example, -webkit-transition-timing-function: ease-in-out describes a transition that will proceed slowly at the beginning and the end of the transition, but that will proceed quickly during the middle of the transition. You can also provide a custom, cubic-bezier function for a higher degree of control over the timing. The -webkit-transition-delay property specifies a delay, measured in milliseconds, before the transition begins.

The transition properties can also be set simultaneously using the -webkit-transition property, by simply specifying them in the above order. Once the transitions properties are set and up to the point where the value of -webkit-transition-property is changed, all modifications of the specified CSS properties will trigger transitions.

CSS3 Transforms

CSS3 transforms allow the rendering of an HTML element to be modified using 2D and 3D transformations such as rotation, scaling, and translations. Transforms are applied by setting the -webkit-transform CSS property with the desired list of transforms. Each transform takes the form of a transformation function, such as translate3d or rotate, and a list of parameters enclosed in brackets. For example, to move an object to the right by 100 pixels and rotate it by 45 degrees you can use the -webkit-transform property:

-webkit-transform: translate(100px, 0) rotate(45deg);

Using -webkit-transform as the transition property when moving an element is advantageous relative to using the standard top and left properties because transitions using -webkit-transform are hardware-accelerated in Safari. An exception here is that it seems that 2D translations are not hardware-accelerated. But, since any 2D translation is equivalent to a corresponding 3D translation with the same translations in the x and y and no translation in the z axis, it is easy to use a hardware accelerated translate3d(x, y, 0) transform instead of a non-hardware accelerated translate(x, y) transform.

Terminology

There are a few terms here that begin with ‘trans,’ and they can easily be confused if you are not familiar with them. Here they are again:

• Transition: An implicit animation of CSS properties between an initial and a final value.
• Transform: A modification to the appearance of an HTML element by manipulating it in a 2D or 3D space.
• Translation: A particular type of transformation that moves the HTML element in 2D or 3D space.

Stacked Cards Interface

In the stacked cards interface, cards representing selected conversations transition onto the screen when their corresponding conversation is selected, and transition off of the screen when it is deselected.

When cards are selected, they are transitioned out from underneath the conversation list on the left side of the application into the selected conversation area on the right side of the application. To move the card onto the screen, we set an initial transform, configure the transition, and finally apply the desired final transform to the element.

To simplify the layout, the un-transformed position of each card is its normal position in the selected conversation area. This allows the card to have no translation applied when in this position, although it will need a translation to animate the movement. Initially the card has a transform that translates it to the left. The z-index property is used to ensure that the card will render underneath the conversation list. The rotation of the card is also initially applied, since we chose not to have the card rotate as it transitions onto the screen.

card.style.WebkitTransform =
‘translate3d(-700px, 0, 0) rotate(5deg)’;

Since the particular translation and rotation can vary, we chose to apply this property using JavaScript rather than including it in the CSS class applied to the card. It is important that the CSS3 transition is not yet applied because we do not want this transform to be a transition. Moreover, it is important that the card is rendered at its initial transform before the transition is configured and the destination transform is applied. This is easily achieved by wrapping these next steps in a call to window.setTimeout with a timeout of 0 ms.

window.setTimeout(function() {
card.style.WebkitTransition =
‘-webkit-transform 300ms ease-in-out’;
card.style.WebkitTransform =
‘translate3d(0, 0, 0) rotate(5deg)’;
}, 0);
Completion of the Transition

It is useful to know when the transition is complete. In the stacked cards interface, we use this to improve performance by setting display:none on obscured cards so that they do not need to be rendered. Adding an event listener allows the application to be notified when the transition has completed.

element.addEventListener(‘webkitTransitionEnd’, listener, false);

Interrupting a Transition

In some cases, you may want to change a transition while it is in progress. For example, if the user unselected a conversation while the corresponding card was still animating onto the screen, we might apply a new transition to send the card back off of the screen again. When you apply a new CSS value while a transition is already in progress, a new transition will occur between the current value of the property in the transition and the new value that you apply. For example, suppose a card is halfway through it’s transition onto the screen, and we apply this CSS transform:

card.style.WebkitTransform =
‘translate3d(-700px, 0, 0) rotate(5deg)’;
Since the transition properties are still configured, a new transition will occur. The initial value for the transition will be the halfway point - approximately translated3d(-350px, 0, 0) rotate(5deg). The final value will be translate3d(-700px, 0, 0) rotate(5deg). The full duration of the transition will still apply, so the card will move about half as quickly as it usually does. It is possible to determine the current transform applied to an HTML element using the WebKitCSSMatrix and to use this to recalculate more appropriate transition parameters, but this is outside the scope of this post.

Conclusion
I hope that this introduction to CSS3 transitions and transforms has been useful, and that the insight into the implementation of Mobile Gmail on the iPad has been interesting. Based on positive feedback, the Mobile Gmail team is looking forward to making more use of transitions and transforms in the future.

By Liam Asher Segel-Brown, Software Engineering Intern, Google Mobile

Many developers have asked for a faster, more powerful way to access Google Analytics account configuration data through the Data Export API. We’ve listened and today we’re releasing a preview of the new Google Analytics Management API.

The Management API provides read-only access to Google Analytics configuration data. It consists of 5 new Google Data Feeds that map directly to the Google Analytics data model.

Previously, the API returned all the configuration data at once, which in many cases was inefficient if you only needed a subset of data. Now with separate feeds, developers can request only the data they need. For example, it’s now easy to get the Profile IDs for a single account or the Goal configuration data for only a single Profile.

To help you learn more we created a new Management API section in our developer documentation. We also created new reference examples in Java and have a live working demo in JavaScript. Check it out, no coding needed!

The Management API is being launched in Labs as an early preview. The API will change, grow, and get better over time. We recommend developers who aren’t committed to making updates to their applications only experiment with the new API and continue to use the Account Feed as their primary source for configuration data. We will strive to give you at least one month advanced notice of changes to this API.

The Management API represents a significant new piece of the Google Analytics developer platform. We encourage you to come try it out and give us feedback in our new Management API Google Group.

P.S. - Please make sure to sign-up for our notify list to stay up-to-date on all the latest Google Analytics Developer updates.

Thanks!
By Jeetendra M. Soneja, Google Analytics API Team

As announced on the chromium.org blog, we’ve just pushed a bunch of new content to our HTML5Rocks.com developer site, which launched earlier this summer.

Anyone that’s following HTML5 knows how fast things are moving! To keep you informed with all of the amazing features landing in today’s browsers, we’ve added five new articles, a heap of new resources, and a much needed RSS feed for staying tuned in. We're also revealing a new component of the site, the HTML5 Studio. It’s a collection of standalone demos that highlight hot, new HTML5 features working together.

If you'd like to contribute code, guides, or samples, we’re working on a third-party contributors guide. Please stay tuned! In the meantime, you can get in touch with us on the bug tracker or via @ChromiumDev.

By Eric Bidelman, Google Chrome Developer Relations

It’s been less than a month since our last launch, but we couldn’t sit still so today we’re announcing three new features. We think these will help developers create deeper, more engaging user experiences.

First, we wanted to make the firehose experience available to those who didn’t have the required server resources to support that amount of traffic. So we built a “garden hose” that’s a random sampling of public Google Buzz posts with a query rate that’ll come under the free quota limit for Google App Engine. As such, many more developers will be able to easily get their hands dirty on this great source of real-time data.

Second, we’ve created an API to return the people associated with a particular activity query. That is, you can now search for people who have recently created a public post that includes an arbitrary string or related geo-location. For example, if you wanted to see the people associated with Red Sox near Fenway Park, you could use this URL for the JSON response.

Third, we now enable users to discover and explore content related to a particular post. With this new API, developers can now access and deliver Google search results related to the topic of that post. For example, given this post about Coworking Day, you could add ‘/@related’ to the end of the self link to get this JSON response of related links. Cool, huh?

As always, these features are documented in more detail on the Google Buzz API documentation site. Please swing by the the Developer Forum and let us know what you think!

By Eric Steinlauf, Google Buzz Team

Photo credit: Nandhp, used under the Creative Commons Attribution-Share Alike 3.0 Unported license.

We’re very proud to tell you that we’ve just launched a new feature for the Google font directory. The new Google font previewer lets you test drive all the fonts in the directory so you can decide which web font in the Google Font API works best for your requirements.

Now, whenever you visit the font family page of any of the fonts, you will see a link saying “Preview this font” that will load your font selection into the font previewer.

Here you can edit the text, change its size and line height, and add decorations and spacing among other things. You can even apply text shadow to your text.

The previewer will generate the corresponding code for you so all you have to do to start using the font on your own website is to copy and paste the stylesheet link and the CSS into your pages. In the example above this would be:

<link href="http://fonts.googleapis.com/css?family=Lobster:regular"
rel="stylesheet" type="text/css" >
<style> body {
font-family: 'Lobster', serif;
font-size: 28px;
font-weight: 400;
text-shadow: 4px 4px 4px #bbb;
text-decoration: underline;
text-transform: lowercase; line-height: 1.42em; }
</style>

That’s really all you need to use the Google Font API.

If you want to see the font sample without any distractions from the font previewer controls, you can do that as well simply by clicking “Toggle controls” in the upper right corner. This will show you a nice clean example of what the font would look like in your design.

We think the previewer is a great way to try out web fonts and showcase what can be done with them. We’re looking forward to hearing what you think about the new font previewer.

By Marc Tobias Kunisch, Google Font API team

Since we launched the new orkut, we’ve been working hard to launch new features and introduce the new design to other pages that are still using the older UI. Today, we’re excited to announce the redesign of the app pages on orkut. Because we want developers to try it out first, these changes are first being rolled out to the sandbox, and you’ll have some time to give us your feedback before these go live for all users at orkut.com. We believe usability and speed improved considerably.

Let’s check out what’s new:

New canvas page
Options are more descriptive and appear at the top of the page. They open up as dialogs so users can configure or access the app information without leaving the canvas page.


New apps directory page
The apps directory is easier to navigate. We removed the descriptions and arranged the apps in two columns, and you can search for apps within categories, so it all looks much cleaner. We also created a section called "my applications" from where users can open or remove their apps.

When a user clicks on an app listed in the directory, the screenshot as well as the app’s description and popularity will now pop up in a new window. This window replaces the old app page and allows users to quickly add apps without loading another page.


New profile view for apps
We’re changing the way apps are displayed on a user’s profile. Showing several apps in tabs on the profile page was confusing. We made things simpler having users select a single app to appear on their profile page and other apps (as well as the "about me" section) are accessible by a drop-down menu.

A new apps box
We’re adding a “my applications” box, just below the “my communities” one on the right. This box will list the thumbnails of all apps the user has installed. We hope this will drive more traffic to the app’s canvas page.

We hope you’ll like these changes. Please share your feedback with us at the forum.

By Adler Silva, orkut Team

Since we introduced the Google Buzz API at Google I/O, we’ve been working hard to make it better, broader, and more useful. Today we're introducing several new features that are the direct result of your feedback.

We're launching the Google Buzz firehose — our top developer feature request. With the firehose, all public activities are available as they are published with a single subscription, thanks to syndication via PubSubHubbub.

We’ve had some fun coming up with cool things to do with the firehose. For example, Bob Aman coded up Buzz Mood, an App Engine app inspired by Twistori. By scanning for posts that contain certain keywords, Bob’s able to give us a sense for the mood across all of Google Buzz in real time. Definitely take a look at the the source to get ideas for your own apps!

For more inspiration, also check out our firehose launch partners. Integrating with the firehose today are Collecta, Gnip, OneRiot, Postrank Analytics, and Superfeedr’s Track.

We’re making these new API features available starting today:

• Comments by the user - This feed consists of the activities the user has commented on.
• Likes by the user - The activities the user has liked are in this feed.
• Shared counts - This will return the number of times a specified URL has been shared across Google Buzz.

All of these features are documented in much more detail on the Google Buzz API documentation site and can be discussed on the Developer Forum. We will continue to innovate and iterate the Buzz API and encourage you to check out the new features and let us know what you think.

By John Panzer, Google Buzz Team

Gmail, Calendar, Docs, Sites and all Google Apps were designed as cloud-based services from day one.  Google’s web-centric approach allows any application to work seamlessly on any device with a browser, allowing users to work when, where, and how they want. No more need for constant upgrades, security patches and bug fixes required by client based software.

Given the first step to the cloud for many businesses and schools is Gmail, the Google Apps Marketplace aims to make it easier for organizations that have “gone Google” to take the next step and take fuller advantage of the cloud by running even more of their infrastructure on cloud-based apps, from hundreds of software companies.

These software companies agree the web-centric approach is the way to go, and are building their applications on web-based architectures and open standards like OpenID for Single Sign-On and OAuth for data access.  Marketplace developers build their applications using the technologies and hosting platform they prefer.  Want to build using Java?  Great.  Ruby or PHP?  Fine with us.  .NET?  Sure, the Marketplace supports that too.  These apps are then hosted on developers’ own servers, on Amazon EC2, on Google’s App Engine, or on any other cloud hosting service.  As developers, they don’t need to worry about proprietary tools, vendor lock-in, or proprietary cloud architecture lock-in, and as Google Apps customers, you’ll even find apps that compete with Google products such as SlideRocket presentations and Zoho CRM, giving you the maximum possible choice.

The key advantage of Marketplace apps, however, is their integration with Google Apps.  All installable Marketplace apps feature single sign-on with Google Apps, and most go beyond that to incorporate specific features that help you accomplish everyday tasks more easily in combination with Google’s applications.  Here is a tiny sampling of Marketplace apps that integrate with various Google Apps:

Gmail -- Manymoon is an online project management tool that make it easy to turn emails from team mates or customers directly into tasks in your projects.  Kwaga Context and Awayfind are two productivity apps that help you manage your conversations directly in your Gmail inbox, helping keep you more productive.

Spreadsheets -- Sliderocket let’s you connect media-rich presentations to live data in Google Spreadsheets, so your presentation always display the most up to date charts and graphs, and    Smartsheet let’s you extend Google Spreadsheets with Gantt tracking and customer management features to empower your sales teams.

Calendar -- Tungle.me and Timebridge are meeting management tools that make it easier to set up and conduct meetings with partners and customers who use different calendaring systems.

Sites -- RunMyProcess let’s you embed custom business process workflows into Google Sites, so each part of an organization can more easily access business process that effect their daily work.

Talk -- Atlassian integrates Jira Studio with Google Talk, so your software development team can stay up to date with the latest build status and team conversations from within Jira Studio, all in real time.

There are hundreds more business applications available on the Marketplace for every aspect of your business.  Find CRM apps, Admin tools, Document Management apps, Productivity apps, and many more.

Every week more cloud-based business applications are added. If you can’t find an app you want please post a suggestion.

By Don Doge, Google Apps Team

Sharing the joy of building software with someone that doesn’t have an engineering background is hard. Today it got a little easier with App Inventor for Android.

App Inventor for Android is a Google Labs project that makes it possible to create complex Android applications without having to write any code. This is because, instead of writing code, you can visually design the way the app looks and use blocks to specify behavior.

This helps introduce concepts about logic and programming in a compelling way, without getting lost in syntax and code. And while App Inventor for Android doesn’t have every feature available in the latest Android SDK, it has been used to create some very compelling applications.

For more information about how to participate, take a look at the announcement on the Google Blog.

We look forward to seeing what you think and hearing about your stories. And, yes, the irony of writing a Google Code blog post about avoiding the need to code is not lost on me. :-)

App Inventor for Android is possible due to some significant work done in research on education computing both inside and outside Google. The brainchild of Hal Abelson (visiting faculty), App Inventor for Android is an effort to see if the nature of introductory computing can be changed.

By Ali Pasha, Google Developer Programs