While its documentation has been severly improved since then (let us know if you consider it could still be better!), there remains a feeling that implementing tabs in a widget is a complex task, best left to wizard developers.

It’s not! And this article will drive the more sceptic among you through code samples that should make everything clear. Here goes.

Sample 1: three different tabs

The first sample code presents how to combine 3 widgets into one widget with 3 tabs, each one displaying the same content as the original widget. The three panels will display, in our example,

• some regular text;
• the latest Astronomy Picture of the Day, as per the APOD sample widget;
• the latest posts from this very blog, as per the RSSReader sample widget.

The resulting widget is available here.

We can only advise you to dive into its code, and compare to the original widgets’ code. We’ve provided as much comments as possible, so as to help you understand how we implemented some parts.

Sample 2: three different tabs, paging in feeds

You’d notice in the previous example that we did not use the Pager component, in order to simplify the code to the maximum. Therefore, if the user were to change the preference to only display the 5 of the 10 items in the feeds, he wouldn’t get the expected “prev/next” buttons at the bottom of the widget. This is what this sample code implements.

The resulting widget is available here.

The difference with the previous sample code mostly resides in the block of code that starts with this line:

var pager = new UWA.Controls.Pager(

Here, the pager object is instantiated, and the rest of the code show you how to properly have it displayed.

Sample 3: three tabs with a different feed each

As you may know, the most popular use of tabs is to have one widget for many feeds, thus reducing the needed space. To that end, you’d need to re-use the previous sample widget, and duplicate the third tab into the two first ones.

The resulting widget is available here.

Since we remove the code that displays the first two tabs (the text one, and the image one), the code gets shorter, but you should actually pay more attention to the code, because it presents how to have the logic work for us, and not crash the widget every time we change tab.

For instance, in the previous sample code, the pager was placed in a given, non-changing DIV tag:

var pagerDiv = widget.createElement('div', {'class':'paging'});

It is important to understand that each of the three tabs require its one pager, and therefore to have the code properly implement the pager so that tab-changing would not break it:

var pagerDiv = widget.createElement('div', {'class':'paging_'+tabName});

There are more advanced uses of the TabView control, which will have a look at in another post…

Your turn!

Go ahead, dive into each sample widget’s code, and you should come out of it with more understanding of tabs and their inner working.

Share this post:

A reminder: JavaScript in UWA

As UWA developers know, portability and predictability in the framework’s usage has lead us to not recommend the use of JavaScript objets such as ‘window’ and ‘document’, instead recommending the equivalent to some of their methods that have been implemented in the UWA-specific ‘widget’ objet. For instance, ‘window.open()’ is to be dropped in favor of ‘widget.openURL()’, or document.getElementById(’uniqueID’)’ is to be replaced by unique classes and the use of ‘widget.boy.getElementsById(’uniqueClass’)[0]‘, among other things.
Failing to find the needed function equivalent in the UWA JS Framework, developers are suggested to implement the required code within the widget’s HTML page.

That is all fine and dandy: all UWA developers are now used to play with these idiosynchrasies, and their widgets just get sturdier thanks to that. But when it comes to Flash-JavaScript communication, things get more “idiosynchratic”, if you will…

The curious case of Flash-JavaScript communication

Flash-JS communication is a subject at least as old as Flash itself (well, at least as old as Flash 2 and FSCommand, then). The solutions at the time seemed almost magical, nowadays they are well understood and implemented within ActionScript – the Flash scripting language.

Calling a JavaScript function from the Flash application’s containing HTML page only requires a couple of ActionScript lines with Flash CS4. Let’s say we have on our Flash scene two main instances: a textfield named myInputText and a button named myButton. With a click on myButton, we want Flash to send the text content of myInputText to a JavaScript function called, for lack of a better name, theJavaScriptFunction().

Here’s how our ActionScript code could look like:

import flash.external.ExternalInterface;
myButton.addEventListener(MouseEvent.MOUSE_DOWN, mouseDownHandler);
function mouseDownHandler(event:MouseEvent):void {
  if (ExternalInterface.available) {
    try {
       var tempStr:String = ExternalInterface.call("theJavaScriptFunction", myInputText.text);
    }
    catch (error:SecurityError) {
       // ignore
    }
  }
}

Basically, with Flash CS4, the ExternalInterface object is the central place to improve your communication skillz. Past versions of Flash had other methods, that we’ll let you peruse at will, since it’s a safe bet CS4’s methods are here to stay…

Flash-JavaScript communication in UWA

Since UWA isn’t much more than a XHTML page, having Flash communicate with JS in that context should be a cake, right?

Wrong. Remember the first part of the article, where I reminded you of the “no ‘document’ object” recommendation? Well, as it turns out, JS method calls from Flash are targetted at the document – which means, basically, that if you try to call your MyWidget.AwesomeFunction(), Flash will in fact target document.MyWidget.AwesomeFunction(). Hilarity ensues.

One solution here is to break out of the “no ‘document’ object” rule, and build a proxy function for each JS method that you want called. For instance, in order to call this function:

MyWidget.AwesomeFunction = function(var) {
  // some code
}

…you’d simply have to define a proxy AwesomeFunction directly on the page’s default object (the ‘document’ one), and have it call your UWA-tied function, like so:

function AwesomeFunction(var) {
  MyWidget.AwesomeFunction(var);
}

So, this would tend to prove a little diversion can go a long way. But wait! There’s more!

Making your way through domains

Official explanation graphic from Adobe

Let’s say your ActionScript and JavaScript code is in place, as explain above. You load the widget directly in your browser (standalone mode), and it just works: awesomeness! But then you decide to install the widget on a Netvibes page, and lo!, it fails to even trigger AwesomeFunction(). Fatalitas!

No, Netvibes is not blocking such usage of UWA code. Simply put, Flash has some security restriction which you will need to check one by one before you can make it all shine.

The basis of these security measures is the domain name. In short, by default, a Flash app (.swf) can only communicate with external files (.html, .php, .xml, .js …) if it is hosted on the very same domain name.

This behavior is therefore broken once in Netvibes (or any Exposition-based widget server, for that matter), since widget’s are not only displayed within an iFrame (which might be a problem in itself), but also on a unique domain name. Hence, the HTML file can never be on the same domain as the SWF file, and therefore the data loading (or JavaScript communication, in our case) cannot happen.

Luckilly, Macromedia at the time undertstood that need, and gave us support for a crossdomain.xml file, which would let the developer allow (or disallow) a given set of domain to be accessed by the SWF. This XML file, hosted at the root of the domain bearing the Flash file, can take this form:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

For added fun, you can add the following lines to your ActionScript code:

import flash.system.Security;
Security.allowDomain("*");

These lines are another way for Flash to validate crossdomain access.

One down, only one more to go….

But that’s only for data, here. What we need in our case is access to the local JavaScript. This, in turn, is made possible by adding the AllowScriptAccess attribute in the SWF’s embed code, and setting it to “always”. Your embed code would therefore look like this:

<embed type="application/x-shockwave-flash"
  src="http://domain-name.net/uwa-flash.swf"
  width="250" height="100" bgcolor="#FFFFFF"
  AllowScriptAccess="always"></embed>

Still willing to use Flash for your widget? Then hop onto the next section!

Handling UWA preferences from a Flash application

As if that wasn’t enough, there are cases where you’d like your Flash application to make use of UWA’s preferences methods, if only in order to record the user’s settings for the Flash app within the confines of the UWA environment.

This case should be view from two points:

1. Have the Flash settings be saved as UWA preferences;
2. Have the Flash app load the UWA preferences on startup.

The first part is pretty ease if you you follow the instructions above: instead of calling widget.setValue() directly from ActionScript (which would result in document.widget.setValue() being called instead, and therefore nothing happenning), you’d call UWA_setValue(), which in the HTML file would be defined as…

function UWA_saveInPref(varid) {
  widget.setValue('myValue', varid);
}

Obviously, if you have more than one preference to set from Flash, you’d nees to expand on this code a bit…

Now, we want the SWF file to load up a preference, but only if it is set (obviously, else it would load the preference as ‘null’ or other unset values). That can be done pretty easily by passing variables to Flash via the embed code’s URL (or more precisely, its query string).

Why, yes it is!

Here is one way to get a nice, working query string for your Flash app…

First, retrieve the preference value, and build it into your query string via a ternary operator, for instance. Here is an example:

var myValue = widget.getValue('myValue');
div_flash.innerHTML += '<embed type="application/x-shockwave-flash"
  src="http://domain-name.net/uwa-flash.swf'+ (myValue?'?theValue='+myValue+'':'')
  +'" width="250" height="100" bgcolor="#FFFFFF" AllowScriptAccess="always"></embed>';
widget.setBody(div_flash);

If the ternary XXX finds that myValue is not empty (ergo, the preference is set), then it assigns its content to the Flash app’s theValue internal variable. If it is empty, ‘theValue’ is not even defined in the query string, and the Flash app launches in its default state – which is pretty much the whole point of this ternary operator.

Second, add the following two lines of ActionScript in your SWF’s first frame (given that you want to update a ‘myInputText’ textfield based on that query string):

var myQueryStrings = this.loaderInfo.parameters;
myInputText.text = myQueryStrings.theValue;

This will load our query string (using the loaderInfo object and its ‘parameters’ property), and assign the ‘theValue’ value as the text content of our beloved myInputText. Done: the textfield is updated with the correct UWA preference on each loading (or preference update)!

You can see it for yourself with this basic widget, the code of which is available here (you might need Flash CS4).

Two final tips, for the road

1) Don’t forget to add wmode=”opaque” to your embed code, so that i doesn’t overlap with Netvibes’s content!

2) Choose the “hidden” preference type if you want that preference to only be changeable through your Flash app!

Now go and build more awesome Flash-based UWA widgets!

Share this post:

Feed widget in normal view

Back in December 2008, we updated our Feed Reader widget with three new views (Ticker, Carousel, Magazine) ; we added four more feed views in March 2009 (Classy Slideshow and its black-background version, Headline, and Quick Details), bringing a total of 8 possible views for your feed. Netvibes users can then choose the most appropriate view for a given feed, and bring more variety to the whole page: feeds can now stand out, image-centric feeds are better than ever, it makes it easy to discernate between two feeds, etc.

Feed widget in Magazine view

All in all, these new views not only bring a whole better feedreading experience to the Netvibes users, but they can also prove to be very handy for those whishing to build some greate public pages based solely on feeds – with a the help of Flexible Layout tool that was also released in December 2008.

Feed widget with Ticket view

So, users can choose to set their page with different views, public pages editors can present their content in a great fashion of ways, but one point remains: how to you make sure that YOUR feeds can work properly with these new views?

How can you make use of them?

The best way for your feeds to be correctly handled by our various views, is to have them carry a proper link to your media content (most of the time, an image, but it could also be audio or video). This way, the feedreader can display more than just text, which in turn will make your feed stand out in the crowd of those without an image. Simple as that.

Feed widget in Classy view

There is a handful of way to do this in the world of feeds, the most popular being:

• enclosures ;
• MediaRSS ;
• parsing of the post’s content.

…which are all supported by Netvibes, of course!

Let’s explore each of these solutions…

Enclosures

Enclosures rely on a special type of XML tag, which have been supported by the RSS and Atom formats for a long time, and that all major feed readers now understand. In these two popular feed formats, enclosures simply point to one (or many) media files, along with useful metadata about these. Feed readers can in turn make use of these informations to display the media files along (or after) the post’s content.

The <enclosure> element was added to RSS back in 2000, when broadband was still rare and it would make better sense to let feedreader download a feed’s huge files during idle time (at night, for instance), allowing the user to come back to his/her feed reader with all files downloaded.

Using enclosures, an editor (or editing tool) can add an absolute URL to a file, to be dealt with by the feed reader accordingly. In the case of podcasting, that enclosed file would be an MP3 file (or some video format for “vidcasting”), file which the feed reader would download silently and make available to the user for his listening (or viewing) pleasure. Nowadays however, thanks to omnipresent broadband and cheaper bandwidth, files can just be listened through directly – such as is possible with Netvibes, with the podcast player.

Feed widget with Slideshow view

Even for non-podcasters, enclosures can be useful simply in order to point the feedreader to a thumbnail image, which would bring more life to the feed in some feedreaders, and help it stand out in the crowd…

MediaRSS

MediaRSS is an extension to the RSS 2.0 file-format, trying to solve one issue: enclosures in RSS could only link one media file per files. While one was enough at the birth of podcasting, now podcasters like to spread their audio/video files over more than a single, or include some more interesting media content besides the main file itself. This was solved right at the beginning in Atom, but the RSS format being frozen, extensions where needed.

In these case, the Yahoo! developers stepped up and proposed MediaRSS, which immensely improves on RSS enclosure tag, adding support for such much-needed data as thumbnail, title, description, keyword or even player source URL, for each link file.

Sadly, not all feed readers do understand MediaRSS, which leads to some CMS and feed-generators to not put this extension to wider use.
Why so? Once you build upon a much-successful format, having your extension of that format adopted by the very people it targets can be hair-threatening. It’s very much like a Catch-22 – or a chicken-and-egg dilemma, if you will:

• Why would data publishers implement your extension if no tool support it?
• Why would tools support it if no data publishers implement it?

We at Netvibes chose to support that extension as much as we could, since it the best way to benefit our users. Therefore, we fully encourage you to make use of MediaRSS, and help spread its usefulness.

Parsing

Alas, not all feeds/CMSs do implement MediaRSS — or even enclosures, for that matter. Still, there is no reason why these feeds would not have their image nicely thumbnailed for all to see. In this case, feedreaders cannot rely on standardized tags, and therefore have to rely on magic.

Magic, or in our case parsing, which means that the post’s content is scanned by the Netvibes feedreader, all the images are gathered, and the first one in the post is then used as a thumbnail. Problem solved. Magic, I tell you.

One recurring pitfal that you should strive to avoid: smileys. Along with social network buttons, they represent the culprit of badly-chosen thumbnails, and would most of the time happen when parsing is necessary (no enclosure nor MediaRSS tags to be found). While this misshap is pretty much unavoidable for image-less posts (we’re working on a solution), bloggers who use images in their posts can sometimes be surprised to find a smiley instead of their beautifuly crafted illustration.

Smileys gone bad

The explanation is easy: as said earlier, the post parsing makes a list of all images in the post, then uses the first image as the thumbnail. Therefore, in order for the first big image to be used as a thumbnail, you should try as much as possible to either…

• put the image as for the first content of the post, even before the text itself ;
• never use a smiley before the first image of the post.

Still, this remains a constrains, and we’re currently working on a solution around that issue…

How it all works out in the end

Because some feeds can propose both enclosures and MediaRSS tags, it’s up to the feereader to sort the wheat from the hay. Here’s how we decided to make it work at Netvibes :

• In the case of thumbnails :
  1. use the first <enclosure> tag ;
  2. use the first <media:thumbnail> tag ;
  3. use the first image within the <media:content> tag ;
  4. use the first image within the post’s content.
• In the case of videos :
  • we exploit the <media:content> tag that has a content-type of “application/x-shockwave-flash”.

As you can see, the best way to have your media files be correctly handled by the Netvibes feedreader, is to use the great MediaRSS extension to your RSS feed. Since not all CMSs support it out-of-the-box, you might have to dig for existing extension – here’s one for WordPress, and another one for Drupal, for instance. Know of more? Come and share them in the comments!

Share this post:

Today marks another milestone for animated themes in Netvibes, with the official support of 10 brand new themes, which obviously make plenty o’ use of time ranges.

I want my own!

We hear ya! One of the great projects released with the Netvibes Labs launch, back in April ‘09, was the Theme Designer, which allowed you to design your theme visually rather than through a tedious XML format.

However, our Theme Designer is not yet able to build animated themes (that’s planned for a further iteration), so in order to feast your visitors’ eyes with an everchanging design, you will still have to dive into the code. Don’t be scared: it’s quite easy as long as you know how to handle XML.

Our theme documentation already features most of the information you might need in order to code your own theme, be it static or animated.

In this article, we’ll dive into building a complete animated theme step by step, using the Theme Designer. That editor doesn’t yet support animated themes, but we can just as well use it to build a handful of static themes, and merge them into one file by hand, in order to get an animated theme!

Step one: Deciding on the time ranges and graphics

Before we hop into the editor and start choosing the header color for widgets, you should first have a clear idea of what you want your theme to look and behave like – which could greatly impact the header graphics.

For instance, you can have up to 24 different designs (one per hour of the day/night), but you can just as well have an animated theme with two different states.

For the purpose of this article, we’ll show you how to build a 5-parts theme, with 3 different behaviors: work, lunch, and spare time – therefore, your visitors will be able to know what you’re up to just by looking at your theme!

Each behavior fits into a specific time range:

1. 12am-9am: spare time
2. 9am-1pm: work
3. 1pm-2pm: lunch
4. 2pm-7pm: work
5. 7pm-12am: spare time

Note that while the two “spare time” ranges are next to each other, the XML format requires us to keep them separated rather than having a single “spare time” range going from 7 PM to 9 AM: valid time ranges are from 12am – 12am, and if the end time is before the start time, it will cause an error.
Also, make sure you set ranges for the full 24h of the day — you wouldn’t want your users to miss out on an hour…

Step two: Making the graphics

Our theme  has 5 parts, but we will base it upon 3 designs: “lunch” (used once), work (used twice) and “spare time” (used twice).

We’ll leave the graphic creation to you, and will simply remind you of the size recommendations for a good header image, as well as useful information:

• Images should be at least 175px tall. Since the user can expand the header’s height, it is recommended to go up to 260px, or even 300px to be on the safe side.
• Center image must be at least 640px wide.
• Tile image can be any size, but must wrap-up seamlessly.
• Image should not weight more than 100 kb. Recommended weight is 40 kb, but prefer better quality to smaller size.
• Images are centered in the header, both horizontally and vertically.
• Images can use any format. Recommended are PNG andJPG, but GIF can of course be used. Use PNG/GIF if you need to use transparency.

A lot more information is available in the theme documentation, such as a description of the various layers available for the header, and image tiling…

Step three: Making the themes using the Theme Designer

Now that you have everything at hand, you can launch the Theme Designer and simply fill-in the blanks for each section. You’ll have to do that for each of the various time ranges of your animated theme.

Once you feel you static theme is perfect, you can save it by clicking on the “Download theme” button, available from the Main tab. You end up with an XML file containing all the needed info for your static theme, and named “theme.xml” – which we advise you to promptly rename into something more informative, for fear of overwriting it with your next theme saving.

Step four: Merging static themes into a animated theme

Each of the three static themes we have created are wholly contained within the <ConfigMap type=”Skin”>…</ConfigMap> tags of each of their respective XML files. One theme XML file can contain more than one such <ConfigMap> tag, and they are differentiated using the sub-tag <Trait>, as explained in both the theme documentation and the announcement from last month.

Therefore, merging static themes into one animated theme is simply a question of copy/pasting the <ConfigMap> tags from all files into the remaining one, after its own such tag. Once the pasting is done, add a <Trait> tag with the proper time range settings to each <ConfigMap>, and you’re pretty much done!

In our case, we have three static themes which apply to 5 time ranges, so two of them are bound to be duplicated within the XML. They will be singled out by their <Trait>.

In order to build our animated theme, we’ll start with the file for the static theme tied to the first time range, then paste the <ConfigMap> tags from the two other files into 5 distinct <ConfigMap> section, and finally differentiate them using their very own <Trait> tags. The sequence of the <Trait> tags might be as such:

1. “spare time” theme: <Trait name=”TimeOfDay”>12am-9am</Trait>
2. “work” theme: <Trait name=”TimeOfDay”>9am-1pm</Trait>
3. “lunch” theme: <Trait name=”TimeOfDay”>1pm-2pm</Trait>
4. “work” theme: <Trait name=”TimeOfDay”>2pm-7pm</Trait>
5. “spare time” theme: <Trait name=”TimeOfDay”>7pm-12am</Trait>

Easy as peas!

Step 5: applying the theme on your page

You must upload the XML files and all the media files it uses on a public host in order to apply it. Do not remove it from the host after installation, since your page would lose the theme altogether…

Now comes the part were you get to see your theme in action. As explained in the documentation, you can apply the theme on either one of your private pages, or your public (or all of them!) – it all depends on the syntax you use.

If it’s on a private page:

1. Go to that page of yours ;
2. Type the following in your browser’s adress bar:
   http://www.netvibes.com/?theme=http://URLOF YOURTHEME

If it’s on your public page (http://www.netvibes.com/PAGEID):

• http://www.netvibes.com/?visit= PAGEID&theme=http://URLOF YOURTHEME

Explore 10 exclusive themes!

The 10 exclusive animated themes that were released today are available for your to browse through, in order to learn how to build awesome themes yourself!

Here are the links to their XML files, along with links to apply them on your current private page:

• 4 Seasons (apply it)
• 24 Hours (apply it)
• Aurora (apply it)
• Colors (apply it)
• Food (apply it)
• Grey Texture (apply it)
• Heart (apply it)
• Lightness (apply it)
• Sea Serpent (apply it)
• Yann Arthus-Bertrand (apply it)

Caution: Applying one of these themes will replace the current theme.

Show us your own themes!

Share this post:

Dynamic themes are themes that evolve according to the time of day. Provided the theme designer has built his theme conscienciously, a visitor to your public page would not see the same theme in the morning, in the afternoon or in the evening.

This can make for some very creative and inventive use of a theme! You can now express the whole spectrum of your personality through your public page’s theme.

How it works

In your themes, all you have to do is create more than one <ConfigMap type=”skin”> and indicate the time the skin must be displayed at. To do so, add the following tag: <Trait name=”TimeOfDay”>1am-2am</Trait> in yout ConfigMap.

You should end up with something like this:

<ConfigMaps>
  <ConfigMap type="skin">
    <Trait name="TimeOfDay">12am-12pm</Trait>
    ...
  </ConfigMap>
  <ConfigMap type="skin">
    <Trait name="TimeOfDay">1pm-12am</Trait>
    ...
  </ConfigMap>
</ConfigMaps>

Make sure that your timestamps cover the whole day. You can make your life easy by having just two themes (12am-12pm and 1pm-12am), or go crazy and make a specific theme for each hour (12am-1am, 1am-2am, etc.)! Don’t be afraid about using too many images: only the currently dispayed image is loaded.

We’re looking forward to improve the syntax. Help us build a better theme format by sending your feedback!

Share this post:

UWA widgets at work

That’s exactly what happened last month with Kludgets. Kludgets (short for “Klumsy, Lame, Ugly, Dumb, but Good Enough” ) is a new, open-source and multiplatform (Windows and Linux) widget engine, which aim is to become a best-of-breed widget engine, taking inspiration from the best features of other platforms.

As such, its widget format is a clone of the Apple Dashboard’s. And since UWA widgets can be exported to the Dashboard format, it was only a matter of time before the Kudgets developer took advantage of it! As they write in their blog, it only takes a handful of steps to get any UWA widget from Ecosystem to work on this new engine.

We’re really happy to see further proof that the UWA format’s versatility can be once more proven by this open-source project, and we wish it a swift and successful version 1.0!

Now, if they could directly implement the UWA format itself (either using the UWA specification or the LGPLv3 Exposition project), that’d be neat!

Share this post:

Well, ado there needs to be: let it be known, good people and dearest subscribers, that my time away from the blog has not been in vain, only that I was diverted by other projects which needed my full attention. Even better, the latest of these time-consuming project has even been recently launched: French users of Netvibes can now profit (literally!) from a fully-featured Cashback widget – in the conception of which I had a not-too-small part

Anyway, the Netvibes DevNet blog is now back on tracks, and to make up for the lost time, here are a couple not-so-random facts that popped on our screens during the hiatus, and that we thought you might be interested in. In fact, far from being random, they are both tied to UWA one way or another. Neato!

UWA widget for WordPress!

Now that the major components of UWA have been released as open-source on Netvibes.org (as well as the UWA specification), it was just a matter of time before some talented coder got hold of them to add UWA-capability to a project. Turns out the talent came from none other than François Hodierne,  a former member of the Netvibes team and the man behind the h6e moniker!

The UWA Widgets plugin, which hecreated and released back in January, is a WordPress plugin which lets you add UWA widgets on your WordPress dashboard. Simple as that.

What that means is that you can improve the overly dull defaults blocks of WordPress’ dashboard, by mixingsome fun or useful widgets in.

Installing a widget is very easy, once you have a UWA widget’s source URL. The plugin adds a ‘Manage Widget’ section in the ‘Settings’ menu. Click it, and a quick interface reveals itself: a list of the installed widgets (with a remove button in case you need it), and simple form to add new widget.
Copy-paste the new widget’s source URL in that form, validate, and from now on the dashboard will display it along with the other components. You can edit the widget just as you would on Netvibes or the Apple Dashboard: by clicking the ‘Configure’ button that appears at the top-right of the block…

The WordPress dashboard with the Twitter, i-Metro and Gaping Void UWA widgets

You can get this nifty plugin from the WordPress.org Extend section, or directly from WordPress’ internal plugins installer (if you use WP 2.7+).

Note: the UWA technology relies on the Zend Framework. Hence, François have created a separate Zend Framework plugin for WordPress, which you should install and activate before activating the UWA Widgets plugin.

UWA cheat-sheet in Russian!

Our friends at Rambler.ru, who’s own personnalized startpage uses the Netvibes technology, have been kind enough to make a russian translation of the UWA cheat-sheet, and share it with us. You download it here, as with the English and French version!

If you happen to be interested in translating the cheat-sheet into your own language, don’t hesitate to contact us!

Share this post:

Here is a sample link: http://www.netvibes.com/share?title=Netvibes%20is%20awesome!&url=http%3A//www.netvibes.com/

The resource http://www.netvibes.com/share accepts the following parameters:

• title : Title for the shared link (my be URL-encoded);
• url : The link itself (must be URL-encoded);
• autoclose : Set it to 1 if you want the popup window to close after submission.

To URL-encode your links, you can use the function urlencode in PHP or encodeURIComponent in Javascript.

We tried to make it easy for anyone to integrate those links in any page by keeping it very simple. However, if you’re looking for turnkey solutions, some universal sharing buttons have already integrated Netvibes and you may use one of them.

Share this post:

Busy with improving your experience with UWA, that is! While you might not jump to the eyes, some of our recent efforts have been centered around giving both users and developers a stronger UWA. We did this by working at improving two critical components of a widget developer’s life: the UWA code itself, and its documentation.

Better, Faster, Stronger… and not Harder

For the last few weeks, our developers have been steadily rewiring the internal compilers for most of the supported platforms, bringing the UWA Environment at top speed, and making room for further improvements. This all happened behind the scene, but the upgrade to the compilers (iGoogle, Opera, Apple Dashboard, Live.com, etc.) should improve your every day use of UWA widgets.

Aditionnally, we used these updates to normalize behaviors across the different platforms, and incorporate a bottom status bar to maximize the spread of your widgets. Every newly-exported widget from Ecosystem will feature this bar, which we hope will help your widget reach more people.

See for instance the Web Radio Player widget, as displayed on Apple Dashboard, iGoogle, Opera and with the export tool :

As you can see, they all share the same Share button at the bottom of the widget. This is not in place in the Vista/Live.com export for now.

Also, note that all changes made to UWA are regularly backported to the open-source Exposition Widget Server.

…and easier on the eyes too!

Let’s face it, the DevNet used to be a mess of intertwined pages. That alone was bound to lose the reader’s patience, but the fact that over the years more technologies other than UWA kept being added to the documentation site (REST API, Ecosystem API, Theme format…), made for a much-needed revamping of the homepage, as well as a reorganization of all pages and a trimming of the unneeded ones.

That means a few important changes in the documentation URLs. All the documentation used to be located under http://dev.netvibes.com/doc/, but the coming of non-UWA-related docs urged us to gave each of them its own directory, as it should. There are now 3 mains sub-directories:

• http://dev.netvibes.com/doc/uwa/ : all there is to know about UWA, the Universal Widget API;
• http://dev.netvibes.com/doc/api/ : for some of Netvibes’ other APIs;
• http://dev.netvibes.com/doc/theme/ : for our Theme file format.

All the previously available docs have been moved to their respective directories. This would mean URL breakage, but we paid attention to make sure old URL would automatically redirect to the news ones. That being said, if you stumble upon any remaining ones, don’t hesitate to let us know!

Likewise, some pages of documentation have been deleted, some others created, some renamed for clarity, and most have been rewritten at least in part in order to take into account two years of UWA discussions on the forum. We’re still working on a brand new FAQ as of this typing, but all other page should be clearer yet.

Anyway, as the old song goes: “you have to admit, it’s getting better, a little better all the time”

Share this post:

2008 has been a good year: we’ve released some very cool stuffs, added some functionalities to the API, and made the code sturdier. Let’s bring on The List:

• Netvibes saw a major release, named Ginger, which quite simply overhauled everything, from code to design. UWA also benefited from this with some niceties (such as rich-icon, widget.readOnly and widget.addStar) and consequently the MiniAPI finally got put to rest.
• Our dear DevNet site got a cool new design, and the UWA Cheat-Sheet got finalized in a lovely printable form, as a companion to the one-page documentation.
• In May, we celebrated the first birthday of UWA late, with a Developer Conference where we released…
  netvibes.org: the central repository for all our open-source projects, with a proper bug-tracking tool ;
  Netvibes Platform: open-sourced UWA components, such as UWA JavaScript Runtime (to run UWA widgets), PHP Exposition libraries (to parse and compile UWA widgets) and Exposition widget server (to serve widgets to users) ;
  Full in-code documentation for all the above projects ;
  The UWA-iframe method.
• To polish our opening of UWA, we published the first working draft of the UWA specification, for everyone to implement our widget API freely ;
• Since september, designer can create their own theme for Netvibes, through an XML format ;
• Ecosystem saw the addition of a full-blown widget creator, which eases the creation of widgets based on multiple feeds ;
• And finally, as if all this wasn’t enough, we released a preview of our support for the OpenSocial API, allowing widget developers to not only have universal widget, but social too (provide the platform support OpenSocial).

All in all, this has been a very productive year, and we hope you’ve been happy with the direction we gave to UWA. Be sure that more evolution is being prepared for 2009!

Have some excellent NYE parties, everyone, and as the saying goes, “see you next year!”

Share this post: