I Can See Clearly Now - a comparison of widget platforms from a developer’s perspective
I was recently handed the monumental task of comparing the major players in the wonderful world of widget platforms. No mean feat, I can assure you, this turned into a mammoth undertaking of epic proportions (well, that may be stretching it a tad ;-). This is new and (relatively) unchartered territory and, although undoubtedly a new and exciting area of social media to be involved in, this meant it was tricky to nail down and collate the huge volumes of data and information into something palatable and useful that would enable us to deliver a whole host of wonderful widgets (be they destined for the web or desktop) using the right platform for the right client, and for the right price. Phew!
OK, so who are the ‘major players’ in the widget platform arena at this point in time?
With the help of Ivan Pope, of Snipperoo fame, we were able to narrow it down to a few contenders for the crown:
I looked at a number of factors from a technical perspective, ranging from analytics, API richness, deployment options, parameter types, supported technologies (Flash, Flex, ActionScript 3, HTML), hosting capabilities, as well as ’softer’ considerations such as user experience, administrative ease, support responsiveness, and widget exposure (i.e. how many ‘hosts’ we can get our widgets onto, such as iGoogle, Pageflakes, Netvibes, Facebook etc.).
To spare you the gory details, allow me cut to the chase…
The winner is…
Clearspring! And here’s why…
- Firstly, I’m really impressed with the definitions/terminology they have in place. They really seem to have thought through all this ‘widgety goodness stuff’ from a fresh perspective, and as a result, I feel they are pushing the envelope with what’s possible (for example, their concept of a widget ‘placement ID’ and widget placement awareness, is unique. What’s more,
they will be exposing this to developers through an API shortlythis data is exposed through an ‘In-Widget Service‘, which will make our widgets more flexible and able to do all manner of interesting things!). - I like the publishing process on this platform (both from a developer’s perspective and end-user perspective), the process was really clean and fuss-free. Plus, for privately hosted widgets (i.e. where a widget resides on a private space such as iGoogle) there’s no need to revisit the platform’s website just to change a parameter value, you can do it all right there on the page where the widget resides. Bonus!
- Both HTML and Flash widgets are supported (for maximum exposure, stick to Flash widgets as certain sites, notably Facebook and MySpace, don’t allow any scripting in widgets and so simply don’t permit any HTML whatsoever).
- They will be exposing more features to their (already well-documented) API in the coming weeks (I’ve been added to their beta-list and await an update in this respect with bated breath!).
- I was also pleasantly surprised to receive responses to my questions on support forums! And, from a bona-fide Clearspring employee, no less! This is reassuring to say the least!
- Hosting isn’t provided as part of the service (which, incidentally should be provided on a Utility Computing basis, but I digress…) but that could be regarded as a positive thing… no need to hang around wondering when your latest widget amends might finally make it onto the production server, you remain in control of publication at all times.
A tip of the hat in the direction of Widgetbox is appropriate at this point, if only for the fully-fledged Facebook apps you are able to create from your widgets in a few simple clicks using this platform, they really make this a painless process. However, at the end of the day, the sum of Clearspring’s well-thought through concepts, forum support and APIs were the clincher for me!
So, hats off to you Clearspring, for creating what looks like a very promising service, and I hope to be working with you very soon!
Steve wrote this on 22.11.07 –
It's filed in the Development, Social media, Widgets box
On December 10th, 2007 at 12:07 pm, Ash responded:
Here’s a basic case study of a widget project we did using the MDM Zinc platform…
http://www.ashwhiting.com/blog/2007/12/mdm-zinc-widget-engine.html
If you’d like to see the actual finished thing, or would like any further information about MDM Zinc, drop me a mail.
On December 10th, 2007 at 1:31 pm, Jez Nicholson responded:
In the Widgety Goodness conference, WidgetAvenue sounded interesting too. They appeared to be generating native code from an app definition rather than wrapping the widget to make it work anywhere.
On December 10th, 2007 at 5:48 pm, jenni responded:
Hi Ash
Until Steve notices your comment and you get a proper developer response ;) I was wondering how you define a desktop widget and how it differs from a desktop application? From what I’ve experienced any widget created with Air or Spring Widgets’ Spring Box etc will need an application to be downloaded to the desktop in order to view the widget - which from a user experience point of view is pretty clunky… Is this also the case with MDM Zinc?
On December 11th, 2007 at 12:31 pm, Ash responded:
Hi Jenni
It’s certainly not the case with MDM Zinc… It gives you a standalone installer and you simply install the object — I actually call them desktop “objects” when delivered in this manner. Not having to install any other software was the reason we chose this method to deliver our DHL Navigator. Our client didn’t want the user to have to download anything else alongside the object. I researched a great many platforms to this end, and for me (being lazy - I don’t want to bother learning Visual Basic or anything evil like that) Zinc came out top.
I may be incorrect, but I consider “widgets” to be things that bolt on to existing frameworks, IE Windows Vista - wheras “objects” are completely standalone.
Like I point out in my case study, MDM Zinc is great for non-techies to develop objects with. It has a great deal of inbuilt functionality via custom ActionScript - For example, you can sit a web browser inside the framework, play video files, save data to the client machine, run queries, connect to servers, and loads more.
I have limited knowledge of things like C and VB. The beauty of the Zinc platform is that Flash/Flex can be used in a very similar way that you may use Visual Basic. IE, as a (nearly) true application development platform. Basically, if something can be done in Flash or Flex, it can be a desktop object. (I hear 10,000,000 people who doubt Flash scoffing). The possibilities are pretty endless, then.
You don’t even need to have Flash installed on your machine, as you can bundle it with the installer when you set it up.
I quickly cobbled together a simple currency converter object so you can have a quick look at some of what the Zinc platform can do…. it’s here.
http://www.ashwhiting.com/Currency_setup.zip
Right click to drag it around…. ;) - (I couldn’t be bothered to make it left-click draggy)
Ash
On December 11th, 2007 at 3:22 pm, Steve responded:
Many thanks for this, Ash.
I was actually investigating the ‘best’ way of implementing desktop widgets, and this seems like a very good option. I agree that developing in Flash/Flex is the way to go, and I’d been considering Adobe Air for this but, as Jenni points out, this approach has the drawback of requiring an extra installation step on the desktop. MDM Zinc sounds great, if it can remove the extra step but still provide all the benefits of the Flash platform!
I believe Clearspring are releasing a tool that will automagically convert a web widget into an ‘object’ that is compatible with existing desktop widget plarforms (Google Desktop, Apple Dashboard and what have you), I haven’t had a chance to experiment with this yet, but it also sounds like a promising option!
On December 11th, 2007 at 6:09 pm, Jenni responded:
Cool! Thanks for the info Ash - very helpful. Loving the fact that it doesn’t rely on any other platform being available - and can think of loads of uses straight away!
On December 17th, 2007 at 1:12 pm, Rob Kent responded:
The idea of widgets and mashups etc is pretty interesting and has some obvious benefits for user-customised environments, however, the idea that it is magical and somehow program-free is disingenuous.
The truth is that anything - on the web or desktop - that does something, anything, involves program execution which means a runtime environment. The runtime environment might be Flash, Java, .NET, or a web browser (which itself hosts and bundles together a variety of runtimes, such as XML, HTML, CSS, and Javascript).
So the idea that widgets, ‘BLOB’s, or ‘objects’ can be mysteriiously downloaded to the desktop or embedded on a web page and simply run without the user having to have anything else is false and misleading. The word ‘widget’ should be qualified with an epithet such as Flash, Java, ActiveX, Silverlight etc so that your users/customers know what the real payload is. if the widget runs in a browser, you also need to specify which browsers are supported and which plugins are required in the browser.
If you have a look at the Clearspring documentation - which I have only just done as the result of reading your blog - you will see that they support a limited range of content - Flash, web page, Javascript, and image. In addition, they also support ‘BLOBs’ created using their proprietary API (yet another runtime environment hosted by them). So, when you use any of these platforms, you are buying into a specific set of tools and technologies. There is absolutely nothing wrong with this if you aware of what you are getting. Some of the comments on your blog give the opposite impression, as if this is all program-free, ie, ‘You don’t even need Flash installed on your machine’ - until you want to run the widget that is.
Since Clearlight is a launchpad management system and API, it might be worth separating that aspect of it from what you are able to launch with it, which, given the caveats about hosting Javascript and HTML in Facebook etc, seems to be limited to Flash, images, and syndicated content.
One last comment: why are they using the term BLOB in upper case? A BLOB is a Binary Large Object, normally stored as a stream of bytes in a database. Since they don’t define their acronym, I can only assume they are using it in the common sense of and ‘indistinct shapeless form’, ie not one of their registered types, in which case they should just call it a ‘blob’.
On December 17th, 2007 at 9:03 pm, Will McInnes responded:
Rob - wicked contribution. Thanks for joining in the conversation, and pointing out some areas for our developers to consider and come back to you on.
On December 18th, 2007 at 6:01 pm, Jenni responded:
@ Rob - Think my use of the word ‘platform’ might have been ill advised! What I was/am excited about was the ability to give the user the opportunity to install the widget direct, as opposed to having to install Air or SpringBox first and then go back for the widget. It seems clear that the more steps there are to installation the fewer users will bother - so removing those barriers will lead to a more successful project.
On December 19th, 2007 at 10:05 am, Rob Kent responded:
Jenni, agreed. But is this any different to the way the VB installer used to bundle up its own runtime dlls and install them if they were not already present on the user’s machine?
I was just trying to counter the general impression that widgets, ‘BLOBs’, or ‘objects’ mysteriously run without a runtime, as evinved by Ash’s comment on her MDM Zinc example: “The client wanted something that was completely standalone, and that didn’t need a platform for the widget to run on also”.
You can see how prevalent this impression is by looking around the web at users’ surprise when invited to download 10MB of Flash in order to run a widget that tells you how full the coffee jug is (joke).
One example is this comment from a user of Yahoo widgets:
“I’m sorry, I refuse to run this application. Yahoo Widgets are useful because of their simplicity, small size, and minimal impact on the system. For a mini - app like this, I refuse to download and install the 10MB Flash engine.”
http://widgets.yahoo.com/widgets/progressive-traffic-widget
Widgets can be wonderful, but they are not value or technology free and they involve a choice of tools and technologies in the same way as if I told my customer I was going to write their new application in Java, Ruby, Flash, MS Office, or .NET. Everyone has to know what they are buying into because it may have commercial consequences.
As the web becomes more widgety and your customers’ applications depend on them, it becomes important whether you buy into Google Web Toolkit, Clearspring API, Yahoo Widget, Flash, or any other runtime. Remember the Java slogan, ‘Write Once, Run Anywhere’? Could just as easily turn out to be Write Once, Run Away - leaving your customer in widget graveyard.
On December 19th, 2007 at 12:05 pm, Jenni responded:
I have to admit that as a non-programmer I’m not best qualified to discuss runtime environments and dlls!
I’m not really clear on the difference between a desktop application and a desktop widget, but from a user’s perspective it all depends on the perceived value of the application being installed. If you believe its going to do something really useful then you’ll jump through whatever hoops necessary.
From a publishers perspective then there is a requirement to be transparent and honest. The publisher of the traffic widget you referred to above suggests that the problem perceived actually lies with Yahoo. I can imagine that this sort of discussion will only get more involved as the web fragments into more and more disparate pieces or widgets. Ivan Pope has blogged his vision of this future over on Snipperoo - it’s big piece of thinking and well worth a look - http://blog.snipperoo.com/2007/11/death-of-the-do.html
On December 19th, 2007 at 3:15 pm, Rob Kent responded:
Jenni, I had actually read Ivan’s post and disagreed with most of it. I think that injudicious use of Web 2.0, widgets, Ajax, mash-ups, etc mostly leads to poorly or undesigned web applications, poor usability, poor performance, and non-adherence to well-established user-interface standards.
I accept that this might not matter much for a social networking site, such as Facebook, but for a commercial application - such as a corporate web site or an ecommerce site - it spells death.
Just to talk about performance: let’s say you put ten widgets on your corporate home page and they are being served by ten servers belonging to other people and you have no control over their performance or uptime, you’ve just lost control over the performance of your own site.
In addition, many Javascript widgets produce errors: if you run without Javascript debugging disabled (in IE), you will find a high percentage of Web 2.0 sites are throwing Javascript exceptions. In fact, this very page produces an error when I click on your photos on the righthand side ‘line 18 - ‘this.href’ is null or not an object’.
While not in agreement with Ivan, I am totally in agreement with Jakob Nielsen, “Web 2.0 Can Be Dangerous…” (http://www.useit.com:80/alertbox/web-2.html). Most sites do not even get their basic UI design and application processes correct from a Web 1.0 perspective, let alone by Web 2.0 or 3.
I don’t wish to pour cold water on the upgushing of widgetty goodness but I would urge some restraint. I use Ajax and Web Parts (http://www.windowsdevcenter.com/pub/a/windows/2006/01/10/what-are-web-parts.html) where they help me to fulfil the user requirements, and I totally avoid using them if I would only be doing so because they are there, they’re groovy, and I have an urge to use the latest technology.
On December 20th, 2007 at 4:06 pm, Steve responded:
Hi Rob,
Thanks for this, you certainly make some interesting points.
Are you saying that, as a technically-savvy type, you’d rather not have a widget bundled with its runtime ‘container’ so that you retain control over exactly what gets installed on your machine?
I.e. if you want to install a Java based application, you know you need to get Sun’s JVM. Likewise with having to install Adobe Air for any Air based apps.
I can definitely understand this perspective, especially if you end up installing 10 widgets, each of which comes with its own Flash engine. One word comes to mind - bloatware! :)
But, as a lazy programmer (that’s a good thing), what excites me about being able to develop desktop ‘objects’ (I like this catch-all term, thanks Ash :) in Flash/Air/Whatever is that it gives me a ‘write-once-run-anywhere’ solution, and removes the need to maintain separate code lines for different target platforms.
Plus, as Jenni points out it’s important to remove as many barriers as possible between your application and the public!
On December 20th, 2007 at 7:08 pm, Rob Kent responded:
Steve, I originally responded to the comment about widgets being great because they had no runtime payload. Then the conversation moved on to the use of widgets in general, which I have some reservations about. I think they have their place but if not used judiciously in the right place, you can end up with a slow app and a poor user experience, which aint good for bizness :)
On January 8th, 2008 at 1:54 am, Ash responded:
I think we all need to be careful about how much store we place on the end user actually being bothered to download a widget in the first place. We ran a DHL parcel tracking widget a while back which, in theory anyway, would be extremely useful for regular DHL customers and were frankly surprised how few of them actually opted for a standalone app to do this over simply using the website (and perhaps what they were used to doing) for this purpose. It is quite an exciting area for developers, sure. But I still think caution should be the name of the game before promising great results for a new methodology to clients. I think that with the development of new personal computing methods (say the iPhone and the like) Widgets and desktop apps may become more prevelant - Many of them could be well suited to small-screen environments. I’m just not sure at the moment that users really want too much more marketing led clutter on their computers. There is a real danger that widgetising the computing world is a little like dropping unsued litter all over someone’s computer. Ultimately I can’t help but think that users will get as annoyed by this as they are about intrusive pop-ups… Clutter is clutter at the end of the day…. Even if it isn’t “bloatware” — It is making your machine bloated with crap you probably simply don’t need…. I’d say, unless it is very useful, don’t punt widgets….
On January 8th, 2008 at 11:53 am, Will McInnes responded:
Ash,
1. How well was the DHL promoted? The limited downloads may not have been a failure of the widget/technology, but the communication, as has so often happened online (’great website, no one visits’)
2. Widgets don’t need to be ‘marketing-led’. At Widgety Goodness there was a surplus of examples which were old skool advertising dressed up in a new widgety form, which demoralised some attendees. Actually, the widgets I love are useful, revelant and opted-into by their users.
On January 8th, 2008 at 5:49 pm, Jenni responded:
I agree with your point Ash - as usual, it’s about identifying what the customer needs/wants and then finding the appropriate channel for it. I can envision the personal homepage as the place for these branded utilities - that way they don’t clutter the desktop, but are still available in a single place.