Googlers live all over the world, and so do Google's users. In fact, more than half of iGoogle's users are outside the US, which is why we're pleased today to announce the release of support for social gadgets on iGoogle in more than 30 languages, from Bulgarian to Vietnamese.
That means if you're developing or thinking about developing a social gadget to help users connect and collaborate on iGoogle, the size of your potential audience more than doubled! Now is a great time to explore our developer's site to learn about developing social gadgets for iGoogle. Or, if you already have a social gadget, you can click here to learn how to make it accessible to an international audience.
To learn more about how to make iGoogle and even more fun and personal homepage, you can check out the video below.
Monday, 23 November 2009
Friday, 20 November 2009
Launching the iGoogle Gadget Dashboard
As Googlers, we love data. More data lets us make better decisions and make improvements to our products. As fellow gadget authors, we know that once you've developed a gadget, it can be difficult to get data that lets you know how your gadget is doing. The stats and comments in the directory are tailored for users, not developers, to help them make better decisions about which gadgets to install. Developers deserve a way to get data that lets them improve their gadgets.
Worry no longer! We're pleased to announce the launch of the iGoogle gadget dashboard, a place where developers can manage their gadgets and see detailed analytics about their gadgets' usage. Right now the dashboard allows you to see user numbers over time, number of gadget loads in home and canvas view, as well a geographic break down of users. We plan on adding more features to the dashboard in the near future which will give developers even more detailed information.
If you've already built an iGoogle gadget, go to the dashboard and add it. All you have to do is log in and enter the URL of any gadget you own or developed. Enjoy!
If you have any questions about the gadget dashboard, please visit the iGoogle Developer Forum.
Worry no longer! We're pleased to announce the launch of the iGoogle gadget dashboard, a place where developers can manage their gadgets and see detailed analytics about their gadgets' usage. Right now the dashboard allows you to see user numbers over time, number of gadget loads in home and canvas view, as well a geographic break down of users. We plan on adding more features to the dashboard in the near future which will give developers even more detailed information.
If you've already built an iGoogle gadget, go to the dashboard and add it. All you have to do is log in and enter the URL of any gadget you own or developed. Enjoy!
If you have any questions about the gadget dashboard, please visit the iGoogle Developer Forum.
Monday, 19 October 2009
Hot off the press: gadgets.* migration guide
A little over a month, we announced the deprecation of the legacy gadgets API, and in the intervening time have been hard at work on resources to help with the transition. The first of these resources, a gadgets.* migration guide, has just been posted to code.google.com.
The guide includes mappings between _IG_* and gadgets.* methods, helper functions, and pointers to third-party libraries that you can use in your updated gadgets.
If you have any questions about the migration guide, or the transition from _IG_* to gadgets.*, please visit the iGoogle Developer Forum.
The guide includes mappings between _IG_* and gadgets.* methods, helper functions, and pointers to third-party libraries that you can use in your updated gadgets.
If you have any questions about the migration guide, or the transition from _IG_* to gadgets.*, please visit the iGoogle Developer Forum.
Tuesday, 29 September 2009
Deprecating shareable-prefs API on iGoogle
If you don't know about or use the shareable-prefs API, you can safely stop reading now. If you do, we want to let you know that we'll be deprecating this API and feature.
A little over a year ago, iGoogle added shareable-prefs, enabling gadgets to share state across multiple users' pages. Since then, iGoogle has rolled out support for OpenSocial, enabling a collaboration model that is more tightly integrated into an application's design. Given this, along with the low adoption of the shareable-prefs feature in gadgets, we've decided it's time to deprecate the shareable-prefs feature.
In the next few weeks, iGoogle will remove the UI elements for shareable-prefs, preventing any new gadgets from implementing this feature. A few weeks later, iGoogle will break the links between these gadgets entirely, at which point, the gadgets will behave as if they were never shared at all. However, both users will retain the data in their preferences. The gadgets should continue to function in every other regard, but gadgets that wish to share data between users should implement OpenSocial's requestShareApp (paired with appdata, or a 3rd-party storage mechanism).
If you have any questions about these changes, please let us know in the iGoogle Developer Forum.
A little over a year ago, iGoogle added shareable-prefs, enabling gadgets to share state across multiple users' pages. Since then, iGoogle has rolled out support for OpenSocial, enabling a collaboration model that is more tightly integrated into an application's design. Given this, along with the low adoption of the shareable-prefs feature in gadgets, we've decided it's time to deprecate the shareable-prefs feature.
In the next few weeks, iGoogle will remove the UI elements for shareable-prefs, preventing any new gadgets from implementing this feature. A few weeks later, iGoogle will break the links between these gadgets entirely, at which point, the gadgets will behave as if they were never shared at all. However, both users will retain the data in their preferences. The gadgets should continue to function in every other regard, but gadgets that wish to share data between users should implement OpenSocial's requestShareApp (paired with appdata, or a 3rd-party storage mechanism).
If you have any questions about these changes, please let us know in the iGoogle Developer Forum.
Monday, 14 September 2009
The more things change, the more they stay the same
The legacy gadgets API has had a storied life, as both the first version of the gadgets API that drove iGoogle, and the direct predecessor of the current gadgets.* API. As with many APIs there comes a time when we must say goodbye to the past, and embrace the present. The gadgets.* API has gained wide acceptance, both on Google and non-Google gadget containers, and is the standard API for gadget development. And so, as of today, the legacy gadgets API is officially deprecated.
I'll give you all a moment to wipe away the tears of sadness (or joy as the case may be). Now, here are the details:
For most gadgets, the changes should be simple to implement. For each _IG_* method, there is usually a direct equivalent gadgets.* method. For instance, _IG_AdjustIFrameHeight maps directly to gadgets.window.adjustHeight, and performing a find and replace is sufficient. In a small subset of cases, multiple _IG_* methods map to a single gadgets.* method. For instance, _IG_FetchContent and _IG_FetchXmlContent both map to gadgets.io.makeRequest with different parameters. Developers should refer to the relevant section of the developer's guide to find gadgets.* equivalents.
If you have any questions, as always, feel free to inquire in the iGoogle Developer Forum.
I'll give you all a moment to wipe away the tears of sadness (or joy as the case may be). Now, here are the details:
- The legacy API is officially deprecated as of today, September 14th.
- For three months, the legacy API will continue in its current state.
- On or around December 14th, any new gadget submissions to the iGoogle directory must be using the gadgets.*, in order to be accepted, but existing gadgets may continue to use the legacy API.
- On the same date, the remaining inlined gadgets will be disabled.
- Finally, one year after deprecation, September 14th, 2010, gadgets using the legacy API will cease to function on iGoogle, and the majority of other Google-owned gadget containers (such as orkut, Gmail, and Calendar).
- Reminders will be posted when these important dates approach.
For most gadgets, the changes should be simple to implement. For each _IG_* method, there is usually a direct equivalent gadgets.* method. For instance, _IG_AdjustIFrameHeight maps directly to gadgets.window.adjustHeight, and performing a find and replace is sufficient. In a small subset of cases, multiple _IG_* methods map to a single gadgets.* method. For instance, _IG_FetchContent and _IG_FetchXmlContent both map to gadgets.io.makeRequest with different parameters. Developers should refer to the relevant section of the developer's guide to find gadgets.* equivalents.
If you have any questions, as always, feel free to inquire in the iGoogle Developer Forum.
Wednesday, 12 August 2009
iGoogle is a social being
If you've been a devoted reader of this blog you're probably no stranger to the idea that "social is better" when it comes to the web. Activities such as reading the news, doing a crossword puzzle, sharing a todo list, or watching a video are all better when done with a friend. Coincidentally, these are all things that iGoogle users love to do, so bringing social to iGoogle is a logical next step.
Developers have had a chance to sneak a peek at what iGoogle has been doing in the social space for many months, in the iGoogle developer sandbox. As of today, social gadgets taking advantage of the OpenSocial API will now work in both the US and Australia, with other countries soon to follow. That's tens of millions of iGoogle users with access to social gadgets, if you're keeping count.
Of course, iGoogle is a little bit different than most of the sites which support OpenSocial, so here's a quick rundown of the differences:
Developers have had a chance to sneak a peek at what iGoogle has been doing in the social space for many months, in the iGoogle developer sandbox. As of today, social gadgets taking advantage of the OpenSocial API will now work in both the US and Australia, with other countries soon to follow. That's tens of millions of iGoogle users with access to social gadgets, if you're keeping count.
Of course, iGoogle is a little bit different than most of the sites which support OpenSocial, so here's a quick rundown of the differences:
- An iGoogle page is personal, and not shared with other users. In OpenSocial terms, this means that VIEWER and OWNER are always the same person.
- Friendship between two users may be non-mutual. This allows developers to use a "following" model in their applications. For cases where it's important to verify mutual friendship (sharing private data, for instance), developers can use the isFriendsWith filter when requesting the user's mutual friends.
- iGoogle has users without canvas view, with canvas view but without social, and with social, all at the same time. And, some users sign in to use iGoogle while others remain signed out. Developers should make sure their gadgets work gracefully across feature sets so that users always have the optimal experience. This blog post provides more details and an example gadget for checking different cases.
- iGoogle supports organic growth of applications with two mechanisms.
- Application sharing (via requestShareApp), allows developers to reach a wider audience by encouraging users to engage their friends inside of a given application. By default, requestShareApp will list all of the user's Friends and users can auto invite new friends by email. iGoogle will email recipients without iGoogle accounts, or present a notification within the UI to existing iGoogle users to add the gadget and become friends.
- Updates (via requestCreateActivity), allow developers to call out specific user actions, to share them with a wider audience. There is a current limit of 3 updates per user, per app, per day, which may be increased in the future.
Wednesday, 5 August 2009
Every happy gadget is the same, every unhappy gadget is unhappy in its own way
Not so long ago we wrote about the need to keep your social gadgets robust to adversity. We received a lot of questions about how to detect when social conditions have broken down, and what to tell users when they have. So here's a quick cheatsheet for how to determine what might be interfering with the normal operation of your gadget, and what to do about each of them.
- The user is in a domain without canvas view.
All gadgets that take advantage of canvas view should also be prepared to support those domains for which canvas view is not available. To confirm that a canvas view is available, you can insert a Content section without a view specified, as outlined in this blog post. If your gadget does not support a home view only environment, we suggest telling the user "This gadget requires a feature that is not available in your locale at this time. Please check back at a later date." For more on views, check out the iGoogle Developer Guide. - The user is in a domain where OpenSocial is not available.
If a user is in a domain where canvas view is available a good next step is to test whether that domain has access to OpenSocial functionality. A gadget can determine if the user is on an OpenSocial supported domain or not by calling gadgets.util.hasFeature('opensocial-0.8'), which will return true if the domain supports OpenSocial. If your gadget requires OpenSocial to operate correctly, we recommend you tell the user "This gadget requires a feature that is not available in your locale at this time. Please check back at a later date." - The user is not signed in.
Remember that a significant portion of iGoogle's users are not signed in and won't have any available social information to draw from. A gadget can determine if the user has signed in or not by making a request for the owner or viewer and checking the ID of the user. A logged out user is considered anonymous, and will have a viewer ID of -1. If your gadget requires access to OpenSocial information in order to operate we suggest you give users the message "This gadget cannot access the information it needs so that you can share or collaborate with friends. Please sign in to enable access." In many cases, of course, gadgets can still function even without social features. In that case - we suggest the message "This gadget lets you share and collaborate with friends on iGoogle. Sign in to use these features." - The user has not enabled the gadget's social access.
After installing a gadget a user will be prompted to enable that gadget to access their friend list and activity stream. If the gadget makes an OpenSocial request for information that the user has not enabled access to, it will fail with error code 403 (FORBIDDEN). If your gadget needs access to one or both of these datasets, we recommend the message "This gadget cannot access the information it needs so that you can share or collaborate with friends. Please adjust the gadget's settings to enable access." Similarly if your gadget can still function without access to these social features we recommend the message "This gadget lets you share and collaborate with friends on iGoogle. Please adjust the gadgets settings to use these features." Remember that all users will see your gadget displayed without social access at least once, so make sure your gadget handles this case gracefully! - The user hasn't added any friends.
Finally remember that most users will begin with no friends on their friends list. If your gadget needs friends in order operate normally, we recommend that you use tell your users "You can use this gadget to share and collaborate with friends on iGoogle. Share with friends." where you can link "share with friends" to the requestShareApp call, which allows users to simultaneously add friends and invite them to add your gadget.
Thursday, 2 July 2009
Announcing UX improvements in the sandbox
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.
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.
Stem the 401 Tide
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.
Tuesday, 26 May 2009
An update on "Updates"
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.
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.
Thursday, 14 May 2009
The importance of being unsociable
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.
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.
Tuesday, 5 May 2009
Gadget Checker: A simple way to make good gadgets great
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.
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.
Friday, 3 April 2009
Signing changes in the iGoogle sandbox
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.
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.
Thursday, 19 March 2009
The sandbox prods along
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.
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.
Tuesday, 24 February 2009
Are you in the sandbox? Here's a quick way to check
Can't figure out if your account is in the developer sandbox or not? Sometimes the "Welcome to the iGoogle Developer sandbox" message is obscured. Sometimes developers are confused about the behavior of the http://google.com/ig/sandbox page (which acts as a toggle, not just a redirect). And sometimes sandbox features aren't working properly, so that even if you are in the sandbox, it looks like you aren't.
Here's a small gadget to provide a little heads up on the sandbox status. If you're in the sandbox, it lets you know and gives you a quick way to leave. If you're not, it gives you a quick way to enter. And, finally, if it thinks you are in the sandbox, but features don't seem to be working, it tells you that, too. Think of it as your personal sandbox valet.
The exact behavior relies on the current rollout of features (and using the .com TLD), so it will likely need an update down the road as launches occur. Please test it, add it to your pages, and check the status message if things aren't working properly.
For questions and comments, feel free to add to this thread in the forum.
Here's a small gadget to provide a little heads up on the sandbox status. If you're in the sandbox, it lets you know and gives you a quick way to leave. If you're not, it gives you a quick way to enter. And, finally, if it thinks you are in the sandbox, but features don't seem to be working, it tells you that, too. Think of it as your personal sandbox valet.
The exact behavior relies on the current rollout of features (and using the .com TLD), so it will likely need an update down the road as launches occur. Please test it, add it to your pages, and check the status message if things aren't working properly.
For questions and comments, feel free to add to this thread in the forum.
Friday, 23 January 2009
iGoogle's getting some changes under the hood
If you've had a chance to look at recent gadgets documentation, or tried out the iGoogle developer sandbox, you're probably aware that gadgets.* is the new hotness. Sadly, the _IG_* methods are all that work in production.
Starting within the next month, iGoogle will be undergoing some significant behind-the-scenes changes. The first recipients will be gadgets in open syndication, which will gain support for gadgets.*. We've worked hard to make sure gadgets work properly with the new architecture, and gadgets that use _IG_* methods should still function properly. However, there are two things that you, as a developer, should note.
First, support for datatype=location is now deprecated, and you should use another method, such as the Google Maps API geocoder, for positional data.
Second, iGoogle will dynamically rewrite some HTML and JavaScript for faster loading and rendering times. While this is generally a good thing, some malformed HTML and JavaScript can cause problems. Make sure to wrap your JavaScript code as demonstrated by the following example to avoid many common issues:
Starting within the next month, iGoogle will be undergoing some significant behind-the-scenes changes. The first recipients will be gadgets in open syndication, which will gain support for gadgets.*. We've worked hard to make sure gadgets work properly with the new architecture, and gadgets that use _IG_* methods should still function properly. However, there are two things that you, as a developer, should note.
First, support for datatype=location is now deprecated, and you should use another method, such as the Google Maps API geocoder, for positional data.
Second, iGoogle will dynamically rewrite some HTML and JavaScript for faster loading and rendering times. While this is generally a good thing, some malformed HTML and JavaScript can cause problems. Make sure to wrap your JavaScript code as demonstrated by the following example to avoid many common issues:
As always, if you have issues, let us know in the iGoogle Developer Forum.
<script type="text/javascript">
<!--
// js code goes here...
// -->
</script>
Wednesday, 14 January 2009
New ACLs on social features
Up until today, gadgets installed in the iGoogle developer sandbox had implicit access to social data, with no way for users to opt-out without uninstalling the gadget. We've added a feature to give more finely-grained control to users and allow users to explicitly grant or deny access to social data to their gadgets.
When users install gadgets that use social data (indicated by requiring the OpenSocial feature), they will be prompted to give permission to access social data. If a gadget is released without social features and is upgraded, users will be prompted for access within the gadget when the new version is first rendered.
When OpenSocial gadgets are available to all iGoogle users, users must grant permission before gadgets are allowed access to social data. For sandbox users, we want to ease development, so sandbox gadgets are allowed access to social data before confirmation.
Developers, this is important, so take note. If users deny access to social data, the gadget should have a good error message and graceful fallback UI.
Check for the ability to access social data with this snippet of code:
gadgets.util.hasFeature("opensocial-0.8")
and fall back gracefully if permission is not granted.
If you have any questions, please join us in the iGoogle Developer Forum.
When users install gadgets that use social data (indicated by requiring the OpenSocial feature), they will be prompted to give permission to access social data. If a gadget is released without social features and is upgraded, users will be prompted for access within the gadget when the new version is first rendered.
When OpenSocial gadgets are available to all iGoogle users, users must grant permission before gadgets are allowed access to social data. For sandbox users, we want to ease development, so sandbox gadgets are allowed access to social data before confirmation.
Developers, this is important, so take note. If users deny access to social data, the gadget should have a good error message and graceful fallback UI.
Check for the ability to access social data with this snippet of code:
gadgets.util.hasFeature("opensocial-0.8")
and fall back gracefully if permission is not granted.
If you have any questions, please join us in the iGoogle Developer Forum.
Subscribe to:
Posts (Atom)