StickiWidgets

Lawrence has a great post over at Sexy Widget on “Building a Web Service in a Distributed World.” While he raises more questions than answers, he does provide details and a viewpoint based on his experiences and his company, RateItAll.com. We agree that there isn’t a one size fits all solution and that each company will have to look hard to see what model fits their business.

Here’s a excerpt from the post to wet your appetite.

So what’s the right model? Fully distributed like Zynga or a focus on a core community with only marginal outreach to the SNS like Yelp? And how should you manage your various user bases? Should a user on one SNS be able to interact with a user of another SNS via your app (Zynga)? Or should the user bases be kept separate (iLike and Flixster)? And what should be the ultimate goal of your distributed business? Reach or feature ownership? And what brings a higher chance of success porting an existing web service to the social networks (Flixster), or building something native (Renkoo)?

It’s unlikely that one size will fit all. But I have come to some conclusions in regards to my own company.

It’s called Hub and Spoke.

Head on over to read the entire post.

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.

Here is a list of 10 things to consider when building widgets. The items are not in any particular order (hence no numbering) and it does not necessarily mean you have to meet each item. However, we do believe that each item should be considered and conscious decisions should be made regarding each point. Each widget, project and company has its own set of requirements and time lines, so as long as though was put into the process, a widget can meet your goal without delivering on every element listed.

• Compelling content for reader and publisher

  If the content is not interesting for anyone, then why would anyone bother to use or spread it? It’s not just about RSS feeds and cute badges, the possibilities are endless.

• Remember it’s a three way relationship; engage the reader, benefit the publisher and brand yourself

  Many forget that this is a complex relationship. Not only do you have to brand yourself through the widget, but you also have to give a reason for a publisher to use the widget. Are they getting cool content, new features or something unique? What do the readers get out of this?

• Customizations, the more the better

  Beyond branding for yourself, keep in mind that widgets live outside your domain. This means that the more customizations available the more seamless publishers can integrate the widget with their own site, brand and design. Whether it be size, color or headers, flexibility is the key.

• Distribution mechanism, embeddable everywhere

  Why limit your audience? As technology barriers are lowered, more and more people become potential “publishers.” This can be anyone with a profile page, blog or full fledge site.

• Internalize functions, keep as much in the widget as possible

  While your brand, product and site are important, so is the publisher’s. It’s a fine line and a balancing act, but if you can strike a mutually beneficial feature set that is able to keep the readers attached to the publisher while driving traffic home as needed, then you have a potentially successful widget.

• Remote updates

  The ability to update widgets in the wild remotely is important. Widgets must be able to evolve as conditions change and if you are not able to push updates remotely, you risk hurting your brand with outdated or broken widgets.

• Performance

  Everyone is vying for everyone’s time. The web is no exception. The widget must perform without delay for both the reader and the publisher. The reader will not wait for content and the publisher will not tolerate a widget that bogs down their entire page.

• Tracking and analytics

  You do know where your widgets are and how they’re doing, right?

• Business and marketing goals

  What was the purpose for the widget? If you didn’t know that to begin with, how can you start to measure the usefulness or success of the widget? Or, even build a widget in the first place…

• Lastly, don’t forget about the users

  We mentioned this earlier, but it’s worth stating again. Don’t forget about the users. In this case, the user is anyone that will have anything to do with the widget, publishers and readers.