Web 2.0 Designers

1. OpenSocial only offers the lowest common denominator, not the full richness of each social networking platform.  While application developers can create apps using the OpenSocial model and they will be able to run on dozens of different social networking sites, OpenSocial can’t help you leverage the full capabilities of the site it runs on.  Social networking site APIs aren’t anywhere as complex as say, the Windows APIs, but we’ve seen this before with platforms such as Java, where the development model can’t support the full capabilities of the underlying operating systems.  Like Java, write once, test everywhere is the name of the game for OpenSocial and while economies in this model certainly exist, a single universal widget model tends to discourage product differentiation in favor of broad distribution.  This means to get at the full richness of the underlying platform and create a competitive product, you have do custom coding for that site and you’ve just broken the reason to use a common application model.
2. OpenSocial is largely based on open standards and there’s only minor developer lock-in.  Overall, it actually seems pretty safe to do a lot of your social application development using OpenSocial.  It uses the essential browser open standards of XML, HTML, Javascript, and the data formats are all ATOM and RESTful/WOA.  You can even host Flash content and functionality inside the OpenSocial application as long as you don’t break the rules.  Finally, most of the really popular development platforms, including Ruby on Rails, can support the server-side API.  All in all, Google seems to have stuck to a fairly open and non-proprietary model including avoiding crufty proprietary markup.  OpenSocial documentation and sample code all uses the Creative Commons licensing and Apache 2.0, and the OpenSocial FAQ says everything will be open sourced at some point.  Kudos for this open stance, Google.
3. OpenSocial is a real doorway to social networking data portability as well as potential security holes. A site that supports OpenSocial applications provides that application with all the people data in that user’s account.  Their own info as well as their friends.  This can be used to export user’s social data from sites that don’t support themselves directly and it could even be used to knit together a person’s social data across other social sites that support OpenSocial, with properly designed 3rd party apps.  But it also opens the door to security problems and expect to see that security, cross-site scripting, and exploits become an issue over time, as it always does when platforms open up to the rest of the world. Update: Michael Arrington has reported that the first OpenSocial app has now been hacked.
4. OpenSocial is simple and straightforward but also capable of developing full-blown, rich Internet applications.  And without server-side infrastructure.  Developers can simply innovate with a few bits of markup and procedural code and drop it into the OpenSocial ecosystem and leverage the massive audiences and scalable infrastructure of OpenSocial compliant sites.  OpenSocial even supports powerful interactive Web user interface models like Ajax explicitly.  Like we saw last year, with the new productivity-oriented Web development platforms, this will change what’s possible while also creating mountains and mountains of relatively useless, uninteresting apps amongst a few real gems.  But a lot more wildflowers will bloom on the OpenSocial landscape and some will likely rise up and show us how useful these applications can be.
5. OpenSocial is from Google and excessive philanthropy should not be expected.  Google almost certainly thinks OpenSocial will ultimately be very good for Google, if not outright bad for a few others (probably Facebook).  While the openness is encouraging, if OpenSocial is successful, Google has a plan to make that success work for it. Those plans may not always be to the benefit of everyone playing under the OpenSocial umbrella.  User beware.
6. A new era in competency in social software is being ushered in by models like OpenSocial.  A lot more social applications are being created because of open social platforms have become so popular.  But building successful social applications is a lot different prospect from building traditional business and consumer applications.  Expect that many developers and software designers will fail to build applications successfully until we learn that a different focus and way of thinking is required.  I’ve written before about the basic rules for building good social applications, but these are just the beginning.  Understanding people is the key to building effective social networking applications, and that is often the hardest thing for us in an industry obsessed with connecting with each other via 1s and 0s.

What else do we need to know about Google’s OpenSocial?  Put your ideas in comments.

If you're new here, you may want to subscribe to our RSS feed. Thanks for visiting!

There is a lot of hype surrounding the new generation of websites that are emerging. Collectively they are labelled web 2.0 applications.

How many times have you been messing with your WordPress install and wished that you could add just a touch more flexibility to the whole thing? I mean, WordPress is fairly robust and has a ton of features, but inevitably you’ll want something that it doesn’t offer right out of the box. One of the best examples of this is the WordPress sidebar. The sidebar has been a source of frustration for WordPress users because of the lack of customization available - meaning that once you call < ?php get_sidebar(); ?> you pretty much have to stick with whatever it spits out. Well no more! I’m about to show you how to call in a different sidebar (or any other file for that matter) using simple PHP includes.

PHP is a next generation invention.

At the dawn of the world wide web, static content was king. The expense of hosting—not to mention programming for—dynamic content put it out of reach for all but the largest companies. Even though maintaining static content was tedious and time-consuming, it was often the only viable option.

Fast forward a decade, and the picture’s completely different:

« Previous Page