We have now finished the migration of the Platform in production to OpenSocial v0.8. We'd like to thank the developers who helped test 0.8 while it was in beta, as well as those who provided us detailed feedback on the scaling issues we encountered in production last week. We are looking forward to a new wave of application and feature launches on the 0.8 platform. We recently posted an entry highlighting all of the key features of 0.8, the RESTful API being the most significant addition to this standard. Apart from the tremendous contributions to product testing by our QA team and third party developers, our team has also tested 0.8 against Google's OpenSocial compliance application and we're happy to say that it is compliant with most of the recommended test cases.

Additionally, our platform team has been working diligently at responding to your feature requests. This release brought other features into production, some of which had been "in the wild" on our beta servers for about a month and which some developers have already started using:

1. A RESTful API for accessing historical statistics for your apps
2. More attributes in the Person.Field data object
3. A Photo Upload API, auto documented at http://api.hi5.com
4. Status update API that allows you to set the user status 

In line with our earlier policies regarding notifications, we are also instituting similar dynamic limits on the total number of emails that an application can send per day. We did this because after adding notifications limits, we saw an improvement in the perception of applications among our users. We will continue to look into ways of striking a balance between user experience for our members and third party developer needs.

If you'd like to ask questions or leave us comments, feel free to send us an email at platform-help@hi5.com, to post on the online forum and to participate in discussions with other developers on the IRC channel. We're dedicated to continuing our efforts to enhance the platform for our members and partners.

Reaching a Wider Audience: Community-based Translations for Applications

Hi5 has a large audience in Spanish-speaking markets, Thailand, Romania, Portugal, and many other countries. How much more popular would your application be if it supported Spanish, Thai, Romanian, Portuguese and 50 other languages?

To simplify the translation process for applications, hi5 has connected its OpenSocial development platform to its community-based translation system. For the past six months hi5 has been building teams and language tools to translate the hi5 website into 25+ new languages; now, that same community and toolset is available to OpenSocial developers to translate the applications.

Translations are performed only by users of the application who are members of the hi5 translation team for that language. In addition, developers have complete control over all translations translated text within the system, and may delegate this editorial responsibility to specific translators or reviewers.

Translators have access to the hi5 language tools on the application canvas page. Translations take place in context, directly adjacent to the functioning application.

Developers can preview the translations, perform any required edits, and then publish, making the translation available to all hi5 members. Furthermore, as a developer, you can download the translated text for deployment in any OpenSocial compliant container.

Getting Started

The translation process begins by internationalizing (i18n) the application. The OpenSocial specification is i18n-ready and hi5 provides Internationalization guidelines to help you with this step.

Once the application is internationalized, developers will Reload the application and select to Receive hi5 translations. Developers need to set the application's Default Locale to indicate the language used in the default message bundle. This loads the application's text into the translation system and makes it available to the translators who use the application.

Although the translation teams are most accustomed to translating from English to other languages, as is the case on the hi5 website, the translation tool for applications supports translation from any source language as defined in the hi5 system. This permits maximum flexibility in development and translation.

A new tab has been added to the Development Console, showing the translators' progress. As translations become approved by the community, those languages will appear atop the list with messages indicating New Translations available for download. Exporting the translated message bundle, updating the app xml and reloading the app publishes the new translations.

Additional Resources

For more information on the translation system and processes now available to you, please refer to the following documents:

• Developer Guidelines for Translating hi5 Applications - provides an overview of the translation program for OpenSocial applications.
• Linguist Guidelines for hi5 Applications - explains the role of the hi5 Linguist in hi5's Volunteer Translation program.
• Linguist Instructions for Translating hi5 Applications - provides how-to instructions for Linguists assigned to a hi5 application.
• hi5's Internationalization Guidelines - the internationalization section of the hi5 Developer wiki.
• OpenSocial Specificiations - Google's OpenSocial home page.

Following close behind the release of the OpenSocial 0.8 specification two months ago, we have been hard at work implementing it, and are happy to announce that a beta release is now available to developers. We will be rolling this out to production in the first week of September and would like to give developers ample opportunity to test out our latest implementation thoroughly. The 0.8 version of the specification is completely backwards compatible and we expect that all applications developed on 0.7 will continue to work after the migration.

Possibly the most exciting development in 0.8 is that containers are now required to implement a REST based API according to the RESTful API specification. We hope our implementation will enable developers to build richer server-side, mobile and desktop applications. The complete 0.8 version specification and Release Notes are also available on code.google.com and are a useful read for OpenSocial developers.

To test your application on 0.8, please login to betasandbox.hi5.com with your hi5 account and create an application on the developer console --- you can use your existing application or write a new one. Applications running on betasandbox will access the 0.8 API.

If you find issues please create a ticket using the version "Beta 0.8" in the Developer Center. Please let us know at platform-help@hi5.com if you have any questions.

The Statistics API that we announced two weeks ago is available on sandbox. Please use the endpoints described in the earlier post, prefixed with http://sandbox.hi5.com/rest. For example, for the metrics/daily endpoint, you would enter http://sandbox.hi5.com/rest/metrics/daily?<parameters>.

We look forward to seeing the API being used. Feel free to send us feedback -- we will also propose this shortly as an addition to the OpenSocial REST API specification which will present the community with an additional forum to discuss the API.

The hi5.template library is a browser side, Javascript library which enables you to fuse Javascript data and logic into your HTML. It simplifies writing localized apps by providing a message resource tag:

<os:message key=”resource” />

which eliminates the need to build messages and HTML with Javascript. To ease transitioning to language resource files, you can provide the message resource directly in the message tag. For example:

<os:message key=”received_gift” gift=”pizza” friend=”Joe”>You received a ${gift} from ${friend}</os:message>

Also, using the hi5.template library allow future compatibility with our user generated content inline-translation tool. The template is straightforward, with only a few conventions:

1. ${} for variable substitution
2. <for-each> for iteration
3. <if>/<else> for conditional logic, and
4. <os:message> for gadget resource localization.

There is also a <set> tag for storing the output of tags, and <os:name> and <os:profile-pic> convenience tags.

Check out the wiki for more details on the template library: where to download it, how to specify it within your application and the format for various tags.

The hi5 Platform Team is continuing to make changes that help developers better understand the growth trends of their products. To this end, we are making application statistics accessible via the API server. Before making this public, we would like your feedback on the design of the API. Please read through these specs and let us know what you think of them!

Developers will have to authenticate themselves by creating an authToken — any of the developer accounts associated with an application can be used to access the stats for an application. Statistics can be generated for all or some of the applications owned by the developer account requesting the data.

The API has three endpoints:

1. metrics/daily: These are daily stats, not uniq'ed per user. You can query the data for a range of dates, not exceeding 30 days. Requests for more than 30 days will be truncated to 30 days, starting at the start date.
2. metrics/dailyuniques: These are the same type of stats as returned by metrics/daily, but accounting for uniques. This means that if a single user views a canvas page on your application more than once, it will count as just 1 unique canvas page view in these metrics.
3. metrics/total: These are total stats calculated for the applications, aggregated since your application launched.

The input parameters are supplied in the URL and the parameters and the acceptable values are all case sensitive. Only the Hi5AuthToken parameter is required

Parameters

1. metric: If this parameter is not specified, then all available metrics are displayed. You can request the following metrics with this parameter:
   1. install: Total number of installs
   2. remove: Total number of removes. You will have to subtract this from the total number of installs to get the net installs of your application for the applicable time period.
   3. view_profile: Calls to the profile module
   4. preview: Calls to the preview module
   5. canvas: Calls to the canvas module
   6. block: Block requests generated in response to emails and notifications generated by your application_,_ and on the My Applications page.
   7. api_request: API requests sent to our API servers by your application
   8. report_abuse: Notifications generated by your application marked as spam
   9. activity_requested: Requests to generate a Friend Update
   10. activity_sent: Friend Update requests fulfilled
   11. invite_requested: Friend Invite requests generated. Note that this counts a request containing multiple friends as one request
   12. invite_sent: Friend Invite requests fulfilled
   13. notification_requested: Notification API requests made to the API servers
   14. notification_sent: Notification API requests fulfilled. Note that when an API request is fulfilled, not all the recipients in the API request might receive the request, as some might already have received the limit of per-recipient notifications allowed.
   15. all: All of the above
2. context: The context breaks up each statistic in the metric parameter based on the origin of the corresponding action. Note that not all contexts are valid for all actions — for example, blocks can only occur in the invite, myapps and notification contexts, by definition. If context is not specified then breakdown by context will not be displayed. The possible values of context are:
   1. activity_stream: From all links in a Friend Update, if that link is on a user's home page, or from a Friend Update's "More" link if the Friend Update is being viewed on the logged-in user's or someone else's profile.
   2. apphome_friend: From the My Applications page of the currently logged-in user, when the user clicks on a recommended application (currently, applications installed by a user's friends)
   3. apphome_owner: From the My Applications page of the currently logged-in user, when the user clicks on one of their own applications (currently, user's recent applications)
   4. gallery: From the hi5 Application Gallery
   5. homepage: From the homepage applications box at the top right of the page
   6. invite: From a friend invite
   7. myapps: From the Manage Applications page
   8. notification: From a notification
   9. other_profile: From the profile of someone other than the currently logged-in user
   10. own_profile: From the profile of the currently logged-in user
   11. profilenav: From the View More link on the Profile module, and from the Applications drop down in the navigation bar at the top of the Profile page
   12. unknown: From an unknown context, usually generated when the user comes from a link placed in a Profile module or Friend Update by the application (Note that this number is inflated because invites are not being tracked correctly; this will be fixed soon.)
   13. all: All the contexts applicable to a given action
3. start and end: The start and end dates, respectively, in YYYY-MM-DD format. The dates must be "consistent," that is, the end date cannot precede the start date, and they must both be valid calendar dates. A range greater than 30 days generates an error. If no dates are specified then data for the latest available timestamp (typically, for "yesterday") is displayed.
4. Hi5AuthToken: The auth token generated via the REST API for your API key and login information.
5. api_key: The acceptable values are the API keys of the applications owned by the developer making the request; API keys for other applications will generate an error and return no statistics. To return statistics for more than one application (but not all applications) owned by you, specify the api_key parameter multiple times. If no api_key is specified then the one that was used to generate the auth token will be used.

To begin, we will not rate limit this API and expect that the volume will be no higher than once a day per application. Improper use of this API will lead to the offending API keys being blocked from access to this functionality.

We look forward to your feedback. Thanks!

The hi5 Platform Team will be holding Office Hours on the hi5dev IRC channel, twice a week, starting this Thursday. The hours are as follows (all times in PST, which is GMT-7 or GMT-8, depending on the time of the year):

• Tuesdays, 9am - 11am
• Thursdays, 1pm - 3pm

We are very grateful to developers for the lightning-fast feedback we got via this channel during the early days of the platform, and hope to maintain that spirit of interactiveness as we continue to grow. Please let us know if you have other time preferences and we can consider refining this as we go along.

Instructions for access to the hi5dev channel are available at the hi5 Developer Center. During these hours, at least one member from the team will be logged into the chat room. The Tuesday morning hours are to allow developers from Asia to be able to correspond with us at a time that's reasonable on both sides of the globe.

We were inspired to do this by a similar idea that the Google OpenSocial team had announced quite a while ago --- we would like to give credit where its due.

One of the attractive features of the hi5 platform is the many viral channels we've made available to allow developers to advertise their applications to our members. The unprecedented success of our platform has demanded that we keep an eye on the flow of notifications and invites to make sure that this opportunity is not exploited by a minority of abusers, thus degrading the experience for our members and making the service unusable for the developer community as a whole. In other words, we are opposed to having spam on hi5; moreover, a flood of irrelevant or misleading notifications drowns out those  that come from useful and legitimate applications.

To manage this ecosystem in as efficient a manner as possible, we are introducing a new automated system that will implement notification quotas. To date, we have been moving these switches manually but the communication overhead has been too high. The automated quotas will respond daily to abuse report rates and usage. Specifically, the fewer times our members mark a notification as spam and the more they click through to engage with the application, the more notifications your applications will be able to send.

We think our automated system will help the platform respond in the most timely manner to positive user perceptions of applications and notifications. Very soon, developers will be informed via the response to (rejected) API requests for sending notifications if they are in violation of quotas. We also expect soon to expose the actual quotas on a daily basis via the Developer Console.

If you have any questions about the quota system or suggestions on how else we can support your apps on hi5 while also best serving our membership, please get in touch with us via email, our discussion forums or the wiki --- all contact addresses are available on http://developer.hi5.com.

Google has posted a survey asking developers to give feedback on the OpenSocial ecosystem. We would appreciate it if you could take some time to let us and Google know what has been working (or not) for you as a developer on OpenSocial and how we can improve the experience. Specifically, please select your favored locations for holding new hackathons, and any comments you have on features and functionality.

Thanks for participating. As always, feel free to email the hi5 Platform Team as well with any questions and suggestions you have!