Friday, June 25, 2010

[Gd] A fresh coat of chrome

| More

Chromium Blog: A fresh coat of chrome

As part of our continual work on Google Chrome’s user interface, we’ve been trying to streamline the toolbar, make the Omnibox more approachable, and communicate site security information more clearly. Users on our dev channel may have noticed some of these experiments already:

  • When you are typing into the Omnibox, an icon to the left will show how your input will be interpreted - such as a magnifying glass for search queries (), and a globe for URLs (). When you’re not typing, the same icon can be dragged to another document to copy the current page’s URL, or clicked to reveal information about the current site.

  • When on a secure (SSL) site, this icon changes to a lock () - previously we displayed the lock icon at the end of the Omnibox, but now it’s closer to the URL and in a more obvious place.

  • We’ve added a clearer presentation of Extended Validation (EV) certificate holder names (), which, like the lock, are now at the beginning of the Omnibox.

  • We’ve changed the colors and icons used with secure sites to make mixed content more obvious, and avoid confusion about ambiguous colors.

  • In some situations, we’ve stopped displaying “http://” and/or a slash after the hostname. This makes the hostname more prominent and the URL more readable, and provides more visual distinction between regular and SSL websites (which keep their “https://” prefix). We’ve also done a lot of work to make sure that copying and pasting of these URLs continue to work as you would expect.

  • The bookmark star icon () has joined the other “page actions” at the right-hand side of the Omnibox.

  • Stop and Reload have been combined, and Go eliminated, to make things simpler and keep all the navigation-related toolbar buttons together.

Here’s a screenshot of the old interface in the stable channel (5.0), followed by the current interface on the dev channel (6.0):

More experiments are on the way to all platforms, like simplifying our menu structure, and further reducing visual noise in the toolbar:

In all these cases, we may tweak or even revert experiments before settling on a final solution. We’ve found that living with a new design is more informative than merely discussing it, so thanks to all our dev channel users for your patience and feedback as we test out these changes.

Posted by Nicholas Jitkoff, User Experience Designer

[Gd] Wave Federation Keeps Growing: Rich text editor is open source

| More

Google Wave Developer Blog: Wave Federation Keeps Growing: Rich text editor is open source

As you may have heard before, the Google Wave Federation Protocol is an emerging open protocol for improving communication and collaboration across the web -- not just in a single product. To further propel the community, as part of Google I/O, we open sourced another significant chunk of Google Wave production code (now totaling more than 200,000 lines of code released), including: the in-browser rich text editor, the wave model, and the concurrency control mechanism.

This code release introduces a simple web client for FedOne, which enables you to bring up your own browser-based client running against the FedOne backend, which can then federate over to The web client communicates with the FedOne server using an emerging WebSocket-based client/server protocol, with the initial documentation in the whitepaper under review. There is even work going on to make an Emacs client for wave using this emerging client/server protocol. To get started with your own instance, please read a recent forum post: exploring the simple web client, and you may also be interested in reading the wave model code walk-through.

There is a growing community of wave providers building on wave technology and the Google Wave Federation Protocol, including SAP StreamWork (demo below, and you can read more about SAP StreamWork and the wave protocol), Novell Pulse (here's a demo), ProcessOne's OneWave,, and The US Navy also put out a call for proposals earlier in the year (Navy Wave RFP [PDF]). Additionally, there are several open source projects in development as well: PyGoWave, QWave, ARWave, and Ruby on Sails.

Here's a video showing SAP StreamWork federating with

This is all driven by the desire to let users work together no matter what system they may be using. For more information about building your own wave provider, feel free to check out the session video and slides from Google I/O 2010.

Please join us in the forum if you'd like to get involved.

Posted by J.D. Zamfirescu, and Anthony Baxter, Software Engineers, Google Wave


[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 6.0.447.0 for Mac and Windows.

  • PDFs are now shown centered.
  • [r50274] Ctrl-clicking links opens them to the right of the current tab again (Issue 46917)
MacKnown Issues
  • (Issue 47419) Attempting to create an application shortcut from the File menu crashes Chrome on Windows
More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Jason Kersey
Google Chrome

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

Google Chrome 5.0.375.86 has been released to the Stable channel on Linux, Mac, and Windows.

The integrated flash player has been enabled by default and the following security issues were resolved:
  • [38105] Medium XSS via application/json response (regression). Credit to Ben Davis for original discovery and Emanuele Gentili for regression discovery.
  • [43322] Medium Memory error in video handling. Credit to Mark Dowd under contract to Google Chrome Security Team.
  • [43967] High Subresource displayed in omnibox loading. Credit to Michal Zalewski of Google Security Team.
  • [45267] High Memory error in video handling. Credit to Google Chrome Security Team (Cris Neckar).
  • [$500] [46126] High Stale pointer in x509-user-cert response. Credit to Rodrigo Marcos of SECFORCE. 
If you find issues, please let us know:

Anthony Laforge,
Google Chrome Team

Thursday, June 24, 2010

[Gd] Extensions in Incognito

| More

Chromium Blog: Extensions in Incognito

When we first released extension support in Chromium, we left out all support for running extensions in incognito mode. This meant I had to live without handy extensions like Mouse Stroke and PasswordMaker (shameless plug) whenever I opened an incognito window, and that made me sad. When your muscle memory is trained to expect certain features, it's pretty jarring to find them missing. So in the latest stable version of Google Chrome, I added support for running extensions while in incognito.

One of the main reasons we delayed adding incognito support was that Chrome has no way to ensure that extensions obey the incognito rules: in short, that your browsing data is not saved after you close the incognito window. After much debate, we finally decided to let users decide which extensions they were comfortable using in incognito. You should only enable extensions that you trust and that don't save sensitive information. For example, an extension named Save All Your History would probably not be a good idea to run in incognito, since it would defeat the entire purpose of opening an incognito window. (This is not always the case: if the extension is written with incognito support in mind, it could avoid saving sensitive information, but it is up to the extension developer.)

To allow an extension to run while incognito, open the Extensions management page (accessible from the Tool menu -> Extensions). Each extension has an option to "Allow in incognito". Turning this on will let the extension display page and browser actions in incognito windows, and give them access to browser information originating from an incognito tab. It's just as easy to remove this access any time by following the same steps and unchecking the "Allow in incognito" option.

Note to extension developers: Try to be a good citizen by only persisting browsing information collected from non-incognito windows. You can determine this by examining the incognito property on tab and window objects, or checking chrome.extension.inIncognitoTab from within a content script. For more information, see the extension documentation section on Saving data and incognito mode.

Posted by Matt Perry, Software Engineer

[Gd] [Search][Release] Result size can be 1-8

| More

Google AJAX API Alerts: [Search][Release] Result size can be 1-8

Allow arbitrary Integer resultSetSize from 1 to 8, inclusive

[Gd] Exercising Our Remote Application Removal Feature

| More

Android Developers Blog: Exercising Our Remote Application Removal Feature

[This post is by Rich Cannings, Android Security Lead. — Tim Bray]

Every now and then, we remove applications from Android Market due to violations of our Android Market Developer Distribution Agreement or Content Policy. In cases where users may have installed a malicious application that poses a threat, we’ve also developed technologies and processes to remotely remove an installed application from devices. If an application is removed in this way, users will receive a notification on their phone.

Recently, we became aware of two free applications built by a security researcher for research purposes. These applications intentionally misrepresented their purpose in order to encourage user downloads, but they were not designed to be used maliciously, and did not have permission to access private data — or system resources beyond permission.INTERNET. As the applications were practically useless, most users uninstalled the applications shortly after downloading them.

After the researcher voluntarily removed these applications from Android Market, we decided, per the Android Market Terms of Service, to exercise our remote application removal feature on the remaining installed copies to complete the cleanup.

The remote application removal feature is one of many security controls Android possesses to help protect users from malicious applications. In case of an emergency, a dangerous application could be removed from active circulation in a rapid and scalable manner to prevent further exposure to users. While we hope to not have to use it, we know that we have the capability to take swift action on behalf of users’ safety when needed.

This remote removal functionality — along with Android’s unique Application Sandbox and Permissions model, Over-The-Air update system, centralized Market, developer registrations, user-submitted ratings, and application flagging — provides a powerful security advantage to help protect Android users in our open environment.


[Gd] Diacritization added to the Google Language API

| More

Google AJAX APIs Blog: Diacritization added to the Google Language API

Earlier this year, we launched the Tashkeel (Diacritization) service on Google Labs. I'm pleased to announce that we've added an experimental Diacritization component to the Google Language API. This is a simple JSON API which you can use to add diacritic symbols to strings of Arabic text.

To test it out, try clicking this link:مرحبا%20العالم&last_letter=false&callback=result

A URL-encoded string is supplied as the message parameter, and it's returned by the API with diacritics included. These symbols are useful to people just learning the language and as an important pre-step for several text processing applications.

Right now, the API only supports Arabic, but we're working on adding more languages, as well as a JavaScript API, so be sure to watch this blog for details. For more information, see the documentation and our post on the Google Arabia blog (you may want to click "view post in English").

Posted by: Adam Feldman, Product Manager and Jeff Scudder, Software Engineer

[Gd] Android Market Problem

| More

Android Developers Blog: Android Market Problem

Earlier today we had a brief outage in Android Market. For a period of about thirty minutes, some users were unable to find any apps. The problem was detected and corrected, and we believe the user experience is now back to normal. We apologize for the outage.


[Gd] The Froyo Code Drop

| More

Android Developers Blog: The Froyo Code Drop

[This post is by Jean-Baptiste Queru, who moves truck-loads of source code in and out of the Googleplex. — Tim Bray]

Today is one of those days that has my heart racing; we’ve just released the source code for Android 2.2. This is a big step forward for the entire Android ecosystem. Please don’t melt the servers down again while trying to download that latest source code.

This blog typically talks about developing Android applications using the SDK and NDK. However, the skills of a platform contributor aren’t fundamentally different from those of an application developer. Those are simply different roles using the same skill set. I’m providing an update here to the experienced Android programmers all around the world on some of the recent developments in the Android Open-Source Project.

For Google engineers working on Android, releases are mostly known by their code names which are chosen alphabetically after tasty treats. I’ll call Android 2.2 “Froyo” throughout this post, since that was its code name. Raw version numbers don’t make me salivate as much as the thought of a cold dessert in the California summer.

Let’s have a look at some cool aspects of the new Froyo source, and let’s then take a few steps back to look at other noteworthy aspects of the Android Open-Source Project.

I had been increasingly involved in all previous open-source releases of Android, from testing the initial code drop to doing all the open-source-related git-level work in Eclair. Following that path, Froyo is the first release where my primary focus has been the Android Open-Source Project from start to finish. I thank the entire Android team for helping me all along with much of that work. Here are some aspects of Froyo that I am proud of, and that kept me busy for the last few months:

  • Hundreds of platform changes that people everywhere uploaded to the Android Open-Source Project were accepted and merged into Froyo. That process is now a well-oiled machine and will translate well to future contributions.

  • The open-source release happened in a single step. The whole source tree for the entire Android 2.2 platform is now available, with its full change history. That will accelerate everyone’s migration to Froyo from older releases. It is also already fully merged into the open-source master tree. Consequently, we can immediately review and accept platform contributions based on Froyo. That will therefore reduce the risk of merge conflicts between contributions to the open-source tree and changes in Google’s internal master tree where those contributions are meant to end up.

  • In order to make it easier for device manufacturers and custom system builders to use Froyo, we’ve restructured our source tree to better separate closed-source modules from open-source ones. We’ve made many changes to the open-source code itself to remove unintentional dependencies on closed-source software. We’ve also incorporated into the core platform all the configuration files necessary to build the source code of Android Open-Source Project on its own. You can now build and boot a fully open-source system image out of the box, for the emulator, as well as for Dream (ADP1), Sapphire (ADP2), and Passion (Nexus One).

  • Speaking of device support, we also open-sourced several additional hardware-related libraries that had been closed-source in previous releases, which will open the door to more contributions. Some examples are the recovery UI code for Dream, Sapphire and Passion, and the interface between the media framework and Qualcomm chipsets.

Besides the Froyo source code release, I wanted to mention several other improvements in the Android Open-Source Project:

  • We’ve been receiving contributions from more than twenty different companies, and many individuals. We have close to 4,000 registered users on the Gerrit code review server, with an average of 2 contributions per user. Those contributions have been in all areas of the system, from the depth of the C library all the way to the UI of the lock screen. They’ve covered the full range of complexities, from fixing typos in the documentation or reformatting code to adding developer-visible APIs or user-visible features. I want to thank everyone who got involved for their work and patience.

  • We’re now responding to platform contributions faster, with most changes currently getting looked at within a few business days of being uploaded, and few changes staying inactive for more than a few weeks at a time. We’re trying to review early and review often. As I’m typing this, only about a dozen platform contributions haven’t been looked at yet, with the oldest of those being 3 days old. More than 90% of contributions to the platform code itself have been actively looked at during the last 2 weeks. I hope that the speedy process will lead to more interactivity during the code reviews. I realize nevertheless that time differences around the world can make real-time communication a challenge.

  • Over the last 2 months, we’ve reached a final decision on more than 1,000 changes that were uploaded to our public Gerrit server. That means that those changes were either accepted or rejected after being reviewed. The high quality of the contributions we’ve been receiving throughout the history of the Android Open-Source Project has allowed us to steadily merge about 80% of them into the main repository, from where they migrate to official releases. That means that an average of 20 changes have been accepted through the Android Open-Source Project into the public git repositories every business day over those last 2 months.

  • We recently created two new official Google Groups related to the Android Open-Source Project. Android-building is meant to specifically discuss build issues (be sure to search the archives thoroughly before posting). Android-contrib is used to discuss actual contributions (don’t post if you don’t really intend to contribute and follow through on the review process, and if you haven’t already spent an hour or two researching things on your own).

  • We’re developing the developer tools directly in the open-source project, with no work in those areas happening behind closed doors. This covers the Eclipse plug-in and the emulator, and more than a dozen other SDK-related tools.

  • Once a platform version is open-sourced, all improvements to the Compatibility Test Suite related to that version are made directly to the open-source tree. In fact, release 2 of the 2.1 CTS was done 100% that way, with the development, testing and release process all happening straight in the open-source tree. This is now true for Froyo as well, and we are now accepting contributions into the Froyo branch of the CTS project.

I believe that those last two aspects are important to application developers. If you’re an application developer and you’d like to improve the tools that you and your fellow developers use, the process to make changes in that area is now a lot more transparent. Similarly, if during application development you find incompatibilities between devices and believe that those incompatibilities aren’t within the letter or the spirit of Android compatibility, you can help improve the situation by contributing a CTS test for that area.

With Android 2.2 now being available to the open-source world, and with the review process working smoothly, I’m looking forward to seeing a lot more high-quality contributions that will be used to build future versions of Android. My sweetest dream, which is also my worst nightmare, is to have so many contributions that I can’t keep up with them. Please don’t wake me up.


[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

Google Chrome 5.0.375.86 has been released to the Beta channel on Linux, Mac, and Windows.

The integrated flash player has been re-enabled by default.

If you find issues, please let us know:

Anthony Laforge,
Google Chrome Team

Wednesday, June 23, 2010

[Gd] OpenSocial Development Environment 1.0 Released

| More

iGoogle Developer Blog: OpenSocial Development Environment 1.0 Released

OSDE (OpenSocial Development Environment) is an Eclipse plugin for developing and testing OpenSocial applications.
It's an Apache-2-licensed open-source project hosted at:
Its milestone version 1.0 was released on June 22, 2010.

OSDE provides a rich set of features that both enable and enhance OpenSocial application development. It helps people building for both the client within a gadget, or even on another server using the Java RESTful client libraries. Its features include:
  • A built-in Shindig server for local testing.
  • An integrated database for storing and managing social data.
  • Simple project and gadget code generation wizards to quickly generate your OpenSocial application projects and application code.
  • A multi-paned gadget spec editor to facilitate gadget development.
  • A new "OpenSocial" Eclipse perspective that provides enhanced editing and debugging with easy access and control of the local Shindig and social database.
  • An OpenSocial REST Java client wizard that can quickly generate a new project along with sample code that uses the OpenSocial RESTful Java client library to connect to the local OpenSocial server. 
  • Live testing against iGoogle server.
  • Performance Analysis.
For details of installation and how to use it, please read the user guide at:

For bugs reporting or feature requests, please visit:

Thanks for your support.

Post content Posted by Albert Cheng, iGoogle Engineer

[Gd] Hands-on at OSCON

| More

Android Developers Blog: Hands-on at OSCON

This year at OSCON we and O’Reilly are co-presenting Android Hands-on. The event is on the evening of Wednesday, July 21 after the Expo-hall reception. Led by Google Android experts, the Hands-on will run from 7:00 pm-10:00 pm, and will be intense, technical, and structured. The goal is that you leave the room with foundation skills for writing interesting code for an open-source stack that runs on a pocket-sized Internet-connected device.

Some specific topics we’ll cover:

  • Porting existing C codebases to Android

  • Integrating Android apps with RESTful web interfaces

  • UI patterns and best practices

Sign-up in advance is required, and is restricted to registered full conference attendees and speakers. Spaces are limited and will be given out on a first-come-first-served basis.

If you’re considering participating, you might want to keep these things in mind:

  • Android apps are written in the Java programming language, with the exception of some performance-critical code (typically for games) written in C and C++. If you aren’t familiar with at least one of these languages, you won’t benefit much from the session.

  • To prepare, you might want to go to and download the SDK (available for Linux, Mac, and even Windows). Try building the HelloAndroid app and running it on the emulator.

  • You might also benefit from attending the Android for Java developers tutorial on Monday and/or Dan Morrill’s Android: The Whats and Wherefores session on Wednesday morning.


Tuesday, June 22, 2010

[Gd] HTML5 Rocks!: A resource for open web developers

| More

Chromium Blog: HTML5 Rocks!: A resource for open web developers

Because HTML5 and its related technologies cover so much ground, it can be a real challenge to get up to speed on them. That’s why today we're sharing HTML5 Rocks, a great new resource for developers and teams looking to put HTML5 to use today, including more information on specific features and when to use them in your apps.

We're launching the site with nine tutorials on specific HTML5 features. For example, you can learn how to successfully take your application offline, access the user's location with Geolocation, and even read local files from within JavaScript. In the site, we’ve also included a number of APIs that are defined outside the W3C HTML5 Spec, but kept them within this site as next-generation web applications span many specs. Watch the site as we’ll soon be adding more guides.

The Interactive Presentation, written in HTML5, demonstrates a number of features with examples you can toy with. You can use this presentation to learn more about HTML5, but also to conduct presentations with your team. Feel free to share it; all the content here is licensed Creative Commons Attribution.

The code playground lets you take working examples and edit them live, so you can get a feel for how the browser reacts to these APIs. And after you’ve hacked with, for example, the Notifications API, you can explore handpicked resources that include reference guides, development tools, and other community sites.

Send us a tweet at @ChromiumDev or post to the Chromium HTML5 group to let us know how we can improve the site for you. We look forward to seeing you experiment and build apps with these features!

Posted by Paul Irish, Google Chrome Developer Relations

[Gd] Google DevFest coming to Australia

| More

Google Apps Developer Blog: Google DevFest coming to Australia

Google DevFest Australia is a week long series of mini-conferences similar to Google I/O. DevFest will run from June 28th through July 2nd with scheduled sessions on Google Apps, App Engine, Wave, Chrome, Social, and Geo/Maps. Patrick Chanezon and I will be speaking on Tuesday covering Google Apps, App Engine, and Google Apps Marketplace.

DevFest is a Google kind of event for developers that is part hackathon, part seminar, and all fun. Developers will have access to Google developers, our newest APIs, and hear about the latest code to be open sourced.

It is also a learning experience for us at Google. We always like to see what developers are doing with our code and APIs. Working with developers is natural for us. Come see us if you are in Australia, and watch for blog updates and Tweets throughout the week. Here is a link to the sessions and registration information.

Watch this space for announcements of upcoming DevFests in other parts of the world.

Posted by Don Dodge, Google Developer Advocate

[Gd] HTML5 Rocks!

| More

Google Code Blog: HTML5 Rocks!

The term "HTML5" covers so many different topics that developers have a hard time getting up to speed on all of them. Some APIs and features are part of accepted standards, while some are still a work in progress. Additionally, there are a number of great resources out there, but most are still very hard to find. As announced on the blog, Google is releasing a new developer resource dedicated to all that is HTML5,

The site is broken up into four main sections:

Interactive Presentation
The presentation everyone is talking about! An interactive slide deck written entirely in HTML5 which demonstrates many of HTML5’s features. It even includes inline examples you can tinker with.

HTML5 Playground
The best way to learn this stuff is to try it out. The Playground is a sandbox area for editing and experimenting with live samples.

We're launching the site with an initial set of nine tutorials covering a bunch of different areas. We’ll continue to add more over time based on your input.

We've hand-picked some of our favorite tools, reference material, and sites; all generated by the online community. Do check them out. They’ll come in handy when developing your next web app.

We hope HTML5Rocks will help developers put HTML5 to use in the real world, today. We’d love to hear your thoughts on improving the site! Send us a tweet at @ChromiumDev or post to the Chromium HTML5 group with requests for content.

By Eric Bidelman, Google Chrome Developer Relations

[Gd] Quality links to your site

| More

Official Google Webmaster Central Blog: Quality links to your site

A popular question on our Webmaster Help Forum is in regard to best practices for organic link building. There seems to be some confusion, especially among less experienced webmasters, on how to approach the topic. Different perspectives have been shared, and we would also like to explain our viewpoint on earning quality links.

If your site is rather new and still unknown, a good way marketing technique is to get involved in the community around your topic. Interact and contribute on forums and blogs. Just keep in mind to contribute in a positive way, rather than spamming or soliciting for your site. Just building a reputation can drive people to your site. And they will keep on visiting it and linking to it. If you offer long-lasting, unique and compelling content -- something that lets your expertise shine -- people will want to recommend it to others. Great content can serve this purpose as much as providing useful tools.

A promising way to create value for your target group and earn great links is to think of issues or problems your users might encounter. Visitors are likely to appreciate your site and link to it if you publish a short tutorial or a video providing a solution, or a practical tool. Survey or original research results can serve the same purpose, if they turn out to be useful for the target audience. Both methods grow your credibility in the community and increase visibility. This can help you gain lasting, merit-based links and loyal followers who generate direct traffic and "spread the word." Offering a number of solutions for different problems could evolve into a blog which can continuously affect the site's reputation in a positive way.

Humor can be another way to gain both great links and get people to talk about your site. With Google Buzz and other social media services constantly growing, entertaining content is being shared now more than ever. We've seen all kinds of amusing content, from ASCII art embedded in a site's source code to funny downtime messages used as a viral marketing technique to increase the visibility of a site. However, we do not recommend counting only on short-lived link-bait tactics. Their appeal wears off quickly and as powerful as marketing stunts can be, you shouldn't rely on them as a long-term strategy or as your only marketing effort.

It's important to clarify that any legitimate link building strategy is a long-term effort. There are those who advocate for short-lived, often spammy methods, but these are not advisable if you care for your site's reputation. Buying PageRank-passing links or randomly exchanging links are the worst ways of attempting to gather links and they're likely to have no positive impact on your site's performance over time. If your site's visibility in the Google index is important to you it's best to avoid them.

Directory entries are often mentioned as another way to promote young sites in the Google index. There are great, topical directories that add value to the Internet. But there are not many of them in proportion to those of lower quality. If you decide to submit your site to a directory, make sure it's on topic, moderated, and well structured. Mass submissions, which are sometimes offered as a quick work-around SEO method, are mostly useless and not likely to serve your purposes.

It can be a good idea to take a look at similar sites in other markets and identify the elements of those sites that might work well for yours, too. However, it's important not to just copy success stories but to adapt them, so that they provide unique value for your visitors.

Social bookmarks on YouTube enable users to share content easily

Finally, consider making linking to your site easier for less tech savvy users. Similar to the way we do it on YouTube, offering bookmarking services for social sites like Twitter or Facebook can help spread the word about the great content on your site and draw users' attention.

As usual, we'd like to hear your opinion. You're welcome to comment here in the blog, or join our Webmaster Help Forum community.

Written by Kaspar Szymanski, Search Quality Strategist, Dublin

Monday, June 21, 2010

[Gd] Interactive Transcripts and Automatic Captions for Developer Videos

| More

Google Code Blog: Interactive Transcripts and Automatic Captions for Developer Videos

Did you notice the new Interactive Transcript feature that lets you scan quickly through the full text of any owner-captioned video that you’re watching on YouTube? For videos from I/O, that means you can quickly scan through a 60 minute talk to find just the part of the talk that you need to see. Or use your browser search with the Interactive Transcript to find a mention of an API call, and then click on a word in the transcript to jump straight to that part of the video.

Because developers don’t all speak English (and because some developers speak really fast when presenting) we caption every video that we post to Most of the year, that’s a pretty easy thing to keep up with. But last year, when we posted all the videos for Google I/O 2009, it took us months to get everything done.

This year, we captioned everything within 24 hours or less of the videos going live. I’m excited about that, because it wouldn’t have been possible without the new auto-caption and auto-timing features in YouTube. We also did something a little nerdy -- we used four different methods of captioning.

If you use YouTube to share talks from your own developer events, you might find this summary useful.

The two fastest options for producing and cleaning up our captions used auto-timing. We uploaded a transcript and had YouTube’s speech recognition calculate the timecodes for us.

The two auto-timing methods were:

  • CART live real-time transcript + auto-timing
    Because we had professional real-time transcriptionists at I/O, we could instantly caption anything that had a live session transcript. That’s how we got the keynotes captioned on the day of the event. We also used this method for the android talks.

  • Professional transcription + auto-timing
    This was less expensive than CART, and faster than full captions with timecodes, but slower than real-time transcription because we had to get video files to the transcribers.

Although these methods were fastest, auto-timing turned out not to be perfect for all videos. When mic quality varied, or we had too many speaker changes in a short period of time (e.g panel discussions or fireside chats), the timing sometimes slipped out of sync. You can still use the Interactive Transcript to see what was said, but it’s not ideal.

The two slower methods that we used were:

  • Pure 'traditional' captioning
    This is what we did last year for Google I/O 2009 videos. It’s slower, and more expensive, because you have to transcribe and set all the timecodes correctly. But the end result is 100% accurately timed. We did this to fix a video that the auto-timing had a lot of difficulty with.

  • Speech recognition (auto-captions) with human cleanup and editing
    This gave us perfect timecodes, just like traditional captions, and took less time than traditional captioning. It took slightly longer than auto-timing alone because we had to download the machine-generated auto-captions from YouTube to do the edits.

    Automatic captions are fantastic if you don't have time or budget to put any work into your captioning. But for I/O, we wanted our captions to be perfect on technical terms, so fully automatic captions weren't the best fit.

Not all of these methods are equal in terms of quality, but it’s interesting to compare. To see which method was used on a video, look for the track name in the caption menu. To compare owner-uploaded captions with pure machine-generated auto-captions, you can always choose ‘Transcribe Audio’ from the caption menu for our videos.

If you’d like to help improve caption quality, please watch a video and fill out our caption survey to tell us what you think of these captions! We know some of them are going to be a little off -- if you report issues, we’ll fix them.

By Naomi Bilodeau, Google Developer Programs

[Gd] partners with Google to make the web faster

| More

Google Code Blog: partners with Google to make the web faster logoAt we've always valued coding and serving our Web pages efficiently. It's good business sense: reducing operating costs while delivering on the promise of giving users the relevant, quality knowledge they need to quickly and easily accomplish their needs.

Our collaboration with Google's 'Make the Web Faster' team this spring has focused on the following projects:
  • Combining multiple CSS and JavaScript files to reduce external page calls.
  • Serving static content from a domain without cookies.
  • Leveraging browser and server-side caching wherever possible.
  • Compressing image file sizes on output, and serving .png wherever possible.
  • Asking rich media vendors and the Internet ad industry at large to take performance considerations into account when building and serving rich media ads. Any improvements made will ultimately benefit the advertiser, the server, the publisher and the user.
Our efforts thus far have yielded positive results: we've improved page load-time by an average of 19% 1, and we expect to see further improvement through the fall as we incrementally roll changes through all 700+ sites on our network. While it's hard to see a causal impact on network-wide CPC2 RPM3 exclusive of market and other seasonal factors, results from two A/B tests have been promising: one showed a 0.9% increase in CPC RPM4 and the other a 0.4% increase in CPC RPM5 on the page and throughout the user session.

Overall, we're extremely pleased with the results and excited to move forward. The experience has invigorated's commitment to providing quality content and good user experiences on light-weight pages.

By Tara Long Lawner, Senior Product Manager,

[1] Percentage based on Google Webmaster Page Speed performance 03/15/10 vs. 06/03/10 on's top ten sites.
[2] CPC is Cost Per Click, cost for the advertiser when the ad is clicked
[3] RPM is short for Revenue Per Mille (roman for thousand) pages. This is the revenue a website makes per thousand views of pages
[4] network-wide A/B test combining external CSS and JS conducted 03/26/10.
[5] network-wide A/B test serving images from a cookie-less domain conducted 04/02/10.

[Gd] Future-Proofing Your App

| More

Android Developers Blog: Future-Proofing Your App

[This post is by Reto Meier AKA @retomeier, who wrote the book on Android App development. — Tim Bray]

As a developer, I’m excited by Android’s potential as a single development platform that can make my apps available on a wide range of devices. From smartphones to televisions, Android is now being used on an increasingly diverse collection of hardware.

Last year’s Android SDK 1.6 release was the first to introduce support for variations in device hardware, paving the way for devices like the HTC Tattoo — a small screen device with a non-autofocus camera. Future devices, like Google TV, may not include some of the hardware features that we now expect, such a accelerometers and telephony.

We all want our apps available on as many devices as possible, but on some hardware they might just not make sense, so it’s important that apps are available only on the devices where they do.

Android Market Rule #1: Don't let existing applications break on new devices

As curators of the Android Market, one of our most important responsibilities is ensuring consumers and developers can trust the Market to only deliver applications to devices capable of running them.

The Android SDK includes built-in support for specifying which hardware features your application needs, ensuring that when we see more hardware variations, the Market will make sure your apps are available everywhere (and only where) they make sense.

Specify the hardware your app needs using the application Manifest

That includes the target and minimum SDK versions, supported screen sizes, and the required hardware features without which your app will “break”. You can specify the hardware features your app requires by adding a uses-feature node to your manifest.

<uses-feature android:name="android.hardware.microphone" />

By updating your manifest now to include all the hardware features you require, you effectively opt out of future hardware that won’t be capable of properly supporting your app.

Android Market Rule #2: Don't let existing applications break on new devices

In extreme cases — such as the introduction of small screen sizes in Android 1.6 — developers will be required to explicitly opt in their apps before they will be made visible in the Market on these new devices.

In other cases the Android Market will analyze the permissions requested by an app to determine if it implies a dependence on any particular hardware. For example, requiring the CALL_PHONE permission strongly implies the need for telephony hardware.

Until we provide a more convenient tool, you can use AAPT in the SDK to analyze your apps (2.2 SDK required) and see which device requirements are being implicitly added to your application:

aapt dump badging myApp.apk

Where your app uses a particular hardware feature, but you know (and have tested) that it will still work without it, you can specify it as optional by setting the required attribute to false.

<uses-feature android:name="android.hardware.telephony" android:required="false" />

Ensure your application manifest correctly identifies what hardware your app needs, and what is optional

With the uses-feature name strings now available, you can ensure right now that your app appears in the Market, where appropriate, on current and future hardware devices rather than waiting for the devices to be released.

It's in your interest as a developer to ensure your apps work well, and are available, on as many devices as possible and appropriate. Now is the time to test your applications and update your Manifest to opt in to all hardware configurations which you support, and opt out of those that don’t make sense.


[Gd] Running a Contest in Wave: Behind the Scenes

| More

Google Wave Developer Blog: Running a Contest in Wave: Behind the Scenes

Back in April, we ran a challenge together with Mashable, asking developers to make fun and useful extensions. We saw a lot of great extensions come out of it, like WaveTube, Poker, Wave Transformer, and more. Now, I want to take some time out to explain how an open-sourced Wave robot made it possible to run the contest entirely in Wave, from the submission to the voting.

1) Submission Wave

The process is all kicked off by the creation of a new submission wave.

To submit an entry, developers would install the Mashable Submitty extension. They then clicked 'New extension submission' in the New Wave menu, and watched a robot populate the new wave with a submission template. The robot does this by responding to the WaveletSelfAdded event, and appending text, form elements, and a gadget. The text describes the submission process, the form input elements let the developers give the robot information in a structured way, and the gadget manages the flow of submission.

2) Installer Checking

The robot helps automate some of the more tedious aspects of the review process, like checking an installer is valid.

When the developer is filling in the wave, they specify the URL of the installer XML in one of the input elements. When the robot sees a URL in that field, it grabs the XML, and parses it to look for all the required fields. If there are any errors, it reports them in an inline blip, and if not, it inserts the installer element inside that blip. By doing this, the reviewers can easily install the extension from inside the wave.

3) Workflow Gadget

The workflow gadget helps manage the sequence of steps, and let some participants move the sequence forward.

When the wave is first created, the only participants are the developer and the robot. When the developer is done filling out the information, they click "Share with Reviewers" in the gadget, which prompts the robot to add the review team Google Group and tag the wave with status-review. At that point, the gadget shows different options depending on who's viewing it. For the developer who submitted the extension, the gadget explains that the wave is currently shared with the team and will be responded to soon. For the admins of the review process, the gadget provides a "Approve for Gallery" button. When an admin clicks that button, the robot first checks that the event actually came from an admin (just in case someone's simulated the button click in javascript) and then kicks off the process to add the extension to the gallery.

4) Gallery Waves

The robot automates the process of creating individual waves that are rich in content, and of creating one central table of contents wave.

After the extension is approved, the robot starts by creating an individual wave about the extension - inserting the title, description, installer, a ratings gadget, and a sharing gadget. Since gadgets don't have access to the wave content around them, the robot injects the extension name into the state of the sharing gadget so users can easily tweet about it (e.g. "Checking out Requesty- http://www..."). Next, the robot fetches the table of contents wave using the Active API and appends an image and links for the new extension.

All in all, the Submitty extension helps automate a multi-step process in Wave while still allowing for freeform discussion. In the submission waves, we would often go back and forth with the submitter when trying out the extension and start up private replies to discuss the status of the extension with just the reviewers. In the gallery waves, wave users would report bugs and request features, and on the discussion wave for the most popular extension, Mr. Ray, they even got into a passionate discussion about the future of wave.

If you're interested in running a contest in wave or employing a similar workflow for your own use, check out the code for Mashable Submitty from the samples gallery. Let us know in the forum if you have any questions.

Posted by Pamela Fox, Developer Relations