Opening Keynote Session

Session commune d'ouverture, par Ken Bisconti, vice président des produits Workplace, Portal et de collaboration. Ken a présenté l'état des produits actuels et la stratégie d'IBM sur ce créneau. A noter que Workplace désigne désormais toute la panoplie de logiciels "collaboratifs" d'IBM (Lotus Domino, Websphere Portal, Lotus Sametime, Lotus Quickplace) et que le nom "Workplace" va être retiré au fur et à mesure des produits éponymes. D'ailleurs, à propos desdits produits, strictement aucune mention pendant cette journée (edit : ni pendant cette seconde). Serait-ce un aveux d'échec ? Une grande partie de son intervention a consisté à faire une démo du client lourd Sametime 7.5 (Lotus Sametime Connect 7.5) tel qu'il est utilisé chez IBM, et il faut avouer que c'est plutôt impressionnant. Ce produit qui, je le rappelle pour ceux qui ne connaissent pas, est une solution de messagerie instantanée d'entreprise, va beaucoup plus loin que la version précédente. Look plutôt agréable (des dégradés à la Office 2003 et des couleurs pastel à la sauce web 2.0), a priori très intuitif, et en dehors des fonctionnalités "classiques" de messagerie instantanée (présentiel, voix, vidéo, conférences et partage d'écran), ce qui s'est avéré le plus bluffant est son extensibilité : tout est programmable à souhait. De nombreux exemples ont été présentés, de l'insertion dans une discussion du chiffre d'affaire d'un secteur particulier (interrogation via des services web) à la localisation d'un groupe de contacts sur google maps, en passant par la création de sondages instantanés.

Le secret ? Il repose sur Eclipse qui, en dehors d'être un IDE de développement, est surtout devenu un framework de développement d'applications riches. A ce titre, IBM mise sur l'ouverture et un toolkit ainsi qu'une API riche sont mis à la disposition des développeurs. Le produit doit finalement être perçu comme un framework pour développer la collaboration dans son entreprise, plutôt qu'une solution figée et fermée de messagerie d'entreprise (comme c'était le cas jusqu'à la version 7.0, au passage). Et honnêtement, on a super envie d'y croire, car ils ont mis le paquet et ont l'air d'avoir fait les choses vraiment bien. Ah, et un client Sametime pour mobiles (Windows Mobile, Blackberry et Symbian) doit être livré prochainement. C'est le premier produit de la gamme Lotus à franchir le cap vers Eclipse, mais manifestement tous les autres vont suivre. A commencer par Hannover dont vous avez tous vu des screenshots et qui devrait débarquer Q2 2007, mais aussi par Quickplace, probablement pour la version 9.0 (soit pas la prochaine).

L'autre partie de l'intervention a consisté à présenter des nouveaux concepts introduits dans Quickplace 8.0, ce que je n'avais d'ailleurs pas compris hier quand j'ai rédigé tout ceci, du coup, j'ai supprimé et je reviendrai là dessus lors de mon futur billet sur la seconde journée (comme quoi publier en décalé peu aussi éviter de raconter des conneries).

Une intervention très intéressante donc, peut-être l'une des plus de cette journée. La moins technique, aussi.

QP101 : Quickplace installation and configuration

Avant d'évoquer la session en elle même, voici pour ceux qui ne connaissent pas une brève introduction à ce qu'est Lotus Quickplace. Il s'agit d'un produit web collaboratif (reposant sur Domino) particulièrement intéressant dans la mesure où il se situe à mi-chemin entre le wiki totalement libre (destiné essentiellement à la population IT) et l'application conventionnelle avec des rôles prédéfinis très stricts et des workflows tout aussi carrés. Lotus Quickplace permet à n'importe quel utilisateur (du moment qu'il en a les droits) de créer des "places" rapidement (d'où le nom du produit), dans lequel il va pouvoir configurer les droits d'accès, mettre au point rapidement des formulaires (soit avec un wizard, soit depuis un document office qui sera présenté en web, soit avec un formulaire HTML fait à la main) avec éventuellement des workflows simples, des calendriers partagés, de la gestion d'activité, du partage de documents, etc. Bref, c'est un produit super intuitif (et rempli jusqu'à ras bord d'ActiveX) qui permet aux utilisateurs de gérer un projet de taille modeste et limité dans le temps. Et ce sans la moindre intervention de l'informatique. De ce que j'ai pu en voir, mais aussi entendu de mon coté, Quickplace remporte pas mal de succès auprès des utilisateurs. A noter aussi que Quickplace propose un mode offline qui permet donc de bosser totalement déconnecté (j'imagine que c'est basé sur DOLS).

Première session technique donc, dans laquelle fut présentée en 1h15 comment se passe l'installation et la configuration de Quickplace, et les travers dans lesquels ne pas tomber. Furent passés en revue les problématiques d'annuaire (LDAP ou annuaire Domino), la configuration du fichier qpconfig.xml, du notes.ini et du document serveur Domino. Je n'ai jamais installé Quickplace ni ne me suis jamais confronté à de problèmes d'administration, alors j'ai trouvé ça plutôt intéressant, même si j'imagine que ceux qui connaissaient déjà ont du trouver cela un peu rébarbatif.

ST102 : Extending Sametime to the web with ST Links toolkit

Cette session a détaillé la mise en place du toolkit "web" de Sametime : permettre d'afficher l'état d'un utilisateur dans une page web, mais aussi de le contacter directement et démarrer une discussion (ce qui se traduit par l'ouverture d'une pop-up avec une fenêtre de chat), et enfin par la mise en place d'un système de pooling rudimentaire (dans l'exemple, pour gérer le support d'un quelconque service via un lien du type "contactez-nous" qui pourrait contacter en interne l'une des personnes de la hotline, selon la dispo). Le tout passe par une applet Java transparente qu'il convient de charger au démarrage des pages (et de cliquer sur le traditionnel "Toujours faire confiance à IBM" la première fois qu'on la charge).

Si sur le plan fonctionnel c'était très intéressant, j'ai été attéré par la mise en oeuvre technique et le code présenté. En 2006, voir des <SCRIPT>document.all.foo = quelquechose ; showModialDialog("...");</SCRIPT> <BR /> <BR /> est assez effrayant (oui, c'est de l'HTML 4.01, mais ça fait bien de fermer les balises BR). Surtout quand on revient d'un Paris Web 2006 les yeux pleins de standards, de bonnes pratiques et d'accessiblité. Au final, la magie s'est en grande partie envolée quand j'ai vu le code derrière, qui repose principalement sur du masquage des blocs (via CSS, même pas retiré du DOM, non non) selon la connectivité d'une personne, avec du code bien crade à la sauce d'il y a 7 ou 8 ans. Malheureusement, je ne sais pas s'il y a grand chose à y faire, car c'est l'API javascript de Sametime qui est a priori à remettre en cause. Mais bon, les fonctionnalités proposées sont malgré tout vraiment intéressantes, il va donc falloir faire avec.

QP201 : Quickplace Custom Themes

Cette troisième session technique avait pour but de présenter la mise en place de thèmes personnalisés avec Quickplace. L'idée est qu'un thème est constitué d'un fichier CSS et de 5 pages HTML (une pour le mode consultation, une pour le mode édition, et 3 autres dont je n'ai pas bien compris l'utilité, mais qui manifestement n'en avaient pas beaucoup). Au contraire de Domino, il s'agit ici de templates, comme on peut en retrouver du coté de Java ou de PHP. Quickplace propose ainsi un certain nombre de tags spécifiques (QuickPlaceSkinComponent) qu'on insère dans des templates HTML qui seront ensuite parsés à la volée, par exemple pour afficher des boutons d'action selon les droits, générer à la volée un menu ou encore afficher le titre de la place. Ces tags ressemblent un peu à JSTL, si ce n'est qu'ils ne respectent pas la syntaxe XML, et que j'avais rarement vu un truc aussi tordu (jetez un coup d'oeil à l'attribut replaceString : c'est du bonheur). Le cas d'école présenté par Viktor est assez amusant : l'attribut postfixHTML, qui permet de spécifier du code HTML affiché après le contenu généré par le tag (uniquement si le tag génère quelque chose, bien entendu), peut prendre par exemple la valeur <br>. Ainsi, si le tag ne génère rien, ça évite un retour à la ligne inutile. Une curieuse façon de gérer les marges.

De même, l'éventuelle CSS personnalisée est en réalité ajoutée au bout de la CSS délivrée automatiquement par Quickplace. Du coup, si on veut vraiment personnaliser son thème, il faut surcharger toutes les classes définies préalablement par Quickplace, parfois à coup de !important, pour éliminer complètement les résidus du thème initial. Sans compter que la CSS fait le double de poids, et pour rien. Complètement stupide, mais on n'a vraiment pas le choix, puisque le thème s'installe par un wizard dans lequel on va chercher chacun des fichiers par drag'n drop.

Bref, moi qui me faisait une très bonne image du produit, j'avoue avoir été clairement déçu par moyens proposés de personnalisation (ce qui toutefois ne retire au produit aucune qualité que j'ai cité précédemment). On sent fortement l'héritage Domino et les hacks à la con qui vont avec.

QP202 : Developing QuickPlace applications with HTML and Javascript

Quickplace, comme je l'ai dis, c'est bien pour faire des applications simples rapidement, et notamment des formulaires, sans le moindre code (via un wizard ou depuis des documents Office, mais j'ai l'impression de me répéter). Mais il y a aussi la possibilité de faire des formulaires HTML, pour aller un peu plus loin que le wizard : par exemple pour faire des listes de sélection dynamiques depuis les documents d'un autre formulaire Quickplace. C'était donc là l'objet de cette session.

Honnêtement, je sais pas trop par où commencer, tant je reste sans voix par tant de bêtise. Dans l'idée, on réalise une page HTML qui va contenir le formulaire HTML, on la glisse dans Quickplace (dans lequel on avait quand même pris soin de se placer sur la création d'un formulaire HTML), et basta, c'est devenu un formulaire Quickplace (par analyse des balises input, select et textarea de la page). Dis comme ça, ça n'a pas l'air si bête. Oui mais attendez. Si ce n'était que pour ça, on aurait pu utiliser le wizard. Le fait de pouvoir faire son propre code HTML permet d'y insérer sa tambouille, et c'est là que le drame commence. Troy nous a donc présenté un formulaire HTML avec un workflow plus avancé que ce que permet nativement Quickplace, dans lequel il initialise des listes déroulantes via des requêtes AJAX - le genre de truc qui me fait tiquer, mais qui est encore passable -, mais surtout dans lequel tout son workflow et sa sécurité inhérente est basée sur du javascript et du masquage de blocs en CSS. L'utilisateur n'est pas valideur et ne doit pas voir le bouton d'action pour valider ? Masquons le joyeusement avec un style="display:none". Et l'action de validation proprement dite ? Ne nous posons pas de question, et appelons dynamiquement un agent en lui passant le DN de l'utilisateur valideur en query string (et sans vérification coté serveur bien entendu). Ce n'est pas bien grave, me diriez-vous ? Dans le cadre d'un intranet, peut-être (et encore). Mais ces gens font des applications qui sont exposées sur Internet. Je ne peux pas croire qu'on puisse faire ce genre de chose et en être assez fier pour le présenter (et l'enseigner) publiquement. Un joli palmarès de toutes les mauvaises pratiques que je peux imaginer.

Sans compter que l'outil semble assez mal adapté pour ce genre de choses. Une preuve ? On peut aisément imaginer avoir besoin de fichiers externes (une ressource javascript, par exemple) dans son formulaire. Le problème, c'est qu'un formulaire HTML dans Quickplace, c'est un fichier HTML accompagné d'éventuelles images (analyse du code du fichier HTML pour les embarquer directement). Alors comment faire pour embarquer une ressource javascript dans un formulaire HTML Quickplace ? Et bien trompons le parser en ajoutant des <img src="monscript.js">, nous répond-on. Sincèrement, WTF ??!

Vous savez quoi ? vous pouvez essayer de faire rentrer un hamster dans un tube d'aspirine. Je suis même sûr qu'avec un peu d'effort vous y arriverez. C'est la même chose avec les formulaires HTML de Quickplace. Ce produit fait de belles choses, mais jusqu'à preuve du contraire, n'est pas fait pour ça (comme un hamster, ce n'est pas fait pour rentrer dans un tube d'aspirine). C'est dans ce genre de situation qu'on est super frustré de ne pas parler couramment anglais pour en toucher deux mots aux intervenants.

ST750 : Integrating your applications with Sametime Connect 7.5

Dernière session de la journée, et pour finir sur quelque chose d'un peu plus léger après une journée bien chargée, Matthew Perrins d'IBM avait la (lourde) tâche de nous présenter le développement de plugins pour Sametime Connect 7.5 (ceux qui ont été présentés le matin même) au travers d'Eclipse et avec le toolkit Sametime fourni. Objectivement, sa conférence a remporté assez peu de succès, car dans toute l'assemblée (une petite cinquantaine de personnes) à peine 4 ou 5 personnes connaissaient Java (moi y compris). Sa tâche n'allait pas être facile, me disais-je .Et je ne m'étais pas trompé.

Matthew a commencé par nous montrer l'extensibilité de Sametime Connect (qui est très extensible, l'ai-je déjà dis ?), de l'UI jusqu'à ajouter de nouvelles fonctionnalités, et tout allait très bien jusqu'au moment où il a ouvert Eclipse et montré les fichiers de configuration des plugins. C'est à ce moment, je crois, qu'on a commencé à perdre une bonne partie de la salle. Il a ensuite continué par montrer le code proprement dit, et si je me rappelle bien, c'est là qu'on a perdu la partie restante. A l'exception des 4 ou 5 qui avaient déjà eu l'opportunité de travailler avec J2EE, et qui se disaient probablement qu'on était pas sorti de l'auberge. Que dire : de la configuration via des fichiers XML à outrance, une API probablement composée de 3 tonnes de classes et - ma main au feu - des remontées d'exception sur 15 niveaux pour que ça affiche une boite de dialogue d'erreur à l'utilisateur. Un projet Java classique, en somme. Pour essayer de rester un tant soi peu objectif (oui, je suppute beaucoup), je ne sais pas, je n'ai pas vu le toolkit, mais je ne pense pas être très éloigné de la réalité. A la décharge de Matthew, le code était assez conscit, ce qui laisse présager malgré tout quelque chose d'assez carré et bien pensé. Mais bien pensé en Java (et surtout chez IBM), c'est souvent assez éloigné de l'image que se font la plupart des gens de quelque chose de bien pensé.

Devant l'apparente crainte de l'assemblée vis à vis de la technologie mise en oeuvre, Matthew a conclu sur un magnifique "Oh vous savez, vous connaissez Lotusscript, vous connaissez Javascript, ben Java, c'est pareil, avec des objets". J'ai dû me retenir pour ne pas exploser de rire. Ne me faites pas dire ce que je n'ai pas dis : le produit à l'air brillant et je suis plus que convaincu de son potentiel, mais soyons sincères deux secondes, dire à des développeurs qui ne connaissent que Notes/Domino et le LotusScript que la transition va être facile, il fallait oser.

Sur le coup, j'ai voulu lui demander pourquoi IBM n'avait pas choisi XUL plutôt qu'Eclipse. Ils auraient ainsi pu tirer parti des connaissances actuelles de la communauté des développeurs Domino (en l'occurence l'HTML et le javascript) plutôt que de leur imposer un nouveau langage, et auraient fait d'une pierre deux coups : un client pour le desktop, et une application web. Mais cela n'aurait pas changé grand chose ; le choix d'IBM est clair, et c'est Java.

Bilan de cette première journée

Cette première journée fut l'occasion d'apprendre plein de choses. Je vous ai fait part de mes impressions, mais pas de ce que j'y ai appris. Et c'était très riche, ce qui est un point très positif (et vu le prix que ça coûte, l'inverse aurait été dommage). J'ai hâte de voir ce que ça va donner demain, le programme est pas mal non plus.

Sinon, vous avez noté le grand absent ? Moi en tout cas, ça m'a marqué. Avec Sametime 7.5, pas une seule innovation coté web. Où est passé le client léger Sametime super sexy et à base d'AJAX que j'attendais ? Et les réunions et partages d'écran depuis son navigateur à l'aide de quelques ActiveX ? Rien, quenéni. Et d'ailleurs, si j'ai bien compris, l'ancien client web à base d'applets Java n'est plus distribué, il faut chopper celui de la version précédente (point à confirmer demain). Et le toolkit "SameTime Links" (voir ST102) est bien, mais pas vraiment nouveau, et franchement, quand on voit l'énergie déployée sur le client lourd, j'ai du mal à croire qu'il n'y avait pas moyen de faire mieux.

Stratégie d'IBM surprenante ? En tout cas, IBM semble réinvestir le desktop au détriment du web, comme l'atteste ce Sametime 7.5. Du coup, je m'interroge sur Hannover : va-t-il apporter l'innovation web que l'on attend tous ? Pas sûr, car finalement Hannover est un nouveau client, pas un nouveau serveur. En tout cas, on en a vu que des screenshots, et IBM à ma connaissance n'a pas vraiment communiqué sur les nouveautés coté Domino (je poserai la question, tiens). Je suis perplexe. Peut-être que ce n'est pas le cas aux US ou ailleurs, mais en France, je n'ai pas vraiment l'impression que la tendance est aux clients lourds. Et il est encore un peu tôt pour les mobiles. La suite demain donc, avec peut-être quelques éléments de réponse supplémentaires...

Suite : Compte rendu de la seconde journée