StickiWidgets

GolfLink.com

Not to be out done by the recent press release of RockYou’s $35M round of funding, KickApps and Clearspring announces a partnership to “ACCELERATE
WIDGET CREATION, DISTRIBUTION AND ADVERTISING.”

We’ve not seen any of the KickApps Widget Studio beta or features that spawn out of this partnership, so this is a very interesting development and we’ll keep an eye on it.

KICKAPPS AND CLEARSPRING PARTNER TO
ACCELERATE WIDGET CREATION, DISTRIBUTION AND ADVERTISING

Companies Collaborate on Advancing KickApps’ WidgeAD™ Format and Clearspring’s Widget Ad Network

New York and Mc Lean, VA, June 10, 2008 — KickApps, the leading on demand social media platform, and Clearspring Technologies Inc., the world’s largest widget syndication and tracking service, today announced a strategic partnership to further accelerate widget usage and monetization. Under the agreement, Clearspring will promote KickApps’ new WYSIWYG Widget Studio (currently in beta), a self-service widget-authoring environment to the Clearspring user base. This will enable Clearspring customers to easily build their own rich-media and interactive widgets with tremendous ease. KickApps will use Clearspring’s powerful distribution and tracking services to provide one-click distribution and in-depth analytics to anyone using the KickApps Platform.

more…

Clearspring released their early-access In-Widget Services API a few weeks ago. The initial release only supports Flash ActionScript 2, but ActionScript 3 and JavaScript are planned for later versions. These APIs were previously only available to Clearspring’s internal studio team.

In-Widget Services

Clearspring provides a number of APIs that you can use from within your widget. These APIs allow you to do things like invoke our viral sharing services programmatically, get information on the viewer of your widget, access properties of the widget and where it is located, and more.

The APIs are divided into three logical categories, each with a number of properties and functions:

• Context
• Menu
• Track

The In-Widget Services API is now available for your widget if it is registered with the Clearspring platform.

What really makes this interesting is now you will have to ability to get information about your widget that you couldn’t get before. This information can then be passed back to your own server side services powering your widget. The widget can now be aware of its location and become an intelligent app. You’re no longer limited to “dumb” badges and widgets.

context.DOMAIN

The domain (if known) in which the running widget is embedded. If domain is unknown, DOMAIN will be undefined.

context.user.geo.getCountry

Returns the user’s ISO-3166 country code (e.g., “US”).

For example, with context.DOMAIN you will be able to determine if your widget is placed at myspace.com or some other domain. Pass this information back to your server and display appropriate features to the end-users. If the destination site has APIs, you could even display a friends list or other details the platform provides. There is no technical reason why widgets can’t access the social graph and become a social apps, as long as the platforms open up their systems and policies.

Another example is access to the country location of the user. This can obviously be used to customize your widget for specific users based on their location, culture, language, localized services, etc.

These are just couple of methods available. See the documentation for the complete list of available services and methods.

Widgets can and will become more intelligent as standards are agreed upon and platforms open up. They will become applications much like Facebook Apps. While they may not be as fully integrated as a platform specific application (though they can come close), they will be more portable and flexible than a platform app.

A few of the items were already available to developers who knew what they were doing, but Clearspring extends the available information and makes it much easier for developers. Clearspring is leading the way in deploying a powerful widget platform to go beyond what you typically see right now. We just need developers to start innovating and taking advantage of this. Much of the focus and news lately has been on Facebook Apps and OpenSocial, but widgets are still a very viable and powerful tool.

Rather than trying to define a widget or an app, we should be embracing all methods of development and approaching it with the idea that the best solution is the one that is right for your business.

And, we should stop thinking of widgets as just badges. They can and will be “Intelligent Widget Apps”.

We came across the Google best practices via Sexy Widget. And, as with the previous post (5 Questions to Ask When Selecting a Widget Platform), here are the first three items. Visit Google for the complete list.

Google – Social Design Best Practices

1. Engage Quickly

Across containers, there’s a common tendency for a user to take a chance on an unknown application, and shortly thereafter remove it if no immediate value is found. The lesson to be learned from this interaction is that first impressions really do matter, and it’s necessary to engage the user quickly before attention is lost. To this end, we suggest you focus on the 30-second experience; before distracting the user with expert features or sending invites, slow down and give the user a simpler taste of what your application is about. Try the following:

• Show value and identity by making the purpose and core features of your application absolutely clear.
• Populate the application with fun or interesting content (especially content from friends) that makes for a browse-friendly experience.
• Make it easy for the user to add content, change settings and feel ownership of the application. This increases a user’s desire to keep the application on his/her profile.

2. Mimic Look and Feel

Across OpenSocial containers there can be a lot of variation in the look and feel of pages and profiles. When designing your application, it can help to attempt consistency with the container UI by using similar fonts, tabs and buttons.

In cases where applications strive for stronger identity, it can be good to create a UI look and feel which is slightly distinct but still aesthetically strong to play on a user’s tastes and need for self expression.

3. Enable Self Expression

The profile page in a container is often a representation of a user’s identity, interests and tastes. From the perspective of the owner, it’s a means for self expression and a starting point for exploring the social graph. From the perspective of viewers, it’s a place to learn, communicate, and find shared interests. Applications best take advantage of the profile by enabling self expression through common interests around entertainment, brands and groups. Self expression is also enabled through specific forms of communication like gestures and gifts or conversations around special topics.

Don’t forget our own 10 Things to Consider When Building Widgets.

If anyone is interested in Joost Developer Days, check below for some information from the Joost Community Manager.

Unfortunately, there’s no date scheduled for Los Angeles so we won’t be attending.

——————————————

We’re delighted to invite you to Joost’s first developer days, a chance for you to meet some of our developers, get some tips for building widgets for the http://www.joost.com platform and share your own experiences in building them.

Who:
These workshops are aimed at developers with at least basic knowledge of html and javascript

What:

• a (free) lunch
• short presentations from the widgets team at Joost, including an introduction to building widgets, and an update on widget features in new releases
• a preview of our first commercial widget
• the opportunity to work on a widget or two yourself or use the workshops to get hands-on help for widgets you’ve started to develop
• we’ll finish up with a drink or two and some free stuff to take away

Where and when:

• initially in three locations: London, Amsterdam and New York
• London (Covent Garden) – 1pm – 6pm – Friday 16th November
• Amsterdam (Central location) – 1pm – 6pm – Saturday 1st December
• New York (Financial District) – 12pm – 5pm – Friday 7th December

We expect places to fill quickly so please RSVP (to dev-workshop@joost.com ) as soon as possible, and let us know which Developer Day you would like to attend and whether you would like to bring a friend or colleague. We’ll then send you more details on the location and format of the day. You may have to go on a waiting list, but we’ll let you know if that happens.

Even if you can’t make the above dates or venues, please let us know if you’re interested in coming to a similar event next year and which location would be best for you.

Please note that some of the presentations will be filmed and we’ll be uploading them onto a special Developer Channel in Joost later in the year.