Your first UWA widget is Personalized Countdown. Is it your first widget ever? How familiar where you with XHTML/JavaScript before that? How hard was it to get it working as you wanted it to?

Yes, Personalized Countdown is my first UWA widget ever. I have played with MiniAPI before but not for a particular widget and not for a long time. I wasn’t an expert of XHTML/Javascript before that but I had to work with it on few projects like Visual-Music.org. I was mainly focused on server side scripting (PHP), so Javascript was only here to do some basic stuffs like show/hide element and form processing…

Due to the simplicity of the widget, it wasn’t really hard to get Personalized Countdown working like I wanted to. I’m an engineer, so I have some good automatisms like reading the documentation and the forums before starting. The documentation is not that big, but for a beginner it’s really perfect to start and to understand the basics. The most complicated thing in this widget was to use the correct function to do the periodical stuff. Not really a big deal in the end.

You then embarked in the more complicated TV Shows widget. Was it complicated to jump to a widget driven by external data?

Yes it was. In my first widget, there wasn’t so much Javascript. For the TV Shows widget, I needed to gather data from other websites to provide information to my widget. I first played with some RSS feeds and tried the different example widgets provided by the documentation. Then, I tried with other types of feeds and it wasn’t so hard with the Ajax examples. It wasn’t that hard maybe thanks to my job and education: I proceeded step by step, focusing on how to get external data with UWA first, and then on the design/features and so on. Once again, there are some basic steps explained really clearly in the documentation, and this helps a lot!

While building your widget, you documented the creation of your widget on your blog. Did it help you in any way – for instance, helping focusing on what to do?

I decided to do this for me, to see if I was able to explain things to a non-specialized audience. I don’t know if I have done a good job in the end, but it was a great experience. The other great aspect when you are working on an application like this one is the relation with the readers. At the end I wanted this widget to be not just for myself, so when people were leaving comments, advises and recommendations it helped me having a more global picture of the application and made me think about features I didn’t see at first sight. So yes, it mainly helps me focusing on what to do.

Did your perspective of UWA change between the time you got started with Countdown and when you were done with TV Shows?

Not really, mainly because I thought UWA was a great API since the beginning, when it was launched. The crossplatform compliance is just so cool! Like every computer scientist, I’m very lazy… So knowing that my widget would work on different platforms and not only netvibes.com was a huge point. The only idea that changed in my mind was that at the beginning I thought it would have been much harder to get into it.

What were your best surprises, and the biggest blockers/issues?

The first best surprise is how fast we can get something working and being cool. In like one hour of work, your widget is not just a hello world, it’s a personalized RSS feed!

The other great thing is to be able to log. If there is one thing I hate with javascript, it’s coding alert()s everywhere to check data… With UWA and Firebug, it just made my day everyday!

Nevertheless, there were some issues that got on my nerves, like the fact that the process is different on Standalone/Netvibes mode, my widget doesn’t work on standalone mode and I have NO idea why… I also switched to Ginger during the development and run into some bugs which were corrected quickly by the Netvibes team.

The last thing which bugs me is the Netvibes cache. For example my TV Shows widget doesn’t work on standalone mode and when I made a Javascript change, I had to wait for the cache to be over to test my changes. Maybe there is some tips to deal with this, but I don’t know them, so I had to be patient! (Ed. You can use the “Disable Cache” option in the UWA Test widget)

Where would you like to see UWA go next?

I would love to have documentation like a JavaDoc. The current documentation is good, but I don’t find it easy to navigate through. Documents like the PDF you made is just what I love to read! It helps finding new functions and sometimes helps finding new features for the widget.

The other thing I would love to see is a good management of the internationalization. It’s not perfect yet, you can’t internationalize the preferences part. Maybe the future is to build our own preferences part and not use the <preferences /> like the last Digg widget.

Share this post:

i-Métro is a very complex widget, using both a lot of JavaScript code, and a lot of server data. What made you choose to build the whole code from scratch rather than loading one of your existing Web version through an iFrame?

Our previous versions of i-Métro were “old-fashioned” web applications and we thought the NetVibes platform offered a good opportunity to build something more dynamic, kind of “web 2.0-ish”, especially with the promise of supporting multiple platforms. On a more practical point of view, none of our existing versions would have fit nicely in a widget and adjusting one of these would have required some work anyway.

However and despite the size of the main file, the widget has not been so complex to build since I actually re-used existing code for most of it, including styles, javascript and HTML code, not to mention the back-end providing the core of the service.

What are the advantages of generating your HTML code on the serverside, rather than using the browser’s DOM methods?

This is one instance where I wanted to re-use existing code. At first I considered that choice to be some kind of a trade-off, but I was also wary of possible performance problems when relying too much on javascript code.

When I see how slow Safari can sometimes be on my iPod Touch, I just congratulate myself on selecting this approach!
I also think the widget would not benefit much from using DOM’s methods, which I consider more adept at controlling the user interface at an elementary level. In i-Métro’s case, the interaction logic is still mostly based on a “page” paradigm.

How easy/hard was it to adapt your MétrO service into a UWA widget? How long did it take?

As I said above, building the widget itself was not very difficult. It just took a bit of time learning the specific UWA APIs – whose simplicity is a blessing – and all I had to do then was wrapping i-Métro in a dynamic interface – i.e. developping the “interaction” logic above the core services. Although I also created a dedicated version of these core services for efficiency’s sake, our internal server-side architecture let me do this very quickly.

All in all, I think I have spent between 30 and 50 hours building the widget and adjusting details.

What were the worst parts of building this widget? Were you able to include all the functionalities you wanted?

The worst part of building a widget are the same as for any web application: ensuring it is compatible with different browsers and platforms. At times, it is frustrating not to be sure whether a problem lies in one’s code or in the UWA library but thanks to the active developer forum I have never been stuck with bugs for very long.

There are a few features I’d like to add to the widget but the main reason they are not yet implemented is the lack of time – I have to maintain data for transportation systems in about 400 cities! – rather than limitations in UWA. I’m afraid you provide new features faster than I can use them

How was it received by your existing community?

I must admit I am quite disappointed with the lack of feedback I have received about the widget. I know, through the NetVibes Ecosystem and our own back-end logs, that there are quite a few users but I don’t really know what they think of the service.

There is an exception, with the recent addition of an iPhone version of the NetVibes portal: our long-time users really enjoy having access to a rich version of our software on their phone.

What are the improvements you would like to see in UWA?

This is a tough question and after giving it much thought I have not come up with any bright idea The only problem I would like to point out is about the publishing process: every time I want to update the widget in the Ecosystem, I scratch my head wondering how and where I should do it. Why is it not clearly explained in the documentation (or would it be that it is so obvious I can’t see it)?

And I wish you’d deliver much faster on the compatibility with the various widget platforms… (OK, maybe I shouldn’t expect miracles).

I also have a few ideas over the NetVibes platform itself: first, I’d love to be able to provide a direct URL to an iPhone version of i-Métro for users who do not want to setup an account. Second, I’d suggest adding a standard option to the widgets letting users directly post a comment in the Ecosystem – yes, I’d like to get some feedback

Share this post:

How many MiniAPI modules did you build?

Since april 2005, I’ve developed around 30 modules using MiniAPI. Some modules, like Finance, TV Series, French TV Schedule and Calendar are among the most popular widgets from Netvibes Ecosystem.

Do you plan on converting them all to UWA?

For now, I plan to convert to UWA only modules which are used by at least 1000+ users, which makes for 50% of my modules. But If I have time, I’ll convert all.

What are the major benefit of switching to UWA?

There are many benefits to switching to UWA. On one hand, UWA is obviously better than MiniAPI: features, stability, documentation, community, … and on the other hand, UWA allows your widgets to be available outside Netvibes. I often receive emails from users who ask me to convert my modules to UWA because they would like to have them on their iPhone or other platforms.

What would prevent you from switching some of your modules to UWA?

Only Time! UWA is great, documentation is perfect, Netvibes team is brilliant and reactive – for me, only time could prevent me from switching my modules to UWA.

You’ve already switched a few. What are the main problems you’ve encountered thus far? How did you solve/circumvent them?

As soon as UWA launched, I’ve switched Mortgage Calculator module, mainly for testing it. Next I switched French TV Schedule module and I didn’t have any major issues. Some tutorials from the documentation explain pretty well how to convert MiniAPI module to UWA.

The only small issue was with Edit area. With MiniAPI module, this area was fully customizable, and I used it to add items or events to the module. With UWA, this area is strictly used to modules preferences, so I had to fit my mechanism directly into the body of the widget.

Another small matter is testing … With MiniAPI, I just tested modules on the four main browsers (IE, Firefox, Safari and Opera), but now with UWA and all its supported platforms, testing takes longer – but I don’t forget that the audience is bigger!

How do you feel about UWA globally?

I really like UWA. I think UWA is the best tool for developers who wish to develop widgets for a full set of platforms. I only regret the lack of tools around UWA – but stay tuned, I will talk about that later on my blog…

Thanks for the interview, Ben! Hope to see more switches from you soon

Share this post: