Jamjar est un outil collaboratif développé sur une technologie réputée très souple en termes de developpement : Adobe Flex3. Pour ceux qui l’ignorerai enciore, Adobe Flex permet le développement d’applications web variées (HTML, Php, XML, Flash, etc.), lues dans le navigateur grâce au plugin Flash.
Depuis 2 ans, Adobe redouble d’effort pour développer sa technologie en l’ouvrant largement à la communauté des développeurs. Adobe fonde de grands espoirs (surement à raison) sur l’extraordinaire potentiel de Flex/AIR dans les applications internet riches. Pour le moment, il n’existe pas réellement d’alternatives à Flex ou à AIR et Adobe profite de l’opportunité pour tenter de faire de sa technologie un standard (Flash est passé dans le domaine public en devenant un standard ISO en début d’année). Les initiatives d’Adobe se multiplient également en direction de l’implémentation du plugin Flash dans les OS mobiles.
Jamjar se situe donc dans cette logique de recherche et développement de Flex. C’est une tentative à mon sens moyennement réussie de réplication de la logique d’espace collaboratif web, habituellement développé en AJAX (si l’on peut parler d’habitude), vers la technologie Flex.
L’impression générale est celle d’un outil indéniablement puissant, mais malgré tout restreint par le logique Flex. En effet, l’environnement de développement de Flex, même s’il tente de se rapprocher de la logique XML/XHTML/AJAX, reste très traditionel dans sa logique de construction des objets. Flex Builder 3 ressemble d’avantage à une alternative de Visual Studio qu’à un hybride de Flash et d’AJAX. Cela se ressent indéniablement dans l’interface utilisateur de Jamjar.
Jamjar représente très certainement une initiative intéressante, mais on peut déceler que les applications développées en Flex et celles développées suivant une logique plus “pur” web (Ajax, XML…) ne s’épanouiront pas sur les mêmes marchés. Flex excelle certainement dans les solutions e-commerce riches, mais souffre de la comparaison lorsqu’il s’agit de wiki collaboratif.

Pour ceux qui le découvrirait, Adobe Air est une bibliothèque (runtime) qui, une fois installée sur le système, permet de lancer des applications légères construires à partir d’Ajax, de Flex ou de Flash. Ce mode d’installation nous rappelle les premiers temps du plugin Flash (voire Shockwave), ou celui-ci n’était pas installé par défaut sur les navigateurs internet. Il fallait donc un minimum de volonté de la part de l’utilisateur pour visualiser des animations Flash.
Aujourd’hui, l’utilisateur qui souhaite se servir d’applications Air doit suivre un parcours assez complexe : tout d’abord comprendre ce que Air peut proposer comme avantages, ensuite s’insrire sur le site Adobe, puis télécharger et installer AIr, et enfin se rendre sur le site Adobe Exchange pour faire son marché parmi les quelques centaines d’applications déjà disponibles.
Toutefois, le contexte a bien changé depuis les premières versions du plugin Flash. La standardisation des méthodes et l’open source ont fait leur oeuvre. Le 2.0 s’est installé dans tous les esprits. Google a modifié la donne de fond en comble.
Même si Adobe Air repose sur l’utilisation d’un framework payant (Flash), il n’a pu se maintenir vivant que parce qu’il s’est ouvert aux technologies standardisées : XML, Javascript, Ajax et XHTML. c’est grâce à celles-ci qu’aujourd’hui Adobe Air est en position de devenir le Facebook des applications légères, aussi bien pour desktop que pour mobile.
Qui voudra continuer à développer des applications basées sur des technologies fermées alors que s’ouvre la possibilité de création et d’échange au sein d’un environnement standardisé et ouvert ?