Monthly Archives: July 2014

Support for v201406 reports in AdWords scripts

We are announcing support for AdWords API v201406 reports in AdWords scripts. This version introduces several changes to the reporting columns.

Columns and fields cleanup

We've removed duplicates and changed column and display names in some reports:

Column Name
Change
Comments
ValuePerConvManyPerClick
Removed
Use ValuePerConversionManyPerClick instead.
ValuePerConv
Removed
Use ValuePerConversion instead.
TotalConvValue
Removed
Use ConversionValue instead.
PrimaryUserLogin
Removed
AccountId
Removed
Use ExternalCustomerId as unique account ID instead.
TargetingSetting
Removed
This column is now called IsRestrict and returns a proper boolean value.
NonDeletedAdGroupCount
Removed
New column name is NonRemovedAdGroupCount.
NonDeletedAdGroupCriteriaCount
Removed
New column name is NonRemovedAdGroupCriteriaCount.
NonDeletedCampaignCount
Removed
New column name is NonRemovedCampaignCount.


We also made changes to some enumerations for relevance and consistency:
  • Status value for an enabled object is now ENABLED across all reports. Before, it was ACTIVE for some objects.
  • Removed objects now have a status of REMOVED instead of DELETED.
  • The PRODUCT_LISTING_AD_CLICKS display name has changed from Offer to Product listing ad.
If your scripts use these fields in reports, make sure you fix the AWQL when migrating to the new version of the reporting API. Keep in mind that if you don’t use API versioning in your reports, then your code will now be using reports API version v201406 by default.

New report fields

Several new report fields were introduced:

Report Name
New columns
Campaign Performance Report
ServingStatus
Click Performance Report
UserListId
Product Partition Report
date fields, CampaignName, AdGroupName
Multiple reports
ExternalCustomerId, IsRestrict, BiddingStrategyType
Campaign, AdGroup, Ad, and Keyword Performance Reports
Labels


You can refer to https://developers.google.com/adwords/api/docs/appendix/reports for the list of supported reports and columns.

If you have any questions about this feature or the AdWords scripts in general, you can post them on our developer forum.

Anash P. Oommen, AdWords Scripts Team

Learn How UX Design can Make Your App More Successful

By Nazmul Idris, a Developer Advocate at Google who's passionate about Android and UX design

As a mobile developer, how do you create 5-star apps that your users will not just download, but love to use every single day? How do you get your app noticed, and how do you drive engagement? One way is to focus on excellence in design — from visual and interaction design to user research, in other words: UX design.

If you’re new to the world of UX design but want to embrace it to improve your apps, we've created a new online course just for you. The UX Design for Mobile Developers course teaches you how to put your designer hat on, in addition to your developer hat, as you think about your apps' ideal user and how to meet their needs.

The course is divided into a series of lessons, each of which gives you practical takeaways that you can apply immediately to start seeing the benefits of good UX design.

Without jargon or buzzwords, the course teaches where you should focus your attention to bring in new users, keep existing users engaged, and increase your app's ratings. You'll learn how to optimize your app, rather than optimizing login/signup forms, and how to use low-resolution wireframing.

After you take the course, you'll "level up" from being an excellent developer to becoming an excellent design-minded developer.

Check out the video below to get a taste of what the course is like, and click through this short deck for an overview of the learning plan.

The full course materials — all the videos, quizzes, and forums — are available for free for all students by selecting “View Courseware”. Personalized ongoing feedback and guidance from Coaches is also available to anyone who chooses to enroll in Udacity’s guided program.

If that’s not enough, for even more about UX design from a developer's perspective, check out our YouTube UXD series, on the AndroidDevelopers channel: http://bit.ly/uxdplaylist.


Responding to Article 29 Working Party’s Questions

The group of European data protection agencies in the Article 29 Working Party last week invited three US-based search engines - Google, Microsoft, and Yahoo!- to discuss “the practical implementation” of the Right to be Forgotten. Before the meeting, the working party sent us a questionnaire.

Today, in a move to support the working party’s goal of transparency, we are publishing our answers.



The European Court of Justice ruling has sparked a debate about privacy and access to information. We are actively complying with it. Our answers also make clear that many questions raised by the ruling remain unresolved - and will be the subject of a welcome public discussion over coming months.

Posted by William Echikson, Senior Manager Communications and Public Affairs, Brussels

Testing on the Toilet: Don’t Put Logic in Tests

by Erik Kuefler

This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.

Programming languages give us a lot of expressive power. Concepts like operators and conditionals are important tools that allow us to write programs that handle a wide range of inputs. But this flexibility comes at the cost of increased complexity, which makes our programs harder to understand.

Unlike production code, simplicity is more important than flexibility in tests. Most unit tests verify that a single, known input produces a single, known output. Tests can avoid complexity by stating their inputs and outputs directly rather than computing them. Otherwise it's easy for tests to develop their own bugs.

Let's take a look at a simple example. Does this test look correct to you? 

@Test public void shouldNavigateToPhotosPage() {
  String baseUrl = "http://plus.google.com/";
  Navigator nav = new Navigator(baseUrl);
  nav.goToPhotosPage();
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());
}

The author is trying to avoid duplication by storing a shared prefix in a variable. Performing a single string concatenation doesn't seem too bad, but what happens if we simplify the test by inlining the variable? 

@Test public void shouldNavigateToPhotosPage() {
  Navigator nav = new Navigator("http://plus.google.com/");
  nav.goToPhotosPage();
  assertEquals("http://plus.google.com//u/0/photos", nav.getCurrentUrl()); // Oops!
}

After eliminating the unnecessary computation from the test, the bug is obvious—we're expecting two slashes in the URL! This test will either fail or (even worse) incorrectly pass if the production code has the same bug. We never would have written this if we stated our inputs and outputs directly instead of trying to compute them. And this is a very simple example—when a test adds more operators or includes loops and conditionals, it becomes increasingly difficult to be confident that it is correct.

Another way of saying this is that, whereas production code describes a general strategy for computing outputs given inputs, tests are concrete examples of input/output pairs (where output might include side effects like verifying interactions with other classes). It's usually easy to tell whether an input/output pair is correct or not, even if the logic required to compute it is very complex. For instance, it's hard to picture the exact DOM that would be created by a Javascript function for a given server response. So the ideal test for such a function would just compare against a string containing the expected output HTML.

When tests do need their own logic, such logic should often be moved out of the test bodies and into utilities and helper functions. Since such helpers can get quite complex, it's usually a good idea for any nontrivial test utility to have its own tests.

New version of Google Drive viewer

As part of the new Google Drive, we are updating Drive’s viewer. The new viewer is faster, cleaner and provides easier ways to connect with third-party Drive apps. It also brings a unified viewing experience across Drive content and Gmail attachments. Note that as part of this change we will remove support for adding file-level commenting of non-Google file formats. This change doesn’t impact comments in Google Docs, Sheets and Slides, and existing comments on non-Google formats will be retained and available to view. Release track:
Rapid release and Scheduled release (rolling out gradually) For more information:


Note: all launches are applicable to all Google Apps editions unless otherwise noted

whatsnew.googleapps.com
Get these product update alerts by email
Subscribe to the RSS feed of these updates

Seeking advice on the Right to be Forgotten

Earlier this summer we announced the formation of an Advisory Council on the Right to be Forgotten. As the Council begins its work, it is seeking comment from experts on the issues raised by the CJEU ruling. Experts will be considered for selection to present to the Council in-person during public consultations held this fall, in the following cities:
  • September 9 in Madrid, Spain
  • September 10 in Rome, Italy
  • September 25 in Paris, France
  • September 30 in Warsaw, Poland
  • October 14 in Berlin, Germany
  • October 16 in London, UK
  • November 4 in Brussels, Belgium
The Council welcomes position papers, research, and surveys in addition to other comments. We accept submissions in any official EU language. Though the Council will review comments on a rolling basis throughout the fall, it may not be possible to invite authors who submit after August 11 to present evidence at the public consultations.

Stay tuned for details on the Council’s activity.

Posted by Betsy Masiello, Google Secretariat to the Council

Google I/O 2014 App Source Code Now Available

By Bruno Oliveira, Tech Lead of the I/O app project

The source code for the 2014 version of the Google I/O app is now available. Since its first release on Google Play a few weeks before the conference, the I/O app was downloaded by hundreds of thousands of people, including on-site attendees, I/O Extended event participants and users tuning in from home. If one of the goals of the app is to be useful to conference attendees, the other primary goal is to serve as a practical example of best practices for Android app design and development.

In addition to showing how to implement a wide variety of features that are useful for most Android apps, such as Fragments, Loaders, Services, Broadcast Receivers, alarms, notifications, SQLite databases, Content Providers, Action Bar and the Navigation Drawer, the I/O app source code also shows how to integrate with several Google products and services, from the Google Drive API to Google Cloud Messaging. It uses the material design approach, the Android L Preview APIs and full Android Wear integration with a packaged wearable app for sending session feedback.

To simplify the process of reusing and customizing the source code to build apps for other conferences, we rewrote the entire sync adapter to work with plain JSON files instead of requiring a server with a specific API. These files can be hosted on any web server of the developer's choice, and their format is fully documented.

Storing and syncing the user's data (that is, the personalized schedule) is crucial part of the app. The source code shows how user data can be stored in the Application Data folder of the user's own Google Drive account and kept in sync across multiple devices, and how to use Google Cloud Messaging to trigger syncs when necessary to ensure the data is always fresh.

The project includes the source code to the App Engine app that can be reused to send GCM messages to devices to trigger syncs, as well as a module (called Updater) that can be adapted to read conference data from other backends to produce the JSON files that are consumed by the I/O app.

We are excited to share this source code with the developer community today, and we hope it will serve as a learning tool, a source of reusable snippets and a useful example of Android app development in general. In the coming weeks we will post a few technical articles with more detailed information about the IOSched source code to help bring some insight into the app development process. We will continue to update the app in the coming months, and as always, your pull requests are very welcome!

Support for dual screens in Chromebox for meetings devices

Domains using Chromebox for meetings devices will be able to simply plug in a second display to their Chromebox’s display port and that display will behave as a secondary display. During a video call, this will allow participants to see the audience and the projected presentation at the same time. Release track:
Rapid release and Scheduled release For more information:
Using dual displays


Note: all launches are applicable to all Google Apps editions unless otherwise noted

whatsnew.googleapps.com
Get these product update alerts by email
Subscribe to the RSS feed of these updates

Remotely manage Chromebox video meetings

Admins can now better manage video calls in Chromebox for meetings devices right from the Google Apps Admin console, with options like remotely starting, muting and hanging up a meeting. Meeting participants are still in full control of the device in their conference room, even if the video call is started remotely. For example, meetings are muted by default, but participants can unmute the microphone using the remote control if they need to be heard. They can also end the call or perform any other task available on the device. Release track:
Rapid release and Scheduled release For more information:


Note: all launches are applicable to all Google Apps editions unless otherwise noted

whatsnew.googleapps.com
Get these product update alerts by email
Subscribe to the RSS feed of these updates

Eject guests from a Hangout

Hangouts participants will now have the ability to remove other participants from a Hangout. This is only available to people from the same domain as the Hangout creator. For example, if a person creates a Hangout from Calendar, people in their same domain will be able to eject others from the call. Any participants from outside the domain will not have this ability. Ejected external participants will not be able to re-join the call unless explicitly re-invited by a person within the domain. Ejected participants from within the domain can re-join with the invite link. Release track:
Rapid release and Scheduled release For more information:
https://support.google.com/a/answer/6065029#eject


Note: all launches are applicable to all Google Apps editions unless otherwise noted

whatsnew.googleapps.com
Get these product update alerts by email
Subscribe to the RSS feed of these updates