Michael asked a cool question in his blog about gadgets versus portlets.
My response is in Michael’s blog – I replicate it here as well.
Michael – Excellent opening statement. My response is less technical than Antranig’s – I treat “gadget” as a Google gadget – not a generic gadget.
I have been working with Java Portlets (JSR_168) and WSRP (Web Services for Remote Portlets) now for a long time – trying to use them and then finding them not well suited for many applications and then trying to get involved in improving them.
I think that architecturally Google Gadgets, Facebook applications, and remote portlets are *exactly the same thing*. Effectively they all describe a way to build a UI out of rectangles where the rectangles come from various sources and servers and can be written in very different languages.
The only thing that Facebook and Google has added to the discussion is that they have built their standards for integrating “rectangles” in such a way that many people can implement them. The formal standards like JSR-168 and WSRP are aimed at “Enterprise Developers” who are being paid to do this stuff – and it it takes a month to figure out how to do a “hello world” application – there is no harm – because everyone is getting paid.
For Google and Facebook – they need people to use their stuff and quickly – because few will be paid to build gadgets or Facebook applications – mostly it will be people who have some cool idea and want to join the cloud. This means that Google and Facebook give us a rich but simple interface focused on using REST – and in particular focused on making the first few steps really really easy.
Easy and loosely coupled also has a cost – performance tuning can be harder and you lose control of your data. You lose control of the service level agreements – you lose control of privacy – you lose control over a lot of things – but you gain vast richness.
So to summarize the first part of my comments – I see Google Gadgets and Facebook applications solving a problem that portlets and WSRP could not solve in a way that is satisfactory to the market. Google and FB step into a vacuum – provide a crude but effective solution and we all take off running and having fun – and doing things we wished were possible a long time ago.
The second part of this is about IMS Tool Interoperability. Eventually we will need a way of mashing up functionality from many sources without compromising performance, functionality, privacy, or quality. IMS Tool Interoperability *wants* to solve this problem and we are making slow progress on it – I wish I had five programmers I could just tell what to do next on IMS TI – then we would make some progress.
The problem is that this is not as simple as mashing up RSS feeds for our own newspaper. The simple example (moving towards Antranig’s comments above) is when I want to outsource both my content file storage and my testing engine – i.e. neither run in my enterprise LMS.
Lets say for example, I am using Microsoft SharePoint for my file hosting, Sakai for my enterprise LMS and grading, and QuestionMark for my assessment hosting. I am authoring a test question and want to add an image to the question – I click on a button in my question authoring environment and the application needs to bring up a list of files from SharePoint for me to choose from in the QuestionMark UI. Then when the students take the tests – the grades need to end up in Sakai. And I am just a simple faculty member – I want this to just *happen*.
The sad thing is that this is all pretty technically feasible. But no standards exist for it and no one is willing to be the guinea pig for the application and no one seems willing to work with unfinished standards and iteratively evolve them to get to the point where real work can be done.
The good news is that organizations with money to burn and well-funded teams looking at how to make more money in the future are looking at this (i.e. Google and Facebook) – we (the teaching and learning market) are not part of their thinking and don’t get much influence in where they are going. But for me – at least there is *some* investment in what will be the future service oriented architecture for learning.
I am sitting back and watching with some glee as Google and FB beat each other up trying to out-innovate each other for the next few years – my feeling is that they will end up with an 80% solution and then for teaching and learning applications, we can build on their technical design and user interaction patterns.
I think that a company could make a *lot* of money if they decided to get ahead of this and add T/L innovations to the FB/Gadget world. It would not be that hard – Google and FB are solving all of the provisioning, markup, authentication, and sand-boxing problems – we just need to add some standards for content and authorization.
But the road ahead is not simple nor trivial – there will need to be a several year investment in solutions that will need to be thrown away – given that teaching and learning cannot affect Google or Facebook’s direction – we are at their mercy.
But this is how innovators work – they take risk trying to find their way into a market that does not yet exist and when it initially does exist – it will not be too lucrative. But sometime later – it will replace the old market and become the only market – then all of the former market leaders kick themselves and ask “Damn, why didn’t we think of that?”.
Of course the reality is that those former market leaders were probably told repeatedly by members of their organizations where the future was going – but these future thinkers in the market leading organizations are told – “This all sounds interesting, but how will your idea increase next quarter’s revenues by 10%? Unless we can find a way to affect revenue next quarter – we will sit back and wait until someone else figures this out and then jump on as a late adopter.”.
Readers should Google for the “The Innovator’s Dilemma” from Clayton Christensen and read it cover to cover – one of my favourite books.
I also wrote about this in a (soon to be published) Journal article in June 2007 – an excerpt from that article is up on my blog:
Functionality Mashup – FaceBook APIs – Here comes Google OpenSocial