Vaadin : la synthèse de deux mondes ?

Que l'on soit éditeur de logiciels, ou responsable applicatif au sein d'une DSI, on se retrouve souvent confrontés aux mêmes problématiques. L'une d'entre elles est de faire accepter ses logiciels par leurs utilisateurs. A ce stade, l'interface graphique, son ergonomie, sa réactivité - en bref, tout ce que l'on désigne aujourd'hui sous le terme d'expérience utilisateur - joue un rôle déterminant.

Pour développer des IHM, il y a deux stratégies : les clients lourds et les clients légers.
Les clients lourds, malgré l'étiquette de technologies dépassées qui leur collent maintenant à la peau, ont encore beaucoup de qualités : richesse des composants disponibles, fluidité d'exécution, robustesse, possibilité de créer des applications MDI. Du point de vue du processus de développement également, les clients lourds ont de nombreux avantages : même langage de développement que pour la partie métier, existence d'un IDE fourni par l'éditeur, possibilité de débugger le code de la couche présentation (!!!).

Du côté des clients légers, il y a probablement moins d'avantages, mais l'un d'entre eux, essentiel, a fait leur succès dans les entreprises : l'absence de déploiement préalable à l'utilisation sur les postes clients. Par extension, ce point permet également de simplifier la maintenance de l'application pendant toute la durée de son exploitation. Souffrant de trop nombreux handicaps les clients légers laissent peu à peu la place aux clients riches. Dans la longue liste de frameworks de RIA l'un d'eux semble avoir réussi la synthèse optimale du client lourd et du client riche : il s'agit du framework Vaadin de la société IT Mill.

Vaadin est une framework de développement d'applications Internet riches fournissant des composants graphiques et des contrôles accessibles au travers d'une API particulièrement bien conçue. Mais la singularité de Vaadin réside dans son architecture, orientée serveur, ainsi que son mode de développement qui se fait à partir d'un unique langage, Java. En fait, avec Vaadin, on ne pense plus serveur web/navigateur/requête HTTP, mais on pense comme lorsque l'on développe en client lourd : on crée des composants, on les rattache à des conteneurs, on leur lie des évènements, des sources de données, et c'est le framework qui se charge de générer le code HTML/JS/CSS nécessaire (il s'appuie pour cela sur GWT), ainsi que de gérer (de manière optimale, grâce à un UIDL propriétaire) les appels Ajax permettant les échanges de données entre le serveur et le client.

Avec mes collègues, nous avons utilisé Vaadin pour réaliser le prototype d'une application de traitement et de validation de factures, avec dans l'idée de remplacer à terme une application plus ancienne développée avec une framework maison basé sur des pages JSP et quelques soupçons de jQuery ça et là.

Après quelques mois d'utilisation, mes impressions sont les suivantes :
- Pour ceux qui ont déjà réalisé des applications en client lourd (que ce soit en Swing, en C# ou en Delphi), le temps d'adaptation à la philosophie du framework est quasi nul. Lorsque l'on se surprend à débugger son code métier et son code présentation en une seule passe, on oublie vraiment que l'on est en train de générer une application web !
- Vaadin s'exécute à l'identique sur Chrome, Firefox et Internet Explorer (8). Il propose un rendu des composants au look sobre, très professionnel, assez proche de Flex, même s'il est vrai que la bibliothèque de composants est moins fournie que celle d'Adobe,
- Vaadin est beaucoup plus facile à utiliser que GWT, car il n'impose pas de séparer les classes serveur et les classes client lors du développement. De plus, Vaadin n'est pas sujet aux lenteurs de compilation propres à GWT,
- La communauté est très active, les documentations sont de qualité et les corrections de bugs sont fréquentes. Nous avons rencontré un seul bug, il s'agissait d'une fuite mémoire. Sa correction a été publiée la semaine dernière.
- La bibliothèque d'add-ons est encore mince, mais elle s'enrichit de semaine en semaine,
- La plupart des composants de Vaadin supportent le drag'n drop.
- Vaadin possède des dizaines d'autres fonctionnalités toutes plus intéressantes les unes que les autres : support de nombreux serveurs d'applications, du portail Liferay, projets Maven, intégration avec Spring, intégration de widgets GWT...

L'image ci-dessous montre un widget GWT que nous avons développé pour visualiser des factures. Il permet de zoomer et faire pivoter les images, ainsi que de naviguer parmi les différentes pages d'une facture. Une fois développé (sans avoir eu recours au HTML5), le widget GWT est compilé et intégré à l'application comme s'il s'agissait de l'un de ses composants natifs.

Malgré une relative jeunesse, ce framework ne souffre pas d'un manque de maturité. La bibliothèque de composants graphiques gagnerait certes à s'étoffer encore ; la séparation entre la vue et le contrôleur pourrait être mieux encadrée (voire encouragée) par le framework, mais en ayant réussi la synthèse du client léger et du client lourd, Vaadin a tous les atouts pour devenir un framework de référence pour le développement d'applications d'entreprise dans les années à venir...

Améliorer le look and feel d’une application web

La deuxième moitié des années 2000 a été le théâtre de bouleversements majeurs dans nos navigateurs : démocratisation de l’Ajax, Web 2.0, réseaux sociaux ou collaboratifs, wikis… Aujourd’hui, il est fréquent que les applications web que nous utilisons dans notre vie privée – GMail, Yahoo!, Facebook, Picassa, Flickr, blogs – soient plus ergonomiques que celles que nous utilisons dans notre vie professionnelle. Si les utilisateurs finaux doivent s’en accommoder (ont-ils vraiment le choix ?), cette situation n’est pas satisfaisante lorsque l’on est éditeur de logiciels ou responsable applicatif au sein d’une grande organisation. Alors que faire ?

La méthodologie :
Pour un tel projet, qui ne comprendra finalement principalement que des modifications de style et d'ergonomie, inutile d'annoncer le lancement d'une v3 de l'application! Un cycle en V semble également peu adapté, pour de nombreuses raisons :

• les phases amont au développement (architecture, spécifications, conception détaillée) sont souvent produites sous forme de documentation qui seront difficiles à valider par une MOA ou un département marketing,
• certaines phases en aval du développement comme les tests unitaires seront difficiles à réaliser dans ce contexte,
• risque d’effet-tunnel avec des délais difficiles à maîtriser
• risque de surprise des clients (département marketing, MOA, utilisateurs finaux) en cas d’écart entre ce qui a été produit et ce qui est attendu.

Pour ce genre de démarche, il faut oublier la lourdeur du cycle en V et préférer une méthode permettant de faire des livraisons fréquentes, comme une méthode itérative ou une méthode agile de type SCRUM. Les livraisons sont facilitées par l’architecture même des applications web qui nécessitent seulement un déploiement sur un serveur et permettent :

• A l’équipe de développement de montrer que le travail avance régulièrement
• Aux clients de s’approprier le nouveau look de l’application sans être déroutés
• Aux clients de faire des retours et de soumettre leurs idées pertinentes

Une livraison toutes les 4 à 6 semaines (en fonction de la durée du projet) semble un bon rythme. Il est intéressant, si c’est possible, de formaliser les livraisons en présentant les nouveaux éléments aux clients. A chaque livraison, l’équipe de développement fera en sorte de livrer des tronçons complets pour ne pas donner l’impression de travail inachevé. Elle introduira également les retours sur la version précédente dans la mesure de ce qui a été convenu.

La stratégie :
Si l’objectif est d’améliorer l’expérience utilisateur, et de livrer quelque chose de visible tous les mois, il faut être efficace. Dans ces conditions, pas question de remplacer le vieux framework MVC maison par un standard du marché : la valeur ajoutée utilisateur est proche de zéro.
Inutile non plus de tenter une migration vers le dernier framework de développement RIA, genre GWT ou Flex. Cela ne serait pas compatible avec la démarche définie ci-dessus… et les risques de régressions fonctionnelles sont énormes, surtout s’il existe du code métier dans les pages faisant le rendu HTML, ce qui est fréquent !

Une stratégie à la fois raisonnable et efficace est de transformer progressivement l’application en remplaçant certains éléments existants, ou bien en ajoutant de nouveaux éléments. Pour cela, il faut choisir une librairie Javascript suffisamment riche pour :

• Proposer nativement des éléments graphiques comme des fenêtres modales, des datepickers, des accordéons, onglets, etc.
• Manipuler dynamiquement les éléments du document au travers de sélecteurs
• Mettre en place facilement des appels AJAX
• Permettre la création de plugins (pour pouvoir en réutiliser !).

La bibliothèque jQuery est particulièrement adaptée pour ce type de réalisation, car elle a un excellent équilibre entre sa valeur ajoutée intrinsèque et son niveau d’intrusion lorsqu’elle est insérée dans une application existante. Il faut dire qu’avec seulement quelques fichiers .js et .css à inclure (si l’on adjoint jQuery UI), il est difficile de faire moins intrusif ! De plus la clarté de sa documentation et la quantité de blogs de développeurs s’y référant rendent sa mise en œuvre rapide.

La mise en œuvre :
Voici quelques idées de transformations simples qui ont un impact immédiat :

• Remplacement d’anciens calendriers s’ouvrant dans une fenêtre popup (utilisation du composant datepicker de jQuery)
• Utilisation de tables triables et paginées dès que le nombre d’éléments à afficher dépasse quelques dizaines. Utilisation de cookies pour enregistrer ordres les tris et les choix de pagination
• Utilisation du drag and drop pour sélectionner quelques éléments parmi une liste
• Création d’un espace dans lequel l’utilisateur peut personnaliser l’application : choix d’un thème, des options de l’application,
• Ajout d’un composant affichant en temps réel la complexité du mot de passe utilisateur lorsqu’il est modifié
• Suppression des fenêtres popups qui compliquent la navigation (utilisation du composant dialog de jQuery)
• Utilisation d’appels AJAX lorsqu’il faut mettre à jour une très faible quantité d’informations sur une page. Dans ce cas, retourner soit des chaînes de caractères pour du texte, soit un objet JSON pour des tableaux ou des objets structurés.
• Restructurer les pages trop denses soit en les découpant, soit en utilisant des composants comme les onglets ou les accordéons
• Dans les formulaires, ramener les contrôles de format sur le client : taille maximale, formats numériques, monétaires, codes postaux, etc. Cela évitera des rechargements de pages en cas d’erreurs de saisie
• Valider que la navigation au clavier est opérationnelle dans tous les formulaires de saisie,
• Dans les formulaires encore, ajout d’aides à la saisie, comme le format attendu d’une date, d’un n° de téléphone, ou encore le nombre de caractères restant lors d’une saisie dans une textarea.
• Lors d’une erreur de saisie dans un formulaire, indiquer clairement dans quel champ se situe l’erreur, et quelle est la nature de l’erreur. Mettre bien évidemment le focus sur ce champ.

Lors de la mise en œuvre, le responsable des développements devra garder en tête que ce sont les petits ruisseaux qui font les grands fleuves…