Life-cycle of UWA widget development
A question has been recently asked on the Developers Forum, which might warrant a longer answer: “How should we handle the release of our widget?”
I’ll expand my answer into a longer “development cycle of a UWA widget” of sort…
UWA widget should be built by following the documented guidelines - which are also available as a single page for those who only want a reference, not the full explanation. The UWA cheat-sheet is also a way of having it all at a quick glance.
Always keep in mind the most important parts, among which those three are make-or-break:
- Well-formed XML
- Netvibes namespace
There are a handful of successive ways to test your widget.
Also, if you are using Ajax requests, make sure to have a local proxy such as this basic one for local testing. Remember that an XML issue prevents list preferences to be properly displayed in standalone mode.
- Online, by uploading your widget to a web server (along with it’s images and the proxy, if needed), loading its URL in your browser, and checking that everything is fine. This is still standalone mode, so list preferences will probably not work, but now that your widget is online, you can test it further thanks to the two buttons located below the widget: the first one adds it to Netvibes, the second one to iGoogle.
- Within Netvibes. This is the first online test that should be done, since if it doesn’t work in Netvibes, there’s little chance it will elsewhere. Log-in to Netvibes, add the UWA Module from the Essential Widgets menu, and add your widget’s URL in its preference.
If all goes well, it should display your widget properly. The good thing is that if your XML code is not well-formed, it will tell you where.
- Once it works properly in Netvibes, test it elsewhere! Add it to iGoogle, add it to your Opera browser using the UWA Opera widget, add it to your Mac OS S Dashboard using the UWA Dashboard widget! Browse to your Netvibes account from your iPhone!
It works everwhere? Great, go to the next step!
If not, double-check your code, visit the forum, search the UWA FAQ, the how-tos and the known issues…
- It’s time to add your widget to Ecosystem, since this is where you will be able to add and test it with further platforms, once your widget is validated: direct downloads for Windows Vista, Apple Dashboard and Opera; direct links for Netvibes, Windows Live.com and iGoogle…
If all goes well, consider your widget fully tested and ready to launch! Congratulations
Now comes the initial question: how to release a widget? There are many ways to do so, based on the fact that you have two URLs for your widget: its Ecosystem URL (once it is validated), and its direct URL to your server.
In this respect, each situation is unique, and decision should be made according to your own inner methods. We of course advise to give a link the Ecosystem URL, since this is where users are able to add to all present and future supported platforms, with no action from your part – apart from keeping the widget’s file on your server.
You may also want to have a more customized page, on your own server. This is possible, as long as you use the links provided by Ecosystem for your widget: each platform compiler is on Ecosystem, and you won’t be able to propose Vista or Dashboard version without these. Apart from the link, you are free to redesign it as you see fit.
Thirdly, you may just want to offer direct access to the standalone widget on your server, and from there on let the use add to Netvibes or iGoogle if they want to. There again, just relying on the URLs provided by Ecosystem should keep you safe.
Note that once your widget is validated in Ecosystem, it’s also available with Netvibes internal search engine – given a few hours to update the cache. So that’s one less release issue to take care of.
Code changes, and so will your widget. But that doesn’t mean you will have to resubmit your widget to Ecosystem – or even, to take any action beyond updating your file. Indeed, Ecosystem simply acts as a linker to your widget file on your server: nothing is stored on our side, and so does any instance of your widget on the user’s page. You are therefore responsible of keeping the file available.
There are two cases of updates:
- Simply updating the file. New users will automatically get the new version from Ecosystem, and Netvibes users will automatically get the new version too, with their preferences intact. Easiest update path there is…
- Updating the file and moving it to another directory/domain (or just renaming the file). Ecosystem and user’s pages will still point to the older URL, so you have to make it so this changes.
On Ecosystem’s side, just go to the widget’s administration page (in the My Widgets tab at the top), and update its URL accordingly.
Handling existing users is trickier: you have to make them re-install the widget with the new URL. The best way would be to keep the older widget file at the original URL, and add a message to its content letting the user know that an update is available and that they should use it instead – pointing to the updated Ecosystem page. After some time, you may dispose of the older version/URL when you feel it’s safe.
If you just change the URL without notification to existing users, understand that you may lose their trust…
Sometimes you don’t feel like supporting them anymore, or they have been bested by some other widget, or your interests have moved on to other things. While we understand the many reasons involved in the idea of killing a widget, we must urge you to understand that it’s a loss for any user that came to rely on it daily. Before doing anything irreparable, please consider giving it’s support to another developer, and letting it be of use to its users, current and future.
If your decision is final, the steps are few. Connect to Ecosystem and simply click the red cross button to delete the associated widget. No new user will be able to use it. For current users, you may choose to keep the widget on your server, since it doesn’t do much harm there, and just put the widget offline in Ecosystem to prevent further users.
But if you intend to also delete the file, please consider backing it up first (because you never know), and please add a warning message for your users, advising them on finding an alternative, and maybe giving them an ETA.
This is just one way of seeing the life-cycle of a widget. Please consider them as best-practice, or even guidelines, but these are not the only way to act, just the one we envision ideally. You will probably build your own life-cycle as you develop more widgets. We just hope this post has been useful to devise your own path.
Don’t hesitate to let us know about your habits in the comments.