J’ai publié il y a quelques semaines un widget Jaiku dans l’écosystème Netvibes. Autrement dit, on peut désormais interagir avec le sous-employé Jaiku depuis son compte Netvibes en levant à peine le petit doigt.

La réalisation de ce widget était pour moi l’occasion de réaliser mon premier widget utilisant la plateforme UWA : un développement rendu compatible pour plusieurs plateformes dont iGoogle, MacOS X Dashboard, Windows Live etc.

Présentation du widget Jaiku pour Netvibes

Avant de rentrer dans les détails techniques, faisons ensemble un petit tour de ce qu’est capable de faire le widget Jaiku. Rien de bien méchant puisqu’il fait ce qu’on veut : lire et envoyer les messages. Faut savoir rester simple

Widget Jaiku pour Netvibes

Je ne me cacherai pas que je me suis largement inspiré du widget Twitter pour Netvibes au niveau de la présentation tout en ajoutant ma touche personnelle.

L’écran de connexion accueille directement avec des champs identifiant et mot de passe pour faciliter son utilisation. Pas besoin d’aller fouiller dans les options. Un petit confort on dira.

L’entête contient ce qu’il faut pour envoyer des messages : votre lieu de présence et le champ de saisie. Le compteur de texte se met à jour à chaque caractère saisi et surtout, votre saisie n’est pas bloquée une fois que vous atteignez la limite. Il n’y a rien de plus pénible que ça.

Le gros du morceau réside dans les onglets : pour une fois vous pouvez facilement naviguer d’une ligne de temps à une autre. Choisissez les messages de vos contacts, les vôtres (un peu narcissique non ?) ou encore les messages publics.
Les 3 onglets sont paginés à la convenance de l’utilisateur, de 1 à 20 messages par page.

J’ai ensuite agrémenté de plusieurs fonctionnalités que j’apprécie à l’usage (à vous de me dire si c’est aussi le cas) :

• possibilité de répondre à un message en pré-remplissant le champ de saisie avec ce qu’il faut (et ce que l’API Jaiku permet de faire …)
• icône signalant l’origine des messages affichés (flux RSS, Twitter, Last.fm etc.)
• filtrage de ses propres messages : vos messages n’apparaîtront pas dans la ligne de temps des contacts (ce qui en soit n’est pas plus mal)
• formattage des messages avec une meilleure reconnaissance de URL que le widget Twitter et surtout, une reconnaissance des noms d’utilisateurs (@utilisateur) et des noms de canaux (#canal) … vous permettant de leur répondre en cliquant sur leur nom

Il resterait encore pas mal de choses à faire mais on arrive malheureusement assez rapidement aux limites des 2 services.

L’API Jaiku

L’API Jaiku est très bien mais un peu chiche en services.

Le nombre de flux en récupération est suffisant : contacts, messages, informations personnelles.
En revanche les méthodes d’envoi sont limitées et pour cause, il n’y en a qu’une : envoyer un message.

Il ne manque pas grand chose pour qu’on puisse tout faire :

• obtention de la liste des icônes personnalisées
• préciser à quel message on adresse une réponse (pour éviter de casser les discussions)
• une gestion de messages privés (et les flux qui vont bien)
• une API qui ne souffre pas d’autant de délai … parfois il faut attendre 3 heures avant d’avoir un flux actualisé. Pas pratique pour de la messagerie en temps quasi-réel

Ces demandes ont été faites mais bon, il faudra attendre la relance de Jaiku avec Google App Engine … très bientôt visiblement.

Et du côté de Netvibes ?

Le développement du widget repose sur l’API UWA de Netvibes et donc par conséquent, c’est du développement 99% JavaScript.

Heureusement tout n’est pas à faire puisqu’UWA fournit une base d’outils et quelques fonctionnalités natives comme la pagination ou les onglets.

Quels avantages à utiliser Netvibes UWA ?

La spécification UWA permet donc à partir d’un développement unique de le porter sur d’autres plateformes de blogs en un minimum d’efforts (très souvent aucun). Il faut savoir qu’à chaque plateforme de widget il y a une manière de développer différente.

Alors plutôt que de parier sur un cheval, avec UWA, on peut parier sur tous. Et ne faire qu’un seul développement.

Le développement d’un widget aboutit très généralement à l’ajout dans l’écosystème Netvibes. Le widget se retrouve ainsi à la portée de toutes les pages de démarrage par le biais de son moteur de recherche intégré.

Côté développement, tout reste globalement simple quand on veut faire du simple.

Mais quelle galère à développer avec Netvibes UWA …

En revanche ça devient beaucoup moins drôle quand on tombe sur des besoins mal couverts par la documentation.
Et quand je dis mal couvert, ça inclut :

• pas de documentation du tout
• une documentation partielle et pas suffisamment verbeuse (genre pour les onglets et la pagination)
• une documentation obsolète et pas recommandée de leur propre aveu (le stockage des mots de passe)

L’adoption d’un service et sa qualité se jugent à mon avis par sa documentation. Certes des efforts sont faits mais leur API deviendra crédible et fiable le jour où elle sera à jour et complète.

En plus de ça, certaines fonctionnalités sont elles aussi incomplètes.

Au hasard, le processus de l10n : à implémenter soi-même et encore, il ne pourra pas couvrir tous les besoins comme les préférences. C’est d’autant plus dommage que leur système est particulièrement au point pour l’interface traduite en une dizaine de langues.
Mais pas les widgets …

Toute à l’heure j’évoquais les mots de passe. Il y a bien un mécanisme qui permet de les stocker mais il agit comme il veut : on ne peut stocker qu’un mot de passe par widget et surtout, on ne peut pas l’utiliser autrement que dans le cas d’une identification HTTP.
Autrement dit, le stockage d’un clé d’API se fera dans un champ texte standard.

Ça ne serait pas gênant si la plupart des widgets étaient exécutés dans une iframe et que cette dite iframe embarquait dans l’URL toutes les préférences enregistrées. Donc votre clé d’API.
Pourquoi c’est gênant ? Car il y a un mécanisme inhérent à tout navigateur Web qui s’appelle le Referrer. En clair, quand vous affichez une page, votre navigateur envoie l’adresse de la page appelante.
Je me passerai du dessin …

Enfin, et pour terminer sur une note un peu moins noire, l’environnement de développement est un superbe outil pour tester son widget de manière indépendante. C’est à dire sans se connecter sur netvibes.com.
Enfin là où le bas blesse c’est que les comportements et la présentation sont différents entre l’environnement de développement et Netvibes.

Ce qui sous-entend des bugs présents en développement et pas en production, la gestion des mots de passe qui diffère en développement de la production et du paramétrage spécifique pas documenté.

Proxy local pour widget Netvibes

Le proxy de développement Netvibes indiqué dans la FAQ est fonctionnel mais trop minimaliste. On peut en effet récupérer les données mais dès qu’il s’agit d’en envoyer, c’est cuit.

J’ai donc adapté le proxy du Yahoo! Developer Network à mes besoins en ajoutant plusieurs fonctionnalités :

• mise en cache des requêtes GET pour accélérer les chargements de page et éviter de cramer trop de requête auprès de fournisseurs les limitant (qui a dit Twitter ?)
• transmission des données POST ; c’est ce qu’il manquait le plus à la version fournie par Netvibes
• compatible texte/JSON/XML ; le proxy renvoie les bonnes entêtes en fonction de la demande

<?php
define('CACHE_TTL', is_int($_GET['cache']) ? $_GET['cache'] : 3600);
define('CACHE_FOLDER', dirname(__FILE__).'/cache');
//
$session = curl_init($_GET['url']);
// If it's a POST, put the POST data in the body
if (isset($_POST) && !empty($_POST))
{
  $postvars = '';
  while ($element = current($_POST))
  {
    $postvars .= key($_POST).'='.$element.'&';
    next($_POST);
  }
  curl_setopt ($session, CURLOPT_POST, true);
  curl_setopt ($session, CURLOPT_POSTFIELDS, $postvars);
}
// Play with some cache
$md5sign = md5($_GET['url'].$postvars);
$md5file = CACHE_FOLDER.'/'.$md5sign;
/*
 * Read cache
 */
if (file_exists($md5file) && filemtime($md5file)+CACHE_TTL > time())
{
  curl_close($session);
  send_headers_content_type($_GET['type']);
  readfile($md5file);
  exit();
}
// Don't return HTTP headers. Do return the contents of the call
curl_setopt($session, CURLOPT_HEADER, false);
curl_setopt($session, CURLOPT_RETURNTRANSFER, true);
// Make the call
$output = curl_exec($session);
$fp = fopen($md5file, "wb+");
fwrite($fp, $output);
fclose($fp);
send_headers_content_type($_GET['type']);
echo $output;
curl_close($session);
/*
 * Functions
 */
function send_headers_content_type($type)
{
  // Set the Content-Type appropriately
  switch ($type)
  {
    case 'text':
    default:
      header("Content-Type: text/plain");
    break;
    case 'xml':
      header("Content-Type: text/xml");
    break;
    case 'json':
      header('Content-Type: text/x-json');
    break;
  }
}
?>

En revanche, je serais vous, j’éviterais de m’en servir publiquement car il n’y a aucune vérification de sécurité donc à moins que vous ayiez envie de servir de relais à spam, le mieux est de n’utiliser ce proxy que sur une instance locale ou bien de davantage le blinder.

Conclusion

On arrive désormais au terme de ce billet fleuve

Quoique je puisse en dire, Netvibes UWA est quand même fort sympathique et permet d’aboutir à des temps de développement assez courts une fois la majorité des problèmés rencontrés. Nul doute que votre premier développement sera le plus compliqué. Surtout si comme moi vous avez envie de tout utiliser : pagination, onglets et AJAX à droite à gauche.

Dans tous les cas, une bonne conception de l’application vous sauvera la mise et évitera trop de réécriture de code.
L’implémentation de la pagination et des onglets est particulièrement douloureuse si vous n’utilisez pas de programmation objet. Soyez-en avertis.

Je me suis personnellement bien amusé à développer en utilisant UWA et en jouant avec l’API Jaiku. Cette dernière met vraiment l’accent sur le JSON ce qui est très pratique pour manipuler des données distantes de manière minimaliste.

Une fois que ces 2 plateformes arriveront à maturité, il y aura de quoi faire d’encore plus belles applications.

N’hésitez pas à utiliser Jaiku sur Netvibes, à me laisser vos remarques et à partager votre expérience de développement de widgets si le cœur vous en dit

Cela fait maintenant plus d’1 an que j’utilise Twitter. Passée l’appréhension du gadget puéril, je l’ai finalement converti en outil de communication, de réseautage et de veille … comme beaucoup de ses utilisateurs d’ailleurs.

Seulement voilà, les pannes à répétition sont, à mon sens, en train de ruiner un service qui aurait pu être encore plus ravageur qu’il ne l’a été. Plusieurs concurrents s’y sont essayés, aucun ne l’a encore détrôné.

À part peut-être Jaiku, si Google réussit son coup.

Jaiku, Twitter : micro-blogs et/ou messagerie instantanée délocalisée

Entre messagerie instantanée asynchrone et micro-blogs, mon cœur balance.

Toutefois le dénominateur commun de Twitter, Jaiku, Plurk, Pownce et toute la clique ce sont les messages en 140 caractères adressés au monde entier.
En soi c’est assez amusant de constater que cette limite a été adoptée pour tenir sur 1 SMS (tant en envoi qu’en réception) … alors que nous sommes sur le Web. Cet exercice aura le mérite de favoriser le partage d’URL et d’améliorer l’esprit de synthèse de beaucoup.

Malgré tout mon enthousiasme pour Twitter, je n’ai pour l’instant envie que d’une chose : un service stable. Autrement dit :

• des flux RSS / une API qui répond 99,9% du temps : quand je regarde mes twit une fois par heure et que je constante une désespérante « erreur inconnue » dans le widget Netvibes … no comment
• un service qui ne s’effondre pas une page sur 2 en plein milieu de journée
• un service qui communique sur ses problèmes : déjà 3 semaines que le client IM est hors-ligne. C’est pourtant le deuxième client Twitter le plus utilisé

Pourquoi Jaiku est mieux que Twitter

Jaiku ne bénéficie pas du même engouement que Twitter, peut-être pas à tort. Son adoption a été fortement freinée par le rachat de Google en 2007. Ce rachat a placé Jaiku en inscription sur invitation.
Parallèlement à ça, très peu de nouveautés ont fait leur apparition sur le service.

Et avec ça je tente de vous convaincre que Jaiku est mieux ? Et pourtant :

• automatisation de l’intégration de vos flux (RSS, Twitter, Last.fm etc.) avec une présentation des plus sympathiques (exemple ci-dessus avec Flickr, mon service photo préféré)
• une interface Web beaucoup plus agréable : identification facile des source des données, différenciation de nos messages et des flux aggrégés, filtrage des sources de flux
• une API plus sécurisée : parce qu’il ne faut jamais, ô grand jamais donner son mot de passe, cette hérésie est remplacée par une clé unique (mais malheureusement pas regénérable)
• les « channels » ou groupes de discussion. Ils facilitent la création de conversation liées à une thématique ou à des sites/services Web. Pratique pour éviter la schizophrénie du multi-compte.

Pourquoi Twitter est mieux que Jaiku

Malgré tout, Twitter possède une bonne avance, notamment grâce à son énorme base d’utilisateurs :

• immense parc d’applications, tant en terme de mashups que de clients pour twitter. Au hasard : TwitBin, Thwirl, TwitterVision, Summize, TwitterShare, TwitLinks etc.
• une API simple et complète (mais du coup, pas sécurisée : donner son mot de passe n’est pas recommandable)
• une prise en main immédiate : pas de fioriture, tout est simple
• fonctionnalité de veille sympathique : « track ». Recevez tous les twit qui contiennent tel ou tel mot
• affichage affiné avec la possibilité de n’afficher que les réponses qui nous sont faites (@replies)

Comment Jaiku peut surpasser Twitter

Twitter conserve fonctionnellement pas mal d’avantages qui justifient encore son utilisation et sa forte adoption. C’est en subissant les pannes répétées et en lisant plusieurs articles, dont «Can Twitter Be Saved» que j’ai sérieusement mis en doute la capacité à Twitter à accompagner ses utilisateurs de manière pérenne.

Jaiku n’avance plus certes mais en surface uniquement. Si Google est malin tout autant que les créateurs de Jaiku, ils ont toutes les clés pour détrôner Twitter et transformer l’essai.
Voici ce que j’aurais aimé voir sur Jaiku pour migrer définitivement dessus :

• une interface internationalisée (i18n) pour faciliter l’adoption dans tous les pays et éviter de laisser l’outil entre les mains des seuls geeks
• intégration d’un ou plusieurs outils au choix de compression d’URL, comme is.gd ou tinyurl
• import de contacts depuis Facebook, Twitter et pourquoi pas, son carnet d’adresse Gmail (par l’API bien sûr)
• forte intégration dans Google (Google News, Google Alerts, Gmail, Google Calendar, Google Talk/Jabber, iGoogle et widgets etc.)
• utilisation de l’infrastructure Google (on parle d’App Engine entre autre)

Après, ma seule crainte ce sont les habituels travers de Google, abandon de service, manque de suivi et opacité de service.

Je garde bon espoir pour Jaiku. À tel point que je suis même en train de produire un widget Netvibes pour Jaikuter depuis n’importe où