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:

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:

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:

The ability to work on blogs, and for that matter on any website,  has always been part of UWA starting with the now-deprecated BlogWidget method. BlogWidget was a nice first try at including UWA widget within the premises of a website, but in the long run was a hassle to instal, and for us it quickly became hard to maintain.

UWA compilers have improved a lot since last year, and the release of the Ecosystem was for us a chance to push further the proverbial envelope of exporting UWA widgets. So we built UWA export right into Ecosystem, and called it Share.

Let’s say you like news so much, you want your website’s visitors to see our New-York Times widget in your sidebar. With the new Share tool, this previously laborious task has gotten very easy: go to the widget’s Ecosystem page, and click on the Share button, located next to the widget preview, right between the install links for the current 5 support platforms and the Source button, in all its orange glory.

Clicking that link brings you to a whole new tool in Ecosystem, where you can configure the look of the widget for better inclusion in your website. There, you can change the widget’s title, its height and the color of the header. While make these changes, you can see them live in the preview on the right side of this export tool, and can even update the height manually rather than using the counter.

Since exported widget do not offer an Edit section (by design), this tools lets you configure the widget’s preferences directly.

Once you are happy with the preview, you can directly grab the HTML code in the section below. As you can see it’s still pretty close to the old BlogWidget method, but believe me, it really has improved since that first version, the export tool being just the surface of it.

The most advanced among you might even find it cool to dabble with the code directly rather than through the interface…

Stick that in your website’s HTML code, at the right place, upload, reload, and you should new be the proud owner of a UWA widget on your website!

Share this post:

One of these “toys” is the expanded Timeline Search. As a Netvibes user, you must know about the User Timeline, where a user can post his good links, his favorite posts or simply his though of the moment, and let all your followers see them.

These three kinds of item can be posted to the timeline, respectively, using the Star-It widget (which uses the new widget.addStar() method, so you can also build starring within you own widgets), via a click on the little star that is displayed by some widgets (one of which is the internal feed reader, so that makes it easy for blog posts and podcasts), and the My Community widget (which you can find in the Essential Widget section of the Add Content panel). 

It’s all fine and dandy, but you might think that all this data is only available to logged-in Netvibes users who chose to follow your Universe – and therefore, quite walled-garden-y for the reste of teh intarwebs. Luckily, there’s more than that.

When we announced the Netvibes REST API a couple months ago, it already gave a lot of power to developers, like retrieving the whole content of a Netvibes Universe in XML form, but the documentation for the Timeline Search method wasn’t really complete a the time. We’ve been working towards improving it, and the result is that you can now easily use the Timeline data just about anywhere, thanks to an expanded set of options.

In short, the expanded Timeline Search makes it possible for anyone to create services or tools based on public Timeline data retrieval! Desktop apps, anyone?

The documentation itself features a handful of ideas already:

• Need to pull the 100 last public status updates in Atom format? You can do it.
• Want to know who’s been mentioning the iPhone 3G lately, and get it in JSON? Have a lookee here.
• Feel like visiting the recent favorite links of one’s followers, in XML? Here you go.
• Fan of the “FAIL” meme, and want to know who’s been commenting items with “FAIL”? Yup, can do.

This is just a part of what can be done with the REST API, and an avant-goût of things to come from our recent developments. Until we uncover these, you advise you to have a closer look at all the possibilities of the Netvibes REST API, which can offer a lot more than searching public timelines…
 

Share this post:

It was all content and code, until now: the design part of the widget is when that got little love around here until now, but truly deserve it. Once you have coded your widget and it’s full of content goodness, the best way to set it apart from other widget that display the same content, is to display it in a more attractive way.

There are many ways to design a better, and we’re going to explore some of them in this post.

Re-use your knowledge

Keep in mind that thanks to UWA being based on well-known web-standards, you can apply your CSS, table and/or font magic on your widget just as easily as you would. From this standpoint, widgets are just smaller websites: you can make use of your usual tricks of the trade, and even CSS hacks if needed, to achieve the look you need.

One thing to remember, though, is that even if your content is displayed in smaller setting that on a good ol’ website, you still don’t know the width of the container. Not only can the Netvibes user set his page to display widgets in a given number of columns (up to 4 currently), or even resize columns independently , but thanks to the portability of UWA, you widget can find itself displayed through a number of widget platforms, through the browser or on the desktop.
In short: cater for all possible width, and set up your content to display harmoniously from 320 pixels wide to 1280 or more. Use percentages wisely! If you are stuck with fixed width, at least try to keep it centered, so that it looks good even in one column.

From there on, you can apply to your widget all the good advices you might have received from classic web-design books, using the technique you feel more comfortable with: align your form elements and general content so as not to present a mess to your users, KISS (don’t overwhelm with content), balance graphics and white-space in a legible way, etc.

Use the available tools

Users have expectations when browsing online, which are set by mostly habits formed from reading other websites. Consequently, while going with a disruptive look might be tempting in order to get more attention than the other displayed widgets, the end-result will most probably be that your widget will feel out-of-place, or even ugly in comparison to other, better-fitting widgets. Sticking to the rules might therefore be a sound idea.

One set of rules that are easy to follow, is UWA’s templates and controls, a set of CSS conventions and JavaScript object built from the ground up to help your content integrate seamlessly with the Netvibes look-and-feel. More generally, they offer a quick way to get a particular design idea in place, with way less work than if you had to build it all by yourself.

It’s also important to know that using controls, such as the TabView one, doesn’t implies that you are stuck with having to deal with them at all times. Remember that the widget’s content can be entirely built and re-built on demand through JavaScript, and thus you can set up various sections or customize colors, using JavaScript and the DOM. Conditional statements such as if..else or switch..case where created for a reason.

See how the ever-admirable Rugby World Cup 2007 widget makes use of tabs only when needed: on loading, it checks wether the hidden “mode” preference is set to “details”, and displays the content accordingly.

if (widget.getValue('mode') == 'details') {
  RWC.buildTabs();
} else {
  RWC.buildPodium();
}

This means basically that only the podium is displayed on first load (no tabs).

The user can then click a “switcher” link, built dynamically using JavaScript and DOM methods & events:

// Switcher
var toggle = widget.createElement('p');
var a = widget.createElement('a');
toggle.className = 'toggle calendar';
a.setText(toggleText);
a.href = '#';
a.onclick = function() { return false; }
var setDetailsMode = function(event) {
  widget.setValue('mode', 'details');
  RWC.buildTabs();
}
toggle.onclick = setDetailsMode.bindAsEventListener(this);
toggle.appendChild(a);

The buildTabs() method then erases the whole podium, and puts the tabs (and inline pager) in place – along with a bottom switcher link, so that the user can go from one mode to the other.

From there, thanks to the flexibility of JavaScript, anything is possible…

A subtle image can do a big impression

Placing your content harmoniously, using the existing templates: it’s all fine and dandy, but while these are necessary, it doesn’t make your widget stand out in the crowd. What will make it stand out is graphic design: adding color and/or images. But as explained before, this should be done in light touches, so as not to disrupt the general flow of the page.

Again, the RWC widget is a good example of this, with a non-disturbing crop of grass at the bottom, which helps the widget to go from “plain” to “playful”.

Another such example is the recent Euro2008 widget, which also servers as a great example of some of the ways you can make use of tabs and paging in a widget.

The user-contributed TripTouch widget also features a light strip of image at the top and 4 photos at the bottom, fine details which help to personalize the widget, and consequently let the user identifying it quicker in his page.

There are many other examples of great-looking widgets in Ecosystem. We’ll make regular posts on widget design and inspiration, so that as to give you fresh ideas and make your widgets look always better.

Share this post:

A proper blogpost has already been published, summing up these releases, and most importantly the new netvibes.org website. You’ll find a lot of information over there, but keep on reading, ‘cos we have more

First, here’s the video I shot from the event, where our Chief Architect, and Head Mastermind behind UWA and netvibes.org’s projects, explains a lot about what he knows best. Watch the whole video to get a feeling of what Netvibes is offering today. It’s all in spoken French, but I took the time to put English subtitles everywhere so that everyone could understand it all.

Netvibes Platform

So there you go:

• netvibes.org is the central repository for all our open-source projects
• currently available projects are:
  • UWA JavaScript Runtime: JavaScript libraries that make it possible to run UWA widgets
  • PHP Exposition libraries: make it possible to parse and compile UWA widgets
  • Exposition widget server: makes it possible to serve widgets to users, notably within an iframe.

All these projects are available under the LGPLv3 license, which is very permissive, and are referred to as the Netvibes Platform. They are still in “technology preview” – a final version should be released in the coming months.

Along with zip-archives of the 3 projects, netvibes.org also features:

• full documentation of UWA JS Runtime (extracted from the code)
• full documentation of Exposition libraries (extracted from the code)
• the mandatory Trac, where you will be able to follow our progress, submit bug-reports, suggestion enhancements, and where some documentation will also find its place (i.e., how to run the Exposition Server).

An official Netvibes Platform forum exists for you to ask question and get support from the team and users.

What does this mean to you? Simply, it makes UWA more “universal” than ever! We read comments saying that UWA widgets working on the 8 major widget platforms (Netvibes, iGoogle, OS X Dashboard, Vista, Live.com, iPhone, Opera, blogwidget…) sure is great, but that apparently doesn’t make it universal enough…
Well, all these open-source components should help any implementer to port UWA to just about any platform, as long as it supports the usual Web standards: HTML, JavaScript and CSS. Everything is there: the Exposition widget server in order not to rely on Netvibes’ backend, the Exposition libraries in order to compile the widget to just about any of the currently supported platforms, and the UWA JS libraries so that all the client-side JS code of UWA widget works as expected.

All these components are the exact same as the ones we use. That doesn’t mean that Netvibes.com-the-startpage will be available as open-source, ready-to-install code, but it does mean that you can now handle UWA widgets your way, on your own system.

Now go download those archives, try them out, have fun with them, and let us know how we can, together, make them better!

But wait! There’s more!

There are still a few more cool things that might have gone under the radar, one of which being the official release of the UWA-Iframe method, which lets you display UWA widgets within your own environment (website, blog…), through a simple iframe. 

The UWA-Iframe method is the successor to the BlogWidget method, which lets you display UWA widget just about anywhere on the Web, using a simple iframe call to our servers. This new method is far better, and gives you full control over the way events are handled within your system.

This method has already been used in beta form by countless of projects, big or small, open-source or closed source, and it was already working quite well. Now that we have a far superior version, we are releasing it officially for all those who would like to implement widgets simply, in their system: Web portal, blogging tools, etc. For instance, the UWA implementation within JBoss Portal 2.6.3 is based on a previous version of this method.

There are a few other things cooking up, but I’ll talk about them here once a feel confident about their coherence and usefulness. For now, I’m sure you can already find plenty of code to have fun with using the above releases.

Let us know about how you would see them evolve!

Share this post: