StickiWidgets

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.

The core values and principles of Agile Software Development are a perfect fit for widgets development. Due to the nature of the relatively small widget projects and ever changing market environments, third party APIs, services and platforms, one must be agile and ready to adapt.

Manifesto for Agile Software Development - 4 values of Agile Software Development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

However, keep in mind that while preference and emphasis is on the items on the left there is still value in the items on the right.

Manifesto for Agile Software Development - 12 Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

More information at AgileManifesto.org and AgileAlliance.org