SpringWidgets: Early Review

The release of SpringWidgets and the SpringBox runtime caught my attention today. I have been working on widget like applications alot lately, the Finetune embedded player in particular.

JD from Adobe posted a little call out for reviews , so here I am answering that call.


First Impressions:

The UI is nice. It has a little dashboard that holds nice looking icons representing the widgets you have installed. The dashboard/runtime can be launched from the start menu, and remains in your system tray.

Widgets can be launched from the dashboard, or they can be launched from the web, I am guessing this is implemented using LocalConnection. The web launch does not work without the runtime running in the system tray.

Widget files are SBW files, which are just SWF files with a different extension. You can try and double click them to launch in Springbox, but you will be disappointed in the fact that it throws an error saying the widget is not valid, even though it clearly is.

Widgets can be installed from the web, but I have not yet deduced how this works. I am assuming that you would have to register your widget with SpringWidgets. The developer APIs do not provide any insight into the web install feature.

Embedding Widgets on the web runs your widget in a shell SWF that includes their platform. This is a cool idea to allow the widgets to work both on the web or the desktop, but again I have not determined if you have to register your widget with SpringWidgets to utilize this feature. I am guessing you do, even though they have no info on their site about this yet.

So far I think it is cool that they have built this runtime around the Flash Player. I can definitely see myself using it, so it is on to the attempt to port the Finetune Embedded Player to it. I am overall impressed with this simple little tool so far.


Developer Perspective:

Ok, so I download the SDK and samples. Let me prefix all of this by saying that the whole thing goes seriously downhill from here. I will do this as a series of problems that I faced in a list. The problems far out-weighed the features with this tool.

1/ Flash Player 7+ is BS

It is a Flash Player 8 embedded in the application. Flash Player 9 SWF files do not run. Had SWF 9 files have run, I would have loved this thing. Not the case. So all you people out there hoping to bring the power of the new Flash Player runtime to the widget world, are going to have to wait for Apollo.


2/ Primitive API

this API really sucks for anyone that develops in Flash, using methodologies newer than say 2-3 years. The API is totally Actionscript 1 oriented.

No intrinsic classes for Springbox objects, The 3 objects that come into play are dumped onto your root. This makes dealing with the API difficult or clumsy for anyone working in an Actionscript 2 only workflow. While the community could write classes to modernize it, it struck me as bizarre, that a proper AS2 API was not released by default.


3/ Missing Details

Nothing on how to register your widget. Nothing telling you how to include an icon in the dashboard for your widget, nothing telling you how to pass launch parameters, nothing stating how to launch an "Open File" dialogue, etc. Most of the issues are probably going to be related to the fact that they just launched it today, but still.


4/ Another codestream

I am also a slight annoyed that I have introduce even more code to make my widget work in yet another environment. The fact that there is not an option for a default chrome is frustrating, and if I want to opt out of their actionscript API (which i do in this case) and deliver the basic settings in say, an XML file, I am screwed.

While Springbox does offer you a lot of flexibility in how your widget should look, the stupid close button it includes by default over my widget means I have to define a size (in AS) and customize the header of the widget to accomodate the close button visually just for this runtime.....

Between embedding the widget direct from Finetune, Apple Widget format, Google Widgets format, and various other formats , a widget becomes very frustrating to spread around and keep clean. The simple widget, isn't so simple anymore.



Overall Feelings:

I like the application, and the way they are heading with it. It is a neat idea to do the cross web/desktop widgets. I can't help but feel the potential similarities between Macromedia Central and SpringBox though from a business model perspective. I am worried that they will eventually try to work this application down the same licensing road that Macromedia did, to failure. They may have another model in mind however, and I am interested to see what it will be.

Due to the fact that there is not support for the Flash Player 9 and it's wonderful binary APIs, I struggle to see the benefit of having desktop widgets that can't really do that much more on the desktop than they do on the web. I believe that the point of bringing something to the desktop is to extend your offering, not give someone the same thing in a different environment.

While the SpringBox is innovative in the fact that it is offering a standardization for widgets across the board, I am not convinced that the standardization is actually useful to anyone in the real world.

For example, lets assume that Fox uses this for MySpace, which they obviously will. Lets say they use it to extend the reach of their MySpace music player. The MySpace Music player is a nice little widget that users can load up their playlist of mp3's in, and have their visitors enjoy.

Will the Music Player be something I could pull to the desktop? If I could, what playlist is loaded into it? Probably the one from the MySpace profile I got it from. What about if I want to get another playlist from another profile? I guess I would go to another person's profile and maybe the playlist would load into my widget player instead of the embedded web player! Woho!

Not really, I am still browsing the web, and in order for my desktop player to be useful it would need a different, more robust UI to act as an aggregator of content I am listening to as I peruse the site. That way I can always go back to something else I was listening to later when I am not on MySpace.

If the desktop player did not offer these extended features and UI, there is little to no value in having the widget on the desktop. Therefore, I do not see too much value in widgets that offer very similar feature sets across the web and desktop.

Web widgets are viewers(a bit of data) , desktop widgets are gatherers(a lot of data). This is the case when the data for consumption in question, is in control of users rather than publishers. Identical UI's are great for sports scores and clocks, but will quickly become silly for most other types of data that a user tries to consume on mass.

In my opinion,

The progression of this effort should not be focused on consistency across platforms, it should be focused on relevancy and adaptation to context across platforms.