Monday 30 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

What do Arcade Fire and HTML5 have in common?

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.


Friday 27 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

An update on JavaOne

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.

Thursday 26 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

Google Buzz API adds Track and some improvements

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.

Demystifying the app ranking criteria in orkut

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

where
Base Score = Score (total installs) + Score (weekly installs, adjusted for weekly uninstalls) + Score (weekly renders in canvas and profile views)

and
Popularity 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!

Thursday 19 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

A developer preview for the Chrome Web Store

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.

Wednesday 18 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

CSS3 Transitions and Transforms in Gmail for the iPad

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.

Launched: New Google Analytics Management API!

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

Friday 13 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

HTML5: Still Rocking!

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.

Thursday 12 August 2010
Facebook StumbleUpon Twitter Google+ Pin It

New Google Buzz API features, including a garden hose

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!



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