Announcing UX improvements in the sandbox

Thursday, July 2, 2009 at 4:53 PM

Over the last few days, we've introduced several improvements to the sandbox to help flesh out what the full social experience will look like for your users.

First, sharing a gadget is a richer experience — requestShareApp invites now display notifications at the top of the invitee's iGoogle page and in the "gadget shares" link on the left nav bar. This system smoothly handles all the different use cases for you. If you invite a friend who does not yet use iGoogle, they will receive an email inviting them to join iGoogle and to share the gadget with you. Then, if your friend creates an account they will be prompted to add you as a friend. If your friend already has iGoogle but does not have you listed as a friend and/or does not have the gadget, they will see one of the new social notifications prompting them to add the gadget and/or to add you as a friend, respectively. Finally if the friend you invited already has you as a friend and the gadget, they'll get a dismissable message saying that you have invited them. As a developer you won't have to worry at all about whether or not someone uses iGoogle, has the gadget, or is friends with the user — requestShareApp will handle that all transparently for you!

Next, you can delete the "Sandbox Friends" gadget, because our real control for editing and expanding your friends list is here, living in the "Friends" link on the left hand nav bar. This, in addition to the prompts described above, is how users will add friends to their accounts.

And finally, the Updates gadget continues to improve — multimedia Updates should be displaying much more cleanly now, and you can also filter Updates for those posted by your own gadgets. Remember that the final version of Updates, like the friends control and social notifications will live on the left nav bar, and gadgets will be limited to three Updates per user per day.

Posted by Dan Holevoet, Developer Programs

Stem the 401 Tide

at 10:13 AM

Some of you may have noticed that OpenSocial API calls in the sandbox have started returning 401s, regardless of whether or not you've enabled social ACLs in your gadget. We're in the process of changing a few things behind the scenes, one of which has the unfortunate side effect of breaking the ACL check. While this is straightened out, make sure to visit: http://www.google.com/ig?force_sandbox=1 for a squeaky-clean and error-free sandbox.

Posted by Dan Holevoet, Developer Programs

An update on "Updates"

Tuesday, May 26, 2009 at 4:00 PM

Updates are back! As the launch of OpenSocial support for iGoogle draws ever closer, we wanted to give you guys more ability to test and refine your gadget's use of the activity stream.

To that end we encourage you to install the Updates gadget which is now actively displaying Update streams from contacts in your Friend's group. Remember, this is not the final UI - when we launch, Updates will be built into the container, rather than appearing in a standalone gadget.

As you already know, in the wild there will be limits on the amount of Updates we allow from gadgets, to prevent spam. As of right now, we are considering a daily quota of three Updates per user per gadget. This limit will not be enforced on gadgets in the sandbox so that you can continue testing your code without worrying about these protections, but be aware that there will be some anti-spam restrictions when these features go live.

For more on Updates, check out the OpenSocial tutorial's activities section.

Posted by Tyler Odean, Associate Product Manager, iGoogle

The importance of being unsociable

Thursday, May 14, 2009 at 5:53 PM

A lot of the content we post on this blog is about social. Social is new, social is big, social is better (all true!) ... but, non-social is important too, and gadgets should behave gracefully when users have not enabled social features, or they aren't available. Not only is a large part of iGoogle's userbase not signed in, but when users add a new gadget to their pages, for the first time, it is always added without social features enabled. Users enable the social ACLs in a separate step, after the gadget has been added to the page.

Until they do that, the gadget will be rendered without social access - meaning that every single user will see your gadget without social access at least once. Plan for it! Make sure you can handle that case, even if you only display a message prompting users to sign in and enable social access so that your gadget can operate correctly.

For help with detecting whether a user's social functionality has been enabled and other iGoogle-specific OpenSocial questions, check out the Testing iGoogle State gadget. This cribsheet builds on the OpenSocial tutorial to provide a rapid way to look up example code for common social gadget tasks.

Many of the folks who contribute to OpenSocial and iGoogle will be at Google I/O in San Francisco on May 27-28. We love to talk about this stuff, so check out the Google I/O site to sign up and join us.

Posted by Tyler Odean, Associate Product Manager, iGoogle

Gadget Checker: A simple way to make good gadgets great

Tuesday, May 5, 2009 at 9:54 AM

Writing software is hard, and it's easy for bugs to creep in. Gadgets are no different. And while developing gadgets here at Google, we discovered that many gadget bugs only show up when you've finished developing -- like when Japanese users can't see that translation you worked on for ages, or when your gadget turns out to be frustratingly slow.

It's important to have great gadgets in iGoogle. To help you, we'd like to share a tool that we wrote to catch many common gadget errors: Gadget Checker. We like to think of it as a small tool with a big impact. Use it before you submit your gadget to the Directory to pick up errors such as missing ModulePrefs attributes and missing images, scripts or stylesheets. It also makes suggestions for avoiding common latency traps, like unused API libraries, and for internationalizing your gadget. Simply load a gadget and run the tests, and you may find that you've fallen into one of the common problems. If so, there's advice in the gadget on how to address the issue.

To allow developers to use the tool while developing their gadget, Gadget Checker can open a gadget saved as a local file or in the Google Gadget Editor. (Tip: Consider using a special iGoogle tab containing Gadget Checker and the GGE next to each other, just for developing gadgets.) Once you've opened a local file in Gadget Code Checker, you can save it directly to GGE to fix all the bugs you found. Gadget Checker can even check any existing gadget simply by entering its URL.

Of course, the list of checks is nowhere near complete. If there's some pet peeve that you wish Gadget Code Checker looked for, feel free to let us know. We hope Gadget Code Checker makes it easier for you to develop great gadgets, and are looking forward to developing additional tools to help too.

One more thing. We hope you'll join us at Google I/O in late May. It's a useful way to interact with Google engineers and other developers. And two days in San Francisco isn't too shabby, either! Register today.

Posted by Egmont Koblinger and Martin Strauss, iGoogle Software Engineers

Signing changes in the iGoogle sandbox

Friday, April 3, 2009 at 10:31 AM

In case you haven't seen the announcement on the OpenSocial blog, some changes to the way iGoogle's REST and RPC endpoints verify requests will be going live today, on the developer sandbox. If you're using a client library (Java, PHP, Python, Ruby), the latest versions will be compatible with these changes.

To ask questions about the client library changes, please check out the client libraries group. As always, for other questions, see the iGoogle developer forum.

Posted by Dan Holevoet, Developer Programs

The sandbox prods along

Thursday, March 19, 2009 at 2:34 PM

The iGoogle developer sandbox has always served as the bleeding edge version of iGoogle. It's the place to go when you want to be the first to try out new features. Unfortunately, if a bug sneaks into a sandbox release it can grind gadget development to a halt. This puts gadgets.* and OpenSocial developers in a tough spot, because the sandbox is the only place to develop with these features. Or, at least, it was.

Following on orkut's model, iGoogle will now have a "production" sandbox, meant to provide a more stable development environment. New features and improvements will hit the regular sandbox, first. After they've had some time to simmer, they'll move over to the production sandbox.

To enter the production sandbox, first enter the regular sandbox, then append the 'force_prod=1' parameter to your iGoogle URL. If you are not already in the sandbox, 'force_prod=1' will not trigger the proper behavior.

If you're hitting the REST/RPC endpoints, you should now use http://www-opensocial-sandbox.googleusercontent.com/api and http://www-opensocial-sandbox.googleusercontent.com/api/rpc for the sandbox endpoint, and http://www-opensocial.googleusercontent.com/api and http://www-opensocial.googleusercontent.com/api/rpc for the production equivalents.

As always, feel free to discuss sandbox issues in the developer forum.

Posted by Dan Holevoet, Developer Programs