Social Media Design: Best Practices To Build Your First Open Social Widget
OpenSocial is a set of common APIs for building social applications across many websites which in the end makes it very easy for a large number of individuals to start developing their own social web applications.
Photo credit: UK Open University - edited by Robin Good
Three characterizing traits make OpenSocial such a very compelling proposition for would-be new social web developers:
a) Developers only need to learn the OpenSocial APIs in order to create web apps that work with any OpenSocial-enabled website.
b) Developers have a broad distribution network to reach users because any website can easily implement OpenSocial.
c) Websites also benefit by engaging a much larger pool of third-party developers than they could without a standard set of APIs.
But how difficult is it for you to develop social apps using OpenSocial?
Inside OpenSocial web apps it is also possible to embed Flash content and to program them so that they can fully interact with outside third-party applications while using fully standard web protocols.
Social web apps can be hosted directly by Google or on your own servers.
The only other key requirements are to have some good ideas, and, if you can, to follow as much as possible some of the following Google-suggested best practices.
Intro by Robin Good
Social Design Best Practices
If you're new to developing social applications, it can be difficult to immediately grasp how good applications facilitate fun and meaningful social experiences.
To accelerate your learning, we've come up with a list of a few light-hearted recommendations around building good social applications.
Not all of these "best practices" are necessary in every case, but they might spark thoughts about finding new users, keeping old ones, and leveraging the social graph for fresh content and viral spread.
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.
4) Make It Dynamic
Good social applications aren't only static badges of self expression; they dynamically change to provide an interesting experience across sessions.
Change can be derived from the social graph as friends interact with the application to change its state. Change can also occur as the application internally generates new content. In both cases, the day-to-day changes can help to keep an application interesting and desired over time.
5) Expose Friend Activity
A particularly easy way to make an application dynamic and social is to record and present the activities of friends who are using the application. This could be thought of as an application-specific activity stream in which the news and updates of friends are always presented in the context of the application itself.
From these activities, users become more aware of how others are using the application, driving increased use and change.
6) Browse the Graph
Exposing the activities of friends is one method among many for passively browsing the social graph.
Users are often interested in low-effort interactions like viewing a friend's most recent activity, comparing content and choices, and indirectly interacting through their own activity.
In supporting this style of interactions, it's essential to make it easy to browse what friends are doing. This is often achieved by linking names to a user's container profile or even creating application-specific user profiles which provide an overview of a user's activity and content.
Browsing the graph can also certainly extend beyond just friends. In some circumstances, it can be interesting to see and interact friends-of-friends, especially when drawn together by shared interests.
Creating ways for a user to grow his/her social circle adds value to an application from the user's perspective by unearthing opportunities for new friends and content.
7) Drive Communication
Browsing friends' activities and content often flows well into conversation, creating an opportunity to develop deeper social interaction.
In places where communication can happen, it's good practice to make the option explicitly available. This can be done in a more persistent, public manner through a comment system or sharing wall. It can also be done in private by linking into a container's messaging, email or instant messaging systems, or even through an internal communication layer like pokes or other simple gestures and messages.
8) Build Communities
A container's entire social graph is often huge, and even a user's immediate social circle might be too large for a user to easily track.
By growing smaller communities and making them accessible, an application can provide rich and interesting functionality that enhances the overall social experience.
There are three categories of communities which applications commonly build and utilize:
- Grouped relationships (e.g. best friends, family, classmates, etc.)
- Shared interests among a user's immediate social circle.
- Shared interests among the entire social graph.
9) Solve Real World Tasks
Self expression and communication are often fun and entertaining alone, but OpenSocial is also a platform that can be leveraged to solve real world tasks where the social graph assists us in making decisions.
For example, while some might be prone to grab a book at random off the shelf, there are many who appreciate a good recommendation from a friend.
With a variety of possibilities in entertainment and interests, it can be useful to facilitate meetings, purchases, recommendations, information management and learning to create a richer, more lasting experience across your application.
Google Open Social Developers and Partners Speak at CampFire One
Videos from Google Campfire One launch as well as interviews with some of its partners: Slide, Ning, Hi5, Plaxo, Flixster, iLike, Salesforce, LinkedIn, RockYou and more.
OpenSocialStuff.com: Community for Google's OpenSocial Platform - Developers, Applications and More
Google Editors -
Original content written by Google Editors for Google Code and first published online as "Social Design Best Practices" in November 2007. Original content published under a Creative Commons Attribution 2.5 License.
Reference: Google Code [ Read more ]
blog comments powered by Disqus