Thursday, June 2, 2011

[Gd] More new features for the Gadget Dashboard

| More

iGoogle Developer Blog: More new features for the Gadget Dashboard

Did you know we are continuously adding new features to the iGoogle Gadget Dashboard? Today I’d like to let you know about a few of them.

First of all, we added two new data sets to the details page of your gadgets. Now you can see intuitive graphs in the “Installations and Removals” tab, which shows the number of gadget installations and gadget removals, and in the “Browser Errors” tab, where you can see errors recently reported by our end users’ browsers.

As you may have guessed, adding this information made the gadget details page too long, so we introduced a tabular view for that page.

(The tabular view, showing the new “Installations and Removals” data)

(“Browser Errors” table showing the top errors reported by our users’ browsers)

Additionally, the dashboard had been only available in English, but we added 7 other langueges a while ago, so it is now available in 8 languages: English, Spanish, Japanese, Korean, Portuguese, Russian, Simplified Chinese and Traditional Chinese. The localized iGoogle developer documentation will lead you to the localized dashboard. For example, after you select Japanese at, you will arrive at, which has a link for the Japanese version of the dashboard. Alternatively, you can explicitly add the URL parameter “?hl=ja” to the dashboard URL.

Lastly, in the next few days, we will start sending you weekly summary e-mails of your gadget usage. If you don’t want to receive these summary e-mails, you can opt-out from this service by just clicking a link at the bottom of the e-mail. The e-mails look like the following.

Gadget name: Weather

Author email:

Pageviews: 1,000,000 (+5.00% compared to the week of May 30, 2011)

Unique users: ...

Installations: ...

Removals: ...

Browser errors: ...

Gadget name: Youtube Gadget

Author email: …

Pageviews: …

Unique users: ...

Installations: ...

Removals: ...

Browser errors: ...


As you can see, iGoogle is still evolving! Happy coding. :)

Posted by Takashi Matsuo, Developer Advocate

[Gd] Now open source: 20 Things I Learned about Browsers and the Web

| More

The official Google Code blog: Now open source: 20 Things I Learned about Browsers and the Web

By Min Li Chan, Google Chrome Team

Late last year, we released an illustrated online guidebook for everyday users who are curious about how browsers and the web work. In building 20 Things I Learned about Browsers and the Web with HTML5, JavaScript and CSS with our friends at Fi, we heard from many of you that you’d like to get your hands on the source code. Today, we’re open sourcing all the code for this web book at, so that you can use and tinker with the code for your own projects.

20 Things I Learned was celebrated this year as an Official Honoree at the 15th Annual Webby Awards in the categories of Education, Best Visual Design (Function), and Best Practices. For those of you who missed our initial release last year, here’s a quick recap of the APIs behind some of the web book’s popular features:
  • The book uses the HTML5 canvas element to animate some of the illustrations in the book and enhance the experience with transitions between the hard cover and soft pages of the book. The page flips, including all shadows and highlights, are generated procedurally through JavaScript and drawn on canvas. You can read more about the page flips on this HTML5rocks tutorial.
  • The book takes advantage of the Application Cache API so that is can be read offline after a user’s first visit.
  • With the Local Storage API, readers can resume reading where they left off.
  • The History API provides a clutter-free URL structure that can be indexed by search engines.
  • CSS3 features such as web fonts, animations, gradients and shadows are used to enhance the visual appeal of the app.

With this open source release, we’ve also taken the opportunity to translate 20 Things I Learned into 15 languages: Bahasa Indonesia, Brazilian Portuguese, Chinese (Simplified and Traditional), Czech, Dutch, English, French, German, Italian, Japanese, Polish, Russian, Spanish, and Tagalog.

We hope that web books like 20 Things I Learned continue to inspire web developers to find compelling ways to bring the power of open web technologies to education. 20 Things I Learned is best experienced in Chrome or any up-to-date, HTML5-compliant modern browser. For those of you who’ve previously read this web book, don’t forget to hit refresh on your browser to see the new language options.

Min Li Chan is a Product Marketing Manager on the Google Chrome Team and the project curator/author for 20 Things I Learned about Browsers and the Web.

Posted by Scott Knaster, Editor


Wednesday, June 1, 2011

[Gd] How Google Tests Software - Part Seven

| More

Google Testing Blog: How Google Tests Software - Part Seven

By James Whittaker

The Life of a TE

The Test Engineer is a newer role within Google than either SWEs or SETs. As such, it is a role still in the process of being defined. The current generation of Google TEs are blazing a trail which will guide the next generation of new hires for this role. It is the process that is emerging as the best within Google that we present here.

Not all products require the services of a TE. Experimental efforts and early stage products without a well-defined mission or user story are certainly projects that won’t get a lot of TE attention. If the product stands a good chance of being cancelled (in the sense that as a proof of concept it fails to pass muster) or has yet to engage users or have a well defined set of features, testing it is largely something that should be done by the people developing it.

Even if it is clear that a product is going to get shipped, Test Engineers have little to do early in the development cycle when features are still in flux and the final feature list and scope is undetermined. Overinvesting in testing too early can mean a lot of things get thrown away. Likewise, early testing planning requires fewer test engineers than later cycle exploratory testing when the product is close to final form and the hunt for missed bugs has a greater urgency.

The trick in staffing a project with Test Engineers has to do with risk and return on investment. Risk to the customer and to the enterprise means more testing effort and requires more TEs. But that effort needs to be in proportion to the potential return. We need the right number of TEs and we need them to engage at the right time and with the right impact.

Once engaged, TEs do not have to start from scratch. There is a great deal of test engineering and quality-oriented work performed by SWEs and SETs which is the starting point for additional TE work. The initial engagement of the TE is to decide things such as:

· Where are the weak points in the software?

· What are the security, privacy, performance and reliability concerns?

· Do all the primary user scenarios work as expected? For all international audiences?

· Does the product interoperate with other products (hardware and software)?

· In the event of a problem, how good are the diagnostics?

All of this combines to speak to the risk profile of releasing the software in question. TEs don’t necessarily do all of this work, but they ensure that it gets done and they leverage the work of others is assessing where additional work is required. Ultimately, test engineers are paid to protect users and the business from bad design, confusing UX, functional bugs, security and privacy issues and so forth. At Google, TEs are the only people on a team whose full-time job is to look at the product or service holistically for weak points. As such, the life of a Test Engineer is much less prescriptive and formalized than that of an SET. TE’s are asked to help on projects in all stages of readiness: everything from the idea stage to version 8, or even watching over a deprecated or “mothballed” project. Often, a single TE will even span multiple projects particularly those with specialty type skills like security.

Obviously, the work of a TE varies greatly depending on the project. Some TE’s spend much of their time programming, much like an SET, but with more of a focus on end-to-end user scenarios. Other TE's take existing code and designs determine failure modes and look for errors that will cause those failures. In such a role a TE might modify code but not create it from scratch. TE's must be more systematic and thorough in their test planning and completeness with a focus on the actual usage and system experience. TE's excel at dealing with ambiguity in requirements and at reasoning and communicating about fuzzy problems.

Successful TEs accomplish all this while navigating the sensitivities and sometimes strong personalities of the development and product team members. When weak points are found, test engineers happily break the software, and drive to get these issues resolved with the SWEs, PMs, and SETs.

Such a job description is a frightening prospect given the mix of technical skill, leadership, and deep product understanding and without proper guidance it is a role in which many would expect to fail. But at Google a strong community of test engineers has emerged to counter this. Of all job functions, the TE role is perhaps the best peer supported role in the company and the insight and leadership required to perform it successfully means that many of the top test managers in the company come from the TE ranks.

There is a fluidity to the work of a Google Test Engineer that belies any prescriptive process for engagement. TE’s can enter a project at any point and must assess the state of the project, code, design, and users quickly and decide what to focus on first. If the project is just getting started, test planning is often the first order of business. Sometimes TEs are pulled in late in the cycle to evaluate whether a project is ready for ship or if there are any major issues before an early ‘beta’ goes out. If they are brought into a newly acquired application or one in which they have little prior experience, they will often start doing some exploratory testing with little to no planning. Sometimes projects haven’t been released for quite a while and just need some touchups/security fixes, or UX updates—calling for an even different approach. One size rarely fits all for TEs at Google.

[Gd] GTAC 2011 Open for Submission

| More

Google Testing Blog: GTAC 2011 Open for Submission

By James Whittaker

I am happy to announce that GTAC 2011 is now open for nominations. We're going to try and have an executive session, depending on interest, the afternoon/evening of October 25th at the Googleplex in Mountain View. This session is intended for top testing decision makers at top web, technology and software companies worldwide. It will be a chance for frank and open discussion about ours and the industry's collective challenges. It's intended to be a meeting of key decision makers and budget owners to share information, ideas and with a little luck spur some collaborations that will be good for the testing industry overall. Nominate your executive here.

The general session is by invitation only and prospective attendees and speakers must register and be selected. Speaker nominees are encouraged to point us to videos of prior presentations and any other material to help make our decision easier.

Please leave comments if there is some technology, tool or product you want to hear about so we end up with the best possible agenda.

I hope to see a lot of our readers in Mountain View in October!

[Gd] Bringing more context to Gmail contextual gadgets

| More

The official Google Code blog: Bringing more context to Gmail contextual gadgets

As part of the launch of Gmail contextual gadgets, Google released a set of predefined extractors that developers could use. These extractors allow developers to match content within a single part of an email message, such as the subject, and use that content to display relevant information to the current user.

Many Gmail contextual gadget developers have expressed a desire to match on more complex patterns than is possible with the predefined extractors. Today, with the launch of the Google Apps extensions console, these complex patterns, known as custom extractors, are now available to drive contextual gadgets.

Custom extractors allow developers to trigger their gadget when a series of conditions are met. For example, a developer could write an extractor that triggered a gadget only when “Hello world” appeared in the subject and “” was the sender of the email. This allows developers to more finely tune their gadgets, and provide even more relevant contextual information.

If you’re interested in writing a custom extractor you can get started by reading our documentation. If you have questions, please post them in the forum.

Andrew Wansley Dan Holevoet, Google Developer Team

[Gd] Introducing a new way for IT developers to extend Google Apps

| More

The official Google Code blog: Introducing a new way for IT developers to extend Google Apps

Today we're introducing the Google Apps extensions console, a new tool to help IT departments and in-house applications developers integrate with Google Apps.

In-house developers can now access the same Google Apps extension points first introduced in the Google Apps Marketplace. Applications can create links in the navigation bar (alongside “Calendar” and “Documents”), share a single sign-on with Google accounts, and run inside Gmail using rich contextual gadgets.

The extensions console helps in-house developers create new projects, manage team permissions, retrieve OAuth credentials, and upload their application manifest. Once the app is ready to deploy, administrators can install the app to their domain control panel for wider release.

You can get started with the console documentation to learn more.

Andrew Wansley Andrew Wansley, Google Developer Team

Monday, May 30, 2011

[Gd] Location targeting update in AdWords

| More

AdWords API Blog: Location targeting update in AdWords

In February, we launched city targeting in additional 17 countries, and our goal is to make location targeting more accurate, easy to use, and flexible. As part of planning for future improvements, we’re making several changes to the AdWords location targeting capabilities that will affect the way you operate with the API. These changes will start occurring after July 8, 2011 and include:
  • Changes to existing available locations: Due to changes in real-world geography or the existence of duplicate or overlapping location targets, we’re removing certain location targets in countries such as Japan, Denmark, Spain, and the Netherlands, among others. For example, in 2010, six provinces were abolished in Finland, and while you’ll no longer be able to target these provinces, you can continue targeting cities in Finland. You won’t be able to target these provinces through the API and UI, but you’ll be able to continue targeting cities in Finland. After the changes take effect, you won't be able to add the locations that are listed here to new campaigns. If you're currently targeting any of these locations in your existing campaigns, you should migrate them to the recommended targets in the list. Otherwise, we'll migrate them automatically. Please review the list carefully since some of these changes will result in migration to larger locations. After this change takes place, if you try to use any of these locations you’ll receive a TargetError.TARGETING_NOT_SUPPORTED from the API.
  • Sunset of PolygonTarget: You will no longer be able to add PolygonTargets through the API. You’ll still be able to retrieve and delete existing ones in your current campaigns. Any existing polygon target will continue to be used until the end of 2011. After that, all polygon targets that are still present in your AdWords campaigns will be migrated to other GeoTargets such as a city close to your polygon target or to specific ProximityTargets. We encourage you to replace your polygon targets to city, metro, province, country or proximity targets or we will migrate them automatically at end of 2011.
  • Removal of allowServiceOfAddress in ProximityTargets: In some countries, you have the option to use the address in a ProximityTarget to show with your ads by setting allowServiceOfAddress. This field will no longer be available in future API releases and ignored when used in current versions. If you want to display your business address or phone number, you will need to use AdWords location extensions.

These changes will take place after July 8, 2011 and we recommend you adjusting your applications before. We also recommend that you adjust the location targeting settings of your campaigns immediately with the available alternatives.

  David Torres, AdWords API Team