Saturday, December 31, 2011

[Gd] Improved Customer Engagement & Discovery in the Google Apps Marketplace

| More

Google Apps Developer Blog: Improved Customer Engagement & Discovery in the Google Apps Marketplace

We recently updated the Google Apps Marketplace with several new features to help developers better engage with their customers and improve discoverability of apps in the marketplace.

Reply to Comments & Reviews

It’s no secret that engaging your customers and responding to their feedback is critical to success. It’s now possible to engage in conversations with customers based on comments & reviews for your app in the marketplace.

Rich Application Snippets in Google Search

Google Search recently introduced rich snippets for applications several months ago with enhanced search results for applications from marketplaces like Android Market and others. Marketplace apps will soon be appearing as rich snippets with ratings and pricing details.

New Category Home Pages

Lastly, we introduced new home pages for each category in the Marketplace to feature the top installed and newest apps for that category.

We hope that you find value in these changes and wish everyone a happy new year!

Steven Bazyl   profile | twitter | events

Steve is a Developer Advocate for Google Apps and the Google Apps Marketplace. He enjoys helping developers find ways to integrate their apps and bring added value to users.


[Gd] 2011 - A year of features, use cases and developers of Apps Script

| More

Google Apps Developer Blog: 2011 - A year of features, use cases and developers of Apps Script

2011 was the year of momentum for Google Apps Script. As 2012 dawns upon us, let us take a moment to reflect on the past year.

We started 2011 with a bang! In January we released a cloud-based Debugger into Apps Script’s IDE that proved to be very useful for developers. The Script Editor was upgraded bringing about many features and bug fixes. In March we implemented a very powerful feature of embedding Apps Script in Google Sites pages as Gadgets, making it easy to enhance Sites in amazing ways. We also improved Contacts Services, making it more stable with an improved API.

At Google I/O in May we launched Document Services, Gmail Services and the drag ‘n’ drop GUI Builder. These were major steps forward in making sure that Apps Script provides a full set of APIs to allow developers to build rich workflow and automation solutions.

We were very busy during the summer months preparing for a series of launch for later part of 2011. In September, we launched Charts Services. It allows users to dynamically create Charts and embed them in emails, UiApp or export as images. We also released three Google API services for Prediction, UrlShortener and Tasks APIs.

Lock and Cache Services launched in October. These services are important for building performant and scalable applications. We also improved the Script Editor by adding Project Support and made other UI improvements. November brought about the launch of Client Handlers and Validators. This is only the beginning of our commitment to allow developers to build more advanced UI using Apps Script.

In December we continued to improve the reliability and stability of Apps Script runtime. We capped the year by releasing Groups and Domain Services. And who can forget the very useful AdSense Services for AdSense advertisers!

Throughout the year we expanded our outreach channels. There were Apps Script sessions at Google I/O and Bootcamp, and several attendees got their last minute tickets through the Apps Script I/O challenge. We were at Google Developer Day and DevFest events, met with GTUGs, and hosted hackathons throughout the world. Our blog also featured scripts like Revevol’s Trainer Finder, Corey’s Gmail Snooze, Dave’s Flubaroo, Top Contributor’s Mail Merge, Saqib’s Idea Bank, and Drew’s Calorie Counting that showed the power of Apps Script.

Recently we started Office Hours in G+ hangout. These hangouts proved to be very popular, personal and effective means to share ideas with Apps Script community. Join us some day!

In our efforts to help educators, we worked with a New York city school to help them make most out of Google Apps. We also hosted many EDU focused webinars and workshops. In great Google tradition, Apps Script team participated in CAPE and Google Serve.

2012 is going to be an even more exciting and promising year. Tighten your seat belts because we intend to keep firing on all cylinders!

Saurabh Gupta profile | twitter | blog

Saurabh is a Developer Programs Engineer at Google. He works closely with Google Apps Script developers to help them extend Google Apps. Over the last 10 years, he has worked in the financial services industry in different roles. His current mission is to bring automation and collaboration to Google Apps users.


[Gd] Building Professional Video Sites with YouTube APIs

| More

YouTube API Blog: Building Professional Video Sites with YouTube APIs

Using video on your website can add greater depth and richness for your audience. However, to do encoding, hosting and streaming right it takes some time and skill. If you’re lacking in either, here are some suggestions for sites that make it easy to help you setup video-based websites.

VidCaster is a video content management system, whose goal is to make building a website with video as easy as possible.

VidCaster makes use of custom URLs, video sitemaps, metadata, and thumbnails to integrate well with search engines. They provide lots of features to customize your video site, like uploading a logo, picking a theme and choosing custom colors, and you can even upload custom CSS. Using their video management interface, you can publish, unpublish and delete videos. VidCaster can even distribute the videos from your video site to third-party sites such as YouTube and Twitter, and they can also integrate analytics from third-party sources.

VidCaster uses OAuth2 with the YouTube API to manage the user’s YouTube account, using both SUP (Simple Update Protocol) and polling to make sure a user’s video site is always in sync with their YouTube channel. Companies that use VidCaster include AirBnB, Hackers and Founders, and Dirtcast.

By integrating closely with YouTube’s data API, VidCaster makes it easy for users to take advantage of YouTube’s video service from within their own custom video site. tries to make it easy for businesses to build video sites about their company.

Like VidCaster, provides users with a variety of features to customize their video site. They too show videos hosted on YouTube, but their integration with YouTube doesn’t yet include all the features that VidCaster does — for instance, can show YouTube videos using the iframe player, but they haven’t yet integrated with YouTube’s data API. This is something they plan on doing early in 2012. also touts their mobile application which takes the friction out of recording and uploading video to the right place.

And they’re doing well at it — they were recently named a Red Herring Global 100 Winner. Internet World, City Index, and Staples are all example sites created using their platform:

Companies like VidCaster and are a welcome part of the online video ecosystem. As CEO Gillian O'Neil once noted, isn’t competing with YouTube. By enabling third-party video sites to embed YouTube videos, YouTube isn’t trying to get a bigger piece of the pie. They’re making the pie bigger.

—Shannon -jj Behrens, YouTube API Team

Thursday, December 29, 2011

[Gd] Understanding Playback Restrictions

| More

YouTube API Blog: Understanding Playback Restrictions

Have you ever tried to show a user a YouTube video embedded on your site only to find out that they don’t have access to view it? For instance, if you try to play the video below, it’ll say “This video contains content from test_yt_owner, who has blocked it on copyright grounds.” There are many reasons why video playback can be restricted. The user might be in a country where the video is blocked, or the video’s content owner might have decided to block access to the video from all mobile applications.

While we strive to make YouTube content available everywhere, we believe it's important to give YouTube content owners the ability to control where their videos are viewed, which sometimes means you can't view videos in a certain country or on a certain device.

With enhanced content controls comes increased complexity. The only foolproof way to determine if a user has access to watch a video is to ask them to try watching it. So, if you’re writing an application and you’d like to prevent users from seeing videos that they don’t have the ability to watch, here are a list of things to check:

1. yt:accessControl

Videos that are available for embedding on third-party applications will have the following:
<yt:accesscontrol action='embed' permission='allowed' />
If you’d like to only search for videos that are embeddable, add format=5 to your query.

Just as a video can be embeddable or not, it can also be syndicatable or not:
<yt:accesscontrol action='syndicate' permission='allowed' />
A video that is embeddable but not syndicatable will play on or on other sites that embed the YouTube player, but may not play on devices such as mobile phones or TVs. If you’d like to learn more about retrieving videos suitable for playback on mobile devices, see the developer’s guide.

2. Geo Restrictions

Some videos may be restricted in certain countries. This restriction applies to where the viewer is located, not where your third-party server is located. For instance, if a video is blocked in the US, it will have the following:
<media:restriction type='country'
When you make a query, you can add a restriction parameter to filter videos that will not be playable by a client with a specific IP or from a specific country.

3. yt:state

It’s also important to check the yt:state of the video in the API response. Even if yt:accessControl indicates that syndication is allowed, yt:state might override it. For example, a video that has limited syndication would have the following:
<yt:state name='restricted' reasoncode='limitedSyndication'>
Syndication of this video was restricted by its owner.
You might also see the message, “Syndication of this video was restricted by the content owner.” Hence, even if the uploader allows syndication, the content owner could override that and disallow syndication. For example, this could happen if someone uploads a video that contains a soundtrack that is owned by another content owner.

4. Rentals

Some YouTube videos are rentals. You can tell that they are rentals because they have a media:price tag:
<media:price type='rent' price='1.99' currency='USD' yt:duration='PT2592000S' />
Note that the media:price tag is only included in the response if you use a developer key in the query. If you are building a non-browser based YouTube application where it would be impossible for the user to rent a video, you might want to filter out the rentals. You can do that by passing the parameter paid-content=false.

5. Other Restrictions not Currently Exposed via the API

There are even more subtle restrictions that occasionally come into play. Not all of these are currently queryable via the API. For instance, some videos are only playable on a certain set of domains. As I mentioned above, the only foolproof way to know if a user has access to watch a video is to have them try watching it.

Going back to the video above, you might be wondering why it won’t play. If you look at its video entry:

you’ll see that it’s blocked in all countries:
<media:restriction type='country' relationship='deny'>
Furthermore, both syndication and embedding are disallowed:
<yt:accesscontrol action='embed' permission='denied' />
<yt:accesscontrol action='syndicate' permission='denied' />
Hopefully this short blog post on video playback restrictions will help you write applications that have a better understanding of what videos users can and can’t watch. If you have any questions, you can ask them on our forum.

—Shannon -jj Behrens, YouTube API Team

Friday, December 23, 2011

[Gd] Managing groups using the new Groups Settings API

| More

Google Apps Developer Blog: Managing groups using the new Groups Settings API

The recently launched Groups Settings API allows Google Apps domain administrators to write client applications for managing groups in their domain. Once you have created the groups and added members using the Provisioning API, you can use the Groups Settings API to perform actions like:

  • manage access to the group
  • configure discussion archiving
  • configure message moderation
  • edit a group's description, display format and custom fields

Let’s have a look at how you can make authorized calls to the Groups Settings API from your client application.

Getting Started

You must enable the Provisioning API to make requests to the Groups Settings API.You can do so by enabling the Provisioning API checkbox in the Domain settings tab of your Google Apps control panel.

Next, ensure that the Google Groups for Business and Email services are added to your domain by going to the Dashboard. If these services are not listed, add them by going to Add more services link next to the Service settings heading.

Now you are set to write client applications. Let's discuss the steps to write an application using the Python client library. You need to install the google-api-python-client library first.

You can register a new project or use an existing one from the APIs console to obtain credentials to use in your application. The credentials (client_id, client_secret) are used to obtain OAuth tokens for authorization of the API requests.

Authorization using OAuth 2.0

The Groups Settings API supports various authorization mechanisms, including OAuth 2.0. Please see the wiki for more information on using the library’s support for OAuth 2.0 to create a httplib2.Http object. This object is used by the Groups Settings service to make authorized requests.

Make API requests with GroupSettings service

The Python client library uses the Discovery API to build the Groups Settings service from discovery. The method build is defined in the library and can be imported to build the service. The service can then access resources (‘groups’ in this case) and perform actions on them using methods defined in the discovery metadata.

The following example shows how to retrieve the properties for the group

service = build(“groups”, “v1”, http=http) 
group = service.groups()
g = group.get(groupUniqueId=””).execute()

This method returns a dictionary of property pairs (name/value):

group_name = g['name']
group_isArchived = g['isArchived']
group_whoCanViewGroup = g['whoCanViewGroup']

The update method can be used to set the properties of a group. Let’s have a look at how you can set the access permissions for a group:

body = {'whoCanInvite': ALL_MANAGERS_CAN_INVITE,
'whoCanJoin': ‘INVITED_CAN_JOIN’,
'whoCanPostMessage': ‘ALL_MEMBERS_CAN_POST’,
'whoCanViewGroup': ‘ALL_IN_DOMAIN_CAN_VIEW’

# Update the properties of group
g1 = group.update(groupUniqueId=groupId, body=body).execute()

Additional valid values for these properties, as well as the complete list of properties, are documented in the reference guide. We have recently added a sample in the Python client library that you can refer to when developing your own application. We would be glad to hear your feedback or any queries you have on the forum.

Shraddha Gupta   profile

Shraddha is a Developer Programs Engineer for Google Apps. She has her MTech in Computer Science and Engineering from IIT Delhi, India.


[Gd] Fridaygram: goodbye to 2011

| More

The official Google Code blog: Fridaygram: goodbye to 2011

Author Photo
By Scott Knaster, Google Code Blog Editor

This is the last Fridaygram of 2011, and like most everybody else, we’re in a reflective mood. It’s also the 208th post on Google Code Blog this year, which means we’ve averaged more than one post every two days, so that’s plenty of stuff for you to read. What did we write about?

At Google, we love to launch. Many of our posts were about new APIs and client libraries. We also posted a bunch of times about HTML5 and Chrome and about making the web faster. And we posted about Android, Google+, and Google Apps developer news.

Many of our 2011 posts were about the steady progress of App Engine, Cloud Storage, and other cloud topics for developers. We also published several times about commerce and in-app payments.

2011 was a stellar year for Google I/O and other developer events around the world. Some of our most popular posts provided announcements, details, and recaps of these events. And we welcomed a couple dozen guest posts during Google I/O from developers with cool stories to tell.

The two most popular Code Blog posts of the year were both launches: the Dart preview in October, and the Swiffy launch in June.

Last, and surely least, I posted 26 Fridaygrams in an attempt to amuse and enlighten you. Thank you for reading those, and thanks for dropping by and reading all the posts we’ve thrown your way this year. See you in 2012!

And finally, please enjoy one more Easter egg.


[Gd] Download search queries data using Python

| More

Official Google Webmaster Central Blog: Download search queries data using Python

Webmaster level: Advanced

For all the developers who have expressed interest in getting programmatic access to the search queries data for their sites in Webmaster Tools, we've got some good news. You can now get access to your search queries data in CSV format using a open source Python script from the webmaster-tools-downloads project. Search queries data is not currently available via the Webmaster Tools API, which has been a common API user request that we're considering for the next API update. For those of you who need access to search queries data right now, let's look at an example of how the search queries downloader Python script can be used to download your search queries data and upload it to a Google Spreadsheet in Google Docs.

Example usage of the search queries downloader Python script
1) If Python is not already installed on your machine, download and install Python.
2) Download and install the Google Data APIs Python Client Library.
3) Create a folder and add the script to the newly created folder.
4) Copy the script to the same folder as and edit it to replace the example values for “website,” “email” and “password” with valid values for your Webmaster Tools verified site.
5) Open a Terminal window and run the script by entering "python" at the Terminal window command line:
6) Visit Google Docs to see a new spreadsheet containing your search queries data.

If you just want to download your search queries data in a .csv file without uploading the data to a Google spreadsheet use instead of in the example above.

You could easily configure these scripts to be run daily or monthly to archive and view your search queries data across larger date ranges than the current one month of data that is available in Webmaster Tools, for example, by setting up a cron job or using Windows Task Scheduler.

An important point to note is that this script example includes user name and password credentials within the script itself. If you plan to run this in a production environment you should follow security best practices like using encrypted user credentials retrieved from a secure data storage source. The script itself uses HTTPS to communicate with the API to protect these credentials.

Take a look at the search queries downloader script and start using search queries data in your own scripts or tools. Let us know if you have questions or feedback in the Webmaster Help Forum.

Written by Jonathan Simon, Webmaster Trends Analyst

[Gd] Getting to know the Android Developer Challenge finalists

| More

The official Google Code blog: Getting to know the Android Developer Challenge finalists

Author Photo
By Chukwuemeka Afigbo, Program Manager, Sub-Saharan Africa

Cross-posted from the Google Africa Blog

Last month, the five finalists of the Android Developer Challenge came together to share their experiences with the world via Google+ Hangouts. 

Selected from a group of more than 200 submissions and 30 semi-finalists, the five finalists were Chike Maduegbuna, Bobola Oniwura and Tope Omotunde of AfriNolly (Nigeria); David Lemayian of Olalashe (Kenya); Gerald Kibugi of Shopper’s Delight (Kenya); Herko Lategan of Rainbow Racer (South Africa); and Richard Marsh of Wedding Plandroid (South Africa). 

The interview was hosted by CP Africa, a popular African blog and Gbenga Sesan, Nigerian tech evangelist, who conducted the interview while sitting in the departure lounge of the Murtala Mohammed International Airport in Lagos as he waited to board his flight to Addis Ababa.

Thanks to the power of the internet and Google+, the interview was held simultaneously in Nigeria, Kenya and South Africa, in collaboration with three developer hubs: Umbono (Cape Town, South Africa), Co Creation Hub (Lagos, Nigeria) and iHub (Nairobi, Kenya). The finalists answered live questions and questions from people around the world including Ghana, Italy, Malaysia, Mali, Nigeria and Uganda using Google Moderator

The top-voted question was on how to prioritize features when building an application, while another participant wanted to know what kind of changes the finalists hoped to create in Africa with their applications. 

To learn more about the finalists for the Android Developer Challenge and their applications, please visit the new case studies section of the Google Africa Developers website. If you create solutions using Google services for developers (Google Apps, Chrome extensions, Android, App Engine, etc.) and want to share your story with the world, let us know!

Chukwuemeka Afigbo is a Program Manager in the Sub-Saharan Africa Outreach Team. He is an avid football (soccer) fan.

Posted by Scott Knaster, Editor

[Gd] Google Prediction API: faster, easier to use, and more accurate

| More

The official Google Code blog: Google Prediction API: faster, easier to use, and more accurate

Author Photo
By Marc Cohen, Developer Relations

This holiday season, the Google Prediction API Team is bringing you four presents and, thanks to the joys of cloud computing, no reindeer are required for delivery. Here’s what you’ve already received:
  • Faster on-ramp: We’ve made it easier to get started by enabling you to create an empty model (by sending a trainedmodels.insert request with no storageDataLocation specified) and add training data using the trainedmodels.update method. This change allows you to submit your model contents without needing to stage the data in Google Cloud Storage.
  • Improved updates: The algorithms used to implement model updates (adding additional data to existing models) have been modified to work faster than ever.
  • More classification algorithms: We’ve increased the number of classification algorithms used to build predictive models, resulting in across-the-board improvements in accuracy.
  • Integration with Google Apps Script: Prediction services are now available as part of Google Apps Script, which means you can integrate prediction services with Google Docs, Google Maps, Gmail, and other great Google products.
All of the above enhancements are supported by the current Prediction API version 1.4 so you can enjoy these features using the existing client libraries.

Happy Holidays from the Google Prediction API Team. We’re looking forward to bringing you more exciting features in 2012!

Marc Cohen is a member of Google’s Developer Relations Team in Seattle. When not teaching Python programming and listening to indie rock music, he enjoys using the Google Prediction API to peer into the future.

Posted by Scott Knaster, Editor

Thursday, December 22, 2011

[Gd] Building a Meeting Scheduler for Android using the new Calendar API

| More

Google Apps Developer Blog: Building a Meeting Scheduler for Android using the new Calendar API

Though developers are quite comfortable thinking in abstractions, we still find a lot of value in code examples and fully developed sample applications. Judging by the volume of comments, tweets, and git checkouts of the Au-to-do sample code we released a few weeks ago, our readers agree.

For Google Apps API developers who want to get started writing mobile apps, here’s a great new resource: a sample application that integrates Google Calendar API v3 with Android and illustrates best practices for OAuth 2.0. This meeting scheduler app built by Alain Vongsouvanh gets the user’s contact list, lets users select attendees, and matches free/busy times to suggest available meeting times. It provides a simple Android UI for user actions such as attendee selection:

The sample code for Meeting Scheduler demonstrates many key aspects of developing with Google Apps APIs. After authorizing all required access using OAuth 2.0, the Meeting Scheduler makes requests to the Calendar API. For example, the class FreeBusyTimesRetriever queries the free/busy endpoint to find available meeting times:

FreeBusyRequest request = new FreeBusyRequest();

request.setTimeMin(getDateTime(startDate, 0));
request.setTimeMax(getDateTime(startDate, timeSpan));

for (String attendee : attendees) {
requestItems.add(new FreeBusyRequestItem().setId(attendee));

FreeBusyResponse busyTimes;
try {
Freebusy.Query query = service.freebusy().query(request);
// Use partial GET to retrieve only needed fields.
busyTimes = query.execute();
// ...
} catch (IOException e) {
// ...

In this snippet above, note the use of a partial GET request. Calendar API v3, along with many other new Google APIs, provides partial response with GET and PATCH to retrieve or update only the data fields you need for a given request. Using these methods can help you streamline your code and conserve system resources.

For the full context of all calls that Meeting Scheduler makes, including OAuth 2.0 flow and the handling of expired access tokens, see Getting Started with the Calendar API v3 and OAuth 2.0 on Android. The project site provides all the source code and other resources, and there’s a related wiki page with important configuration details.

We hope you’ll have a look at the sample and let us know what you think in the Google Apps Calendar API forum. You’re welcome to create a clone of the source code and do some Meeting Scheduler development of your own. If you find a bug or have an idea for a feature, don’t hesitate to file it for evaluation.

Eric Gilmore  

Eric is a technical writer working with the Developer Relations group. Previously dedicated to Google Enterprise documentation, he is now busy writing about various Google Apps APIs, including Contacts, Calendar, and Provisioning.


[Gd] Optimizing bandwidth usage with gzip compression

| More

Google Apps Developer Blog: Optimizing bandwidth usage with gzip compression

All developers agree that saving bandwidth is a critical factor for the success of a mobile application. Less data usage means faster response times and also lower costs for the users as the vast majority of mobile data plans are limited or billed on a per-usage basis.

When using any of the Google Data APIs in your application, you can reduce the amount of data to be transferred by requesting gzip-encoded responses. On average, the size of a page of users returned by the Provisioning API (100 accounts) is about 100 Kb, while the same data, gzip-encoded, is about 5 Kb -- 20 times smaller! When you can reduce data sizes at this dramatic scale, the benefits of compression will often outweigh any costs in client-side processing for decompression.

Enabling gzip-encoding in your application requires two steps. You have to edit the User-Agent string to contain the value gzip and you must also include an Accept-Encoding header with the same value. For example:

User-Agent: my application - gzip
Accept-Encoding: gzip

Client libraries for the various supported programming languages make enabling gzip-encoded responses even easier. For instance, in the .NET client library it is as easy as setting the boolean UseGZip flag of the RequestFactory object:

service.RequestFactory.UseGZip = true;

For any questions, please get in touch with us in the respective forum for the API you’re using.

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.


[Gd] Website user research and testing on the cheap

| More

Official Google Webmaster Central Blog: Website user research and testing on the cheap

Webmaster level: Intermediate

As the team responsible for tens of thousands of Google’s informational web pages, the Webmaster Team is here to offer tips and advice based on their experiences as hands-on webmasters.

If you’ve never tested or analyzed usage of your website, ask yourself if you really know whether your site is useful for your target audience. If you’re unsure, why not find out? For example, did you know that on average users scroll down 5.9 times as often as they scroll up, meaning that often once page content is scrolled past, it is “lost?” (See Jakob Nielsen’s findings on scrolling, where he advises that users don’t mind scrolling, but within limits.)

Also, check your analytics—are you curious about high bounce rates from any of your pages, or very short time-on-page metrics?

First, think about your user

The start of a web project—whether it’s completely new or a revamp of an existing site—is a great time to ask questions like:

  • How might users access your site—home, office, on-the-go?
  • How tech-savvy are your visitors?
  • How familiar are users with the subject matter of your website?

The answers to some of these questions can be valuable when making initial design decisions.

For instance, if the user is likely to be on the road, they might be short on time to find the information they need from your site, or be in a distracting environment and have a slow data connection—so a simple layout with single purpose would work best. Additionally, if you’re providing content for a less technical audience, make sure it’s not too difficult to access content—animation might provide a “wow” factor, but only if your user appreciates it and it’s not too difficult to get to the content.

Even without testing, building a basic user profile (or “persona”) can help shape your designs for the benefit of the user—this doesn’t have to be an exhaustive biography, but just some basic considerations of your user’s behavior patterns.

Simple testing

Testing doesn’t have to be a costly operation – friends and family can be a great resource. Some pointers:

  • Sample size: Just five people can be a large enough number of users to find common problems in your layouts and navigation (see Jakob Nielsen’s article on why using a small sample size is sufficient).
  • Choosing your testers: A range of different technical ability can be useful, but be sure to only focus on trends—for example, if more than 50% of your testers have the same usability issue, it’s likely a real problem—rather than individual issues encountered.
  • Testing location: If possible, visit the user in their home and watch how they use the site—observe how he/she normally navigates the web when relaxed and in their natural environment. Remote testing is also a possibility if you can’t make it in person—we’ve heard that Google+ hangouts can be used effectively for this (find out more about using Google+ hangouts).
  • How to test: Based on your site’s goals, define 4 or 5 simple tasks to do on your website, and let the user try to complete the tasks. Ask your testers to speak aloud so you can better understand their experiences and thought processes.
  • What to test: Basic prototypes in clickable image or document format (for example, PDF) or HTML can be used to test the basic interactions, without having to build out a full site for testing. This way, you can test out different options for navigation and layouts to see how they perform before implementing them.
  • What not to test: Focus on functionality rather than graphic design elements; viewpoints are often subjective. You would only get useful feedback on design from quantitative testing with large (200+) numbers of users (unless, for example, the colors you use on your site make the content unreadable, which would be good feedback!). One format for getting some useful feedback on the design can be to offer 5-6 descriptive keywords and ask your user to choose the most representative ones.
Overall, basic testing is most useful for seeing how your website’s functionality is working—the ease of finding information and common site interactions.

Lessons learned

In case you’re still wondering whether it’s really worth research and testing, here are a few simple things we confirmed from actual users that we wouldn’t have known if we hadn’t sat with actual users and watched them use our pages, or analyzed our web traffic.

  • Take care when using layouts that hide/show content: We found when using scripts to expand and collapse long text passages, the user often didn’t realize the extra content was available—effectively “hiding” the JavaScript-rendered content when the user searches within the page (for example, using Control + F, which we’ve seen often).

    Wireframe of layout tested, showing “zipped”
    content on the bottom left

    Final page design showing anchor links in the top
    and content laid out in the main body of the page

  • Check your language: Headings, link and button text are what catches the user’s eye the most when scanning the page. Avoid using “Learn more…” in link text—users seem averse to clicking on a link which implies they will need to learn something. Instead, just try to use a literal description of what content the user will get behind the link—and make sure link text makes sense and is easy to understand out of context, because that is often how it will be scanned. Be mindful about language and try to make button text descriptive, inviting and interesting.
  • Test pages on a slower connection: Try out your pages using different networks (for example, try browsing your website using the wifi at your local coffee shop or a friend’s house), especially if your target users are likely to be viewing your pages from a home connection that’s not as fast as your office network. We found a considerable improvement in CTR and time-on-site metrics in some cases when we made scripted animations much simpler and faster (hint: use Google’s Page Speed Online to check performance if you don’t have access to a slower Internet connection).
So if you’re caught up in a seemingly never-ending redevelopment cycle, save yourself some time in the future by investing a little up front through user profiling and basic testing, so that you’re more likely to choose the right approach for your site layout and architecture.

We’d love to hear from you in the comments: have you tried out website usability testing? If so, how did you get on, and what are your favorite simple and low-cost tricks to get the most out of it?

Tuesday, December 20, 2011

[Gd] Speed metrics in Google Analytics

| More

The official Google Code blog: Speed metrics in Google Analytics

Author Photo
By Satish Kambala, Staff Software Engineer

At Google we believe that speed matters and a faster web is better for everyone. That’s why we started the Make The Web Faster initiative. To improve the speed of a website, we need to measure how fast web pages load. The Site Speed report, which is now available by default to all users of Google Analytics, provides just that: it enables website owners to measure page load time for their web pages.

You can use the Site Speed report to correlate speed with other metrics in Google Analytics, such as page views and conversions. This enables website owners to identify and optimize those pages that drive these metrics. Page load times can be analyzed by browser type or user location to understand if specific optimizations are required. Recently, we enhanced the Site Speed report by adding a new section called Technical (see screenshot below) which displays network and server time components of page load time.

site speed report screen shot

You can learn more about the Site Speed report here. This report, along with powerful page speed analysis tools such as Page Speed Online, will help website owners delight their users by building fast and responsive websites.

Have ideas on how to make your website faster or ways to speed up the entire Web? Send us your thoughts.

Satish Kambala works at Google on stuff that helps in making the web faster. In his free time, apart from watching cricket and movies, Satish likes exploring places with his wife.

Posted by Scott Knaster, Editor

[Gd] Announcing the Archive Feed of the Documents List API

| More

Google Apps Developer Blog: Announcing the Archive Feed of the Documents List API

Users of the Google Documents List API have traditionally had to perform individual export operations in order to export their documents. This is quite inefficient, both in terms of time and bandwidth for these operations.

To improve latency for these operations, we have added the Archive Feed to the API. Archives allow users to export a large number of items at once, in single ZIP archives. This feature provides a useful optimization for users, greatly increasing the efficiency of export operations. Additionally, users can receive emails about archives, and choose to download them from a link provided in the email.

This feature had a soft release earlier this year, and we think it’s now ready for prime time. For more information, please see the Archive Feed documentation.

Vic Fryzel profile | twitter | blog

Vic is a Google engineer and open source software developer in the United States. His interests are generally in the artificial intelligence domain, specifically regarding neural networks and machine learning. He's an amateur robotics and embedded systems engineer, and also maintains a significant interest in the security of software systems and engineering processes behind large software projects.

[Gd] Doodles for your Google Apps domain

| More

Google Apps Developer Blog: Doodles for your Google Apps domain

Since 1998, when the first doodle was released, they have been one of the most loved features of the Google home page. There have been doodles to celebrate all kinds of events, including national holidays, birthdays of artists and scientists, sports competitions, scientific discoveries and even video games! Also, doodles have evolved from simple static images to complex applications, such as the interactive electric guitar used to celebrate the birthday of Les Paul.

Want your company logo to change for selected events or holidays, just like doodles? The Admin Settings API allows domain administrators to write scripts to programmatically change the logo of their Google Apps domain, and Google App Engine offers the ability to configure regularly scheduled tasks, so that those scripts can run automatically every day.

With these two pieces combined, it is pretty easy to implement a complete solution to change the domain logo on a daily basis (assuming the graphic designers have prepared a doodle for each day), as in the following screenshot:

Let’s start with a Python App Engine script called

import gdata.apps.adminsettings.service
from google.appengine.ext import webapp
from google.appengine.ext.webapp import util
from datetime import date

class DoodleHandler(webapp.RequestHandler):
# list of available doodles
'1-1': 'images/newyearsday.jpg',
'2-14': 'images/valentinesday.jpg',
'10-31': 'images/halloween.jpg',
'12-25': 'images/christmas.jpg'

# returns the path to the doodle corresponding to the date
# or None if no doodle is available
def getHolidayDoodle(self, date):
key = '%s-%s' % (date.month,
if key not in self.DOODLES:
return None

return self.DOODLES[key]

# handles HTTP requests by setting today’s doodle
def get(self):
doodle = self.getHolidayDoodle(

if doodle:
service = gdata.apps.adminsettings.service.AdminSettingsService()
// replace domain, email and password with your credentials
// or change the authorization mechanism to use OAuth
service.domain = 'MYDOMAIN.COM' = 'ADMIN@MYDOMAIN.COM'
service.password = 'MYPASSWORD'
service.source = 'DoodleApps'

# reads the doodle image and update the domain logo
doodle_bytes = open(doodle, "rb").read()

# webapp initialization
def main():
application = webapp.WSGIApplication([('/', DoodleHandler)],

if __name__ == '__main__':

The script uses a set of predefined doodles which can be edited to match your list of images or replaced with more sophisticated logic, such as using the Google Calendar API to get the list of holidays in your country.

Every time the script is triggered by an incoming HTTP request, it will check whether a doodle for the date is available and, if there is one, update the domain logo using the Admin Settings API.

In order for this script to be deployed on App Engine, you need to to configure the application by defining a app.yaml file with the following content:

application: doodleapps
version: 1
runtime: python
api_version: 1

- url: .*

We want the script to run automatically every 24 hours, without the need for the administrator to send a request, so we also have to define another configuration file called cron.yaml:

- description: daily doodle update
url: /
schedule: every 24 hours

Once the application is deployed on App Engine, it will run the script on a daily basis and update the logo.

The holiday season is upon us. Could there be a better time for your company to start using doodles?

Happy Holidays!

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.


[Gd] Domain user management with Apps Script

| More

Google Apps Developer Blog: Domain user management with Apps Script

Managing the user accounts in a Google Apps domain can be a daunting task when you have hundreds or thousands of them and you have no tools to automate the process. The Google Apps Provisioning API allows developers to write user management applications in the programming language of their choice, but many system administrators prefer a script-based solution instead. The recently launched UserManager Apps Script service fills the gap, providing Google Apps domain administrators an easy way to automate tasks such as batch user creation or update.

With the new Apps Script service, creating a user will be as easy as writing a single line of code:

var user = UserManager.createUser("newuser", "John", "Smith", "mypassword");

The UserManager service also makes it easy to perform the same task on each account in the domain. The following sample shows how you can force all users to change their passwords at the next login:

var users = UserManager.getAllUsers();
for (var i in users) {

Calls to the UserManager service can also be scheduled to run hourly or daily, or in response to certain events thanks to Apps Script Triggers.

Interested in what else you can do with the UserManager service? Please check the documentation and get in touch with us on the the forum for any questions about its usage or to share more info about your project with the community.

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.


[Gd] Watch out for XmlPullParser.nextText()

| More

Android Developers Blog: Watch out for XmlPullParser.nextText()

Jesse Wilson

[This post is by Jesse Wilson from the Dalvik team. —Tim Bray]

Using XmlPullParser is an efficient and maintainable way to parse XML on Android. Historically Android has had two implementations of this interface:

The implementation from Xml.newPullParser() had a bug where calls to nextText() didn’t always advance to the END_TAG as the documentation promised it would. As a consequence, some apps may be working around the bug with extra calls to next() or nextTag():

    public void parseXml(Reader reader)
throws XmlPullParserException, IOException {
XmlPullParser parser = Xml.newPullParser();

parser.require(XmlPullParser.START_TAG, null, "menu");
while (parser.nextTag() == XmlPullParser.START_TAG) {
parser.require(XmlPullParser.START_TAG, null, "item");
String itemText = parser.nextText();
parser.nextTag(); // this call shouldn’t be necessary!
parser.require(XmlPullParser.END_TAG, null, "item");
System.out.println("menu option: " + itemText);
parser.require(XmlPullParser.END_TAG, null, "menu");

public static void main(String[] args) throws Exception {
new Menu().parseXml(new StringReader("<?xml version='1.0'?>"
+ "<menu>"
+ " <item>Waffles</item>"
+ " <item>Coffee</item>"
+ "</menu>"));

In Ice Cream Sandwich we changed Xml.newPullParser() to return a KxmlParser and deleted our ExpatPullParser class. This fixes the nextTag() bug. Unfortunately, apps that currently work around the bug may crash under Ice Cream Sandwich:

org.xmlpull.v1.XmlPullParserException: expected: END_TAG {null}item (position:START_TAG <item>@1:37 in 
at com.publicobject.waffles.Menu.parseXml(
at com.publicobject.waffles.Menu.main(

The fix is to call nextTag() after a call to nextText() only if the current position is not an END_TAG:

  while (parser.nextTag() == XmlPullParser.START_TAG) {
parser.require(XmlPullParser.START_TAG, null, "item");
String itemText = parser.nextText();
if (parser.getEventType() != XmlPullParser.END_TAG) {
parser.require(XmlPullParser.END_TAG, null, "item");
System.out.println("menu option: " + itemText);

The code above will parse XML correctly on all releases. If your application uses nextText() extensively, use this helper method in place of calls to nextText():

  private String safeNextText(XmlPullParser parser)
throws XmlPullParserException, IOException {
String result = parser.nextText();
if (parser.getEventType() != XmlPullParser.END_TAG) {
return result;

Moving to a single XmlPullParser simplifies maintenance and allows us to spend more energy on improving system performance.


Monday, December 19, 2011

[Gd] Simple development of App Engine apps using Cloud SQL - Introducing Google Plugin for Eclipse 2.5

| More

Google App Engine Blog: Simple development of App Engine apps using Cloud SQL - Introducing Google Plugin for Eclipse 2.5

Since we added SQL support to App Engine in the form of Google Cloud SQL, the Google Plugin for Eclipse (GPE) team has been working hard on improving the developer experience for developing App Engine apps that can use a Cloud SQL instance as the backing database.

We are pleased to announce the availability of Google Plugin for Eclipse 2.5. GPE 2.5 simplifies app development by eliminating the need for manual tasks like copying Cloud JDBC drivers, setting classpaths, typing in JDBC URLs or filling in JVM arguments for connecting to local/remote database instances.

GPE 2.5 provides support for:

  • Configuring Cloud SQL/MySQL instances

  • Auto-completion for JDBC URLs

  • Creating database connections in Eclipse database development perspective

  • OAuth 2.0 for authentication.

Configuring Cloud SQL/MySQL instances
App Engine provides a local development environment in which you can develop and test your application before deploying to App Engine. With GPE 2.5, you now have the ability to configure your local development server to use a local MySQL instance or a Cloud SQL instance for testing. When you choose to deploy your app, it will use the configured Cloud SQL instance for App Engine.

Auto-completion for JDBC URLs
GPE 2.5 supports auto-completion for JDBC URLs, and quick-fix suggestions for incorrect JDBC URLs.

Creating database connections in Eclipse database development perspective
The Eclipse database development perspective can be used to configure database connections, browse the schema and execute SQL statements on your database.

Using GPE 2.5, database connections are automatically configured in the Eclipse database development perspective for the Development SQL instance and the App Engine SQL instance.

You can also choose to manually create a new database connection for a Cloud SQL instance. In GPE 2.5, we have added a new connection profile for Cloud SQL.

GPE 2.5 now uses OAuth 2.0 (earlier versions were using OAuth 1.0)  to securely access Google services (including Cloud SQL) from GPE. OAuth 2.0 is the latest version of the OAuth protocol focussing on simplicity of client development.

Can’t wait to get started?
Download GPE here and write your first App Engine and Cloud SQL application using GPE by following the instructions here.

We hope GPE 2.5 will make cloud application development using App Engine and Cloud SQL a breeze. We always love to hear your feedback and the GPE group is a great place to share your thoughts.

Posted on behalf of the Google Plugin for Eclipse Team