Suite et fin heureuse d'une petite série sur les promesses non tenues de la personnalisation "long tail" du Web 2.0.
Donc, nous avons vu que le Web 2.0 tiendra sa promesse de personnalisation du contenu quand l'internaute pourra inclure ses données personnelles au sein des mashups, et que ces données d'intérêt font partie du Web invisible, le plus souvent via des petits sites qui n'exposent ni fils RSS ni APIs ouvertes.
Nous avons aussi vu que la voie est d'offrir à l'internaute un moyen de créer lui-même des widgets (appelons ça un Widget Maker, même si ce terme est déjà employé pour désigner des systèmes ingénieux mais trop complexes pour le non-technicien – Cf. Konfabulator), voie empruntée par des pionniers comme WebWag et Dapper.
Dressons un portrait du Widget Maket idéal pour mieux comprendre pourquoi ceux qui iront jusqu'au bout du Widget Maker grand public devront très probablement choisir une autre solution technique que celle des pionniers.
Les qualités du Widget Maker idéal :
1. Simplicité, ergonomie. L'interface graphique est intuitive et dénuée de jargon technique.
2. Accès au web invisible.
3. Javascript-enabled, capable de gérer entre autres des sites bourrés d'Ajax.
4. Respect de la confidentialité des données de l'internaute, en particulier de ses mots de passe.
5. Autorise une bonne montée en charge. Doit pouvoir rafraîchir des milliers de widgets par heure.
L'impasse du client léger
Le client léger s'accommode sans problème du point 1, le WOD de WebWag le démontre.
En revanche tous les autres points sont des casse-têtes si le navigateur sert de plate-forme technique (attention jargon technique).
Rafraichir les données du Widget personnel de l'utilisateur requiert d'avoir mémorisé tous les échanges entre le navigateur et le ou les serveurs Web pour les rejouer. Cela suppose d'intercepter en JavaScript les submit des formulaires, les clics sur des liens avec target=_blank, la création dynamique d'iFrame dont l'URL a été généré en javascript, les refresh asynchrones d'XmlHttpRequest, et d'autres pièges bien pointus.
Il est tout bonnement impossible d'y parvenir à 100% parce que les navigateurs sont conçus pour éviter ce type d'interception pour des raisons de sécurité : une session de navigation met en œuvre des évènements volontairement inaccessibles au moteur de script et au DOM car gérés par le navigateur. Le vrai chef, c'est le browser, pas le moteur de script, qui est aux bottes du browser. D'où les inextricables difficultés de Dapper, pourtant incroyablement astucieux.
Que des solutions
Positivons.
Points 2 et 3 (javascript, Web invisible) : pour contrôler le browser et non plus seulement la page et les scripts associés, il faut "sortir du navigateur", c-à-d le contrôler par un client "lourd" assis sur le système d'exploitation.
Point 4 : savoir que nos mots de passe sont stockés sur un serveur distant peut être un frein à l'adoption. Ok à la limite pour y laisser un relevé du montant de mon coffre-fort, mais pas les clés… Une solution est de stocker ces données sensibles (et cryptées) sur la machine de l'utilisateur, ce que les navigateurs font très mal (c-à-d très bien jusqu'à ce que l'utilisateur vide son cache), n'ayant pas accès aux disques par sécurité.
Point 5 : Même en supposant que tous les autres points aient été validés, il reste à gérer l'énorme charge en calcul que représentent des millions (bon ok des milliers) de browsers virtuels en train de rafraîchir le contenu de Widgets qui nécessitent JavaScript. Il vaut mieux employer l'astuce du peer-to-peer et du grid computing : le moteur de collecte de données est la machine de l'utilisateur.
En somme les barrières de sécurité des navigateurs rendent extrêmement risqué, pour ne pas dire impossible, la mise en œuvre d'un Widget Maker universel en client léger.
Seule une solution "desktop" peut prendre le contrôle du navigateur, stocker en confiance les données sensibles et offrir de bonnes capacités de monté en charge.
Et tout ça pour quoi ?
Tout ça pour vous dire que je travaille sur un tel projet et que je cherche des partenaires pour le mener à bien. La technologie mise en œuvre a maturé depuis 2002, date de mise en ligne de The Easy Bee, logiciel de collecte de données sur le Web qui répond aux difficultés mentionnées plus haut sans être un Widget Maker. Le logiciel s'est bonifié au fil du temps, pour preuve aujourd'hui des versions plus élaborées (non diponibles en ligne), qui reposent sur le même moteur de collecte qu'Easy Bee, sont exploitées par des clients dans le cadre de la veille sur Internet, ou pour alimenter des sites expérimentaux comme newsblogs.fr ou mashup-news.com.
Il reste à développer un logiciel spécifique basé sur cette techno, avec une chouette interface graphique : c'est un travail en cours. En avant première, voici un screenshot d'une page netvibes telle que vous ne pouvez en créer avec les outils existants car constituée de données privées issues de sites non-widgetisés (je tiens à préciser que mon compte Paypal n'est pas mon compte en banque...).
Fonctionne aussi avec iGoogle et pourrait sans ploblème être pluggé sur WebWag, BubbleTop, etc.
Serie :
La long tail des mashups encore trop short (in franglais dans the texte) --
Partie 1
La long tail des mashups encore trop short -- Partie 2
La long tail des mashups encore trop short -- Partie 3
La long tail des mashups encore trop short -- dénouement
Les commentaires récents