Monday, July 21, 2008

OpenSocial as an alternative to JSR 168

OpenSocial came onto the scene at the end of 2007 but until now I hadn't got around to delving into it and I thought it was about time.

My first observation was that its name is actually a bit of a misnomer. I expected data portability for social data, but in fact this is not what OpenSocial is about, it is instead more akin to "OpenWidget" or "OpenGadget" (as many others have pointed out). This however is not a bad thing, it is just different than what I was expecting.

OpenSocial is the expansion of Google Gadgets across platforms, with the view being that once an OpenSocial Gadget had been developed once and used on one site that it would be able to run on another social networking site and easily access friends lists and other social information on that site due to the common API that OpenSocial mandates. If this all sounds very similar to JSR 168 / 286 and the concept of Portlets then you would not be mistaken (for more on JSR 168 see my earlier post titled 'Are Portal Servers dead?'). Similarly, Netvibes tried to get some standardisation in this space with their Universal Widget API (UWA) standard but this hasn't got much (any?) traction.

I believe OpenSocial has a lot more hope than JSR 168 and other similar efforts, largely due to the weight of Google behind it, but also due to some other very big players signing up (i.e. MySpace, LinkedIn, Plaxo, SalesForce.com, Ning, Yahoo! and many more) and the standard appears to be rapidly evolving.

OpenSocial Gadgets can be considered the Web 2.0 equivalent of Portlets; they are typically more user centric than site centric, mashups tend to occur on the web client vs server side aggregation, and from a programming perspective it appears easier and more elegant. Coupled with a servlet backend OpenSocial Gadgets appear to be able to do everything a Portlet would usually be able to do, including Gadget-to-Gadget communication.

Just like Portlets require a Portal, OpenSocial Gadgets require an OpenSocial Gadget container. To start with I used iGoogle, which was very easy to add a new gadget to. I then decided that I would like to host my own OpenSocial Gadgets so I decided to try out an open source implementation from the Apache Software Foundation called Shindig. This is apparently used by a number of people but some reason I couldn't get it working for me; I suspect it has more to do with my PC than anything.

All in all, I think OpenSocial is definitely worth further investigation.

Key sites for further information:

Wednesday, July 16, 2008

Don't change too much at once!

I have recently been working on a large Architectural diagram that a significant number of people have been looking at on a regular basis and have followed through its evolution. I have been doing some large changes to this diagram, but rather than making them all at once I have staggered the changes across a number of versions of the diagram. There are a number of reasons I have done this, including:
  1. People often get overwhelmed if there is too much that has changed.
  2. The validity of the diagram as being a trusted reference is undermined if it is significantly changed with each release.
  3. People are often much happier if they are taken on the journey.
  4. Less noise. Fewer changes reduces the areas for debate and allows them to be rapidly addressed without the confusion of other changes.

Change can be good, but too much at once is often not a good thing. I have been treating the aforementioned diagram like a brand, whereby whilst it is possible to completely overhaul it, if you make small changes to it over time, you can take people with you rather than getting them to recognise something completely new today than what they were used to yesterday.

Whilst this may seem fairly obvious, it is a common mistake that people fall into. Changes on websites are another great example of where it is often best to do it in chunks and take people on the journey. Technology Operations teams are also often strong advocates of not doing too many changes at once, since identifying the root cause is much more troublesome if there is a lot that has occurred, and rolling back can be a major headache.

Change can occur in many different ways across all facets of People, Process & Technology, but a common theme across all of these is that change is best achieved through understanding where you are (current state), where you want to be (future state) and then planning how to get there (transition plan).

Balancing up how much change to do at any one time is an art and a lot of variables will come into play. A key variable will be the number of affected people, as will the cost of having multiple steps. Going straight from current state to future state may be feasible in some scenarios, but all I am suggesting is that in many scenarios this may cause more harm than good (and it may in fact cost significantly more due to brand damage).

Sunday, July 13, 2008

Barcamp Auckland 2 Synopsis

Yesterday I attended my first barcamp / unconference; Barcamp Auckland 2. Ludwig and his team did a superb job arranging this event. It was well organised and there were lots of great sessions that stimulated lots of thought provoking discussions.

A key aspect of barcamps is participation and it is not about 1 person presenting, but more about having discussions and debates. The agenda is created on the day with people putting topics up on the board they are keen to talk about and facilitate and it just flows from there.

For further information about barcamps / unconferences, check out:

I attended a variety of different sessions which covered topics such as IE8, OpenId, Social Graph API, Privacy, Productivity, Mobile, Predictive Markets, ...

I used Twitter as my journal for the day, and my slightly edited synopsis of each session is:

Tech Productivity
  • Music can help to focus but can also distract; familiarity plays a factor.
  • Discussion re collaborative Personal Assistant's. i.e. one PA which handles multiple people
  • Meetings should be short. Consider Taking the chairs out of the room helps to achieve this.
  • David Allen's books on productivity are being highly recommended. I must check them out
  • Interesting thought re de-prioritising emails if sent to multiple people and a response is expected. Mechanical Turk as a helper?
IE8 Action Plan
  • 1/4 of users in NZ still use IE6. Interesting stat.
  • ~30% more effort required to build for IE6, ~5% more to build for IE7.
  • There are ~18k long tail web sites in NZ that are expected to be affected by IE8, due its better adoption of standards
  • Google is MS's biggest early adopter for IE8. Beta 2 is due out in August.
  • discussion re how to get IE8 being used whilst getting rid of IE6. Ideas: disks in Herald, filler with ISP bill, break IE use on TradeMe (or more to the point, force action)
  • n-1 deployment is a consideration for many companies. This will hinder deployment of IE8 for many corporates.
Using Social Graph and OpenId to make registration easy
  • Social Graph API (rel=me) being discussed. Sounds very useful for prepopulating information.
  • Social graph API looks very very powerful.
  • Open ID adoption needs to be balanced with trust. People will still have multiple IDs. Mainly for people who live and breath the web.
  • Sxipper being suggested by a number of people as an easy way to prepopulate information and signing on
  • OpenID is largely been seen as a land grab at the moment from most providers
  • Banks not expected to use OpenID for a long time due to liability etc.
Mobile Applications
  • Symbian is 75% of Smartphone market. With recent OpenSource announcement this is big.
  • The impact of iPhone vs Symbian will be interesting to watch considering the large Symbian penetration
  • Symbian is write once, run anywhere; J2ME gr8 in concept, device fragmentation; Win Mob little market penetration; iPhone?; Android?
  • iPhone is impacting more apps being acquired for Win Mob Smartphones (i.e. it is helping drive a mindset for the public)
  • Mobile OS stats vary largely by region. High CDMA use in US is a huge factor. Asia Pacific large for Smartphones.
  • Phones in Japanese market are in fact generally pretty basic, but heavy usage and how phone is used different than other markets
Politics & Web 2.0
  • 'Click here to send email to' one click campaign marketing common. Politicians obligated to reply.
  • http://www.politicalstockmarket.co.nz/ is a New Zealand prediction market
  • Prediction markets are a bit like Wikipedia whereby the power of the crowd will normalise malicious behaviour
  • http://pulse.jimungo.com/ is home of the NZ Virtual Election
Privacy in distributed social networks
  • How do we express to a site how we want _our_ info used? Privacy = Control.
  • People don't read Terms & Conditions for web sites. A Common T's&C's framework is being mooted (c.f. Creative Commons)
  • User should be able to express in metadata form how they want their data used. Sounds a bit like a looser form of DRM (eg. robots.txt)
  • Privacy Commons Metadata could be applied to object, service or whatever
  • Leasing of information for a certain time period is being used by Fireeagle.
  • Being open about Privacy can be used as a selling point for a company as opposed to hiding what you're up to.
Mobile Web Stuff
  • Targeted txt advertising http://www.hoohaa.co.nz/
  • Different SMS providers in NZ have different levels of redundancy and performance. Ensure the provider will be able to support you.
  • A SMS message can automatically load up a page, config change settings or apps can be pushed as a SMS message.I never realised the power
  • There is a standard around concatenation of many SMS messages, and most phones handle this nicely
  • Developers are wanting the ability for certain content to be zero-rated on a mobile network and to pay the mobile provider separately
Overall, it was a great day and I will definitely be back!