Le point sur Ajax et les interfaces utilisateurs
Par Laurentj le vendredi, janvier 13 2006, 00:40 - Technologies Web - Lien permanent
À la lecture de certains commentaires, j'ai l'impression que mes billets sur Ajax ne sont pas assez explicites sur ma position à propos de cette méthode, et qu'ils sont peut être assez confus, puisque j'y parle non seulement d'Ajax, mais aussi d'interface utilisateur. Voici donc quelques eclaircissements.
À propos d'Ajax
- Quand je parle d'Ajax, je parle de l'utilisation conjointe de javascript, xmlhttprequest, et DOM. Sachant que le document peut être tout aussi bien du XHTML, du XUL ou tout autre dialecte XML. Je ne parle pas de manipulation DOM en dehors de l'utilisation de xmlhttprequest (pour un menu deroulant par exemple)
- Je ne dénigre pas Ajax, je ne suis pas contre Ajax. Je suis contre son utilisation abusive comme on voit sur certains sites, comme ce que j'expliquais dans le billet "Ajax et accessibilité : attention".
- Je préconisais l'utilisation d'Ajax sur Xulfr bien avant que cette "méthode" ait pour nom "Ajax". C'est ainsi que vous trouviez il y a deux ans des pages sur l'avantage d'utiliser xmlhttprequest pour interroger les services web, des explications pour utiliser xmlhttprequest, ou encore sur les architectures possibles d'une application web.
- Je trouve Ajax inutilement compliqué dans certains cas d'utilisation, comme je l'ai expliqué dans "ajax est déjà obsolète" : il y a des cas où il pourrait (notez bien le conditionnel) être interressant que toute la mecanique Ajax soit "cachée" par une simple balise. J'avais donné pour exemple certaines de ces balises qui existent déjà : la balise <a>, <form> et la balise <template> de XUL (on pourrait rajouter aussi <iframe>). Ces remarques ne sont pas déstiné spécialement aux développeurs web, mais aux éditeurs de navigateurs.
- La solution que j'évoque n'est pas possible pour tous les usages d'Ajax. C'est pourquoi il existe des bibliothèques javascript masquant cette complexité. Mais les navigateurs pourraient proposer une API similaire à ce que proposent ces bibliothèques, évitant de télécharger des kilo octets de scripts.
À propos d'interface utilisateur
- Je fais la distinction entre une application web (qui permet de gérer quelque chose), et un site web (diffusant de l'information). Mais il est vrai que l'évolution des techniques et usages fait que la frontière entre site et application est de plus en plus floue;
- Je suis au courant (merci donc d'arrêter de me le signaler en commentaire à chacun de mes billets, ça devient pénible) que XUL n'est utilisable que chez 10% à 45% des internautes, qu'il n'est pas à préconiser pour une application web grand-public, et qu'il est préférable dans beaucoup de cas d'utiliser HTML pour faire des similis d'interfaces utilisateur;
- Je persiste et signe sur le fait que oui, HTML n'est vraiment pas la panacé pour réaliser des interfaces utilisateurs, qu'il complexie le développement puisqu'il faut combler ses lacunes en la matière à coup de script JS dans tous les sens. Sans oublier qu'une interface en HTML n'atteindra jamais le niveau d'une interface native à l'environnement utilisateur (comme ce qui est généré en XUL), tant en terme "d'utilisabilité" que d'accessibilité;
- C'est pourquoi je persiste aussi à préconiser d'utiliser XUL dans des applications web. Mais bien entendu, dans des applications web qui sont utilisées dans un contexte "privé", par des personnes à qui on peut imposer l'utilisation d'un navigateur Gecko (Firefox) : intranet/extranet par exemple, partie admin d'un site etc; N'en déplaise à certains, de plus en plus d'entreprises (et pas des moindres) l'ont compris et commencent vraiment à utiliser XUL (Surveillez l'actualité sur Xulfr ces prochaînes semaines ;-).
Commentaires
Voilà un avis clair et précis sur ces technologies que je partage entièrement.
Beau résumé :-)
Moi je crois que tu as un problème avec cette "techno" ;-) Il est sure qu'actuellement il y a un gros buzz Web2/ajax. Et il est clair que le trop d'ajax tue l'ajax ; c'est plus qu'évident. Moi je fais beaucoup de dev web, en technos php/dot.net, et j'implémente des frameworks web dans ces technos là (pour intranet only). Et je peux te garantir qu'il y a moyen de rendre très simple l'utilisation d'ajax, pour l'utilisateur/développeur (en masquant la complexité) ... (ex, pour dot.net, mes users ont juste besoin de mettre un decorator sur la méthode "AjaxMethod", et ils peuvent alors l'appeler simplement en javascript, tout en étant compatible avec les mécanisme "d'asp.net session" : pas plus simple)... Tout ça pour dire que le débat maintenance/complexité n'a vraiment pas lieu d'être ! On a également réalisé une appli/php (sorte de spip), qui sans ajax, ne serait pas ce qu'elle est. Et n'aurait absolument pas été faisable sans. (réalisation d'une interface utilisateur complexe, impossible à réaliser sans (en fait c possible, mais ça serait inutilisable) ) Et qui peut imaginer un google-map sans ajax ?!? (pour moi, c'est un des meilleurs exemple) Oui, c possible, mais soit avec du flash (pas mieux, genre mappy), ou avec une applet java (pas mieux, genre map24) ... Maintenant, il est clair que niveau accessibilité : on y perds un peu (links ne fait pas l'ajax ;-) ... mais, pour faire comme une appli GUI, entre les technos ajax/flash/java ; c'est quand même l'ajax le plus adéquate, non?! (et de loin, à mon humble avis) C'est les outils d'accès à améliorer, pour qu'ils soient plus ajax-compliant ...
Mais une chose est sure, c'est que le sujet web2/ajax a vraiment l'air de te perturber, car tu contribue pas mal au buzz qu'il y a autour. (bon, je comprends que ça empiète un peu sur les platebandes du XUL : pouvoir réaliser des applis web équivalentes aux applis GUI, et que forcément c'est génant)
Les 2 points où je suis d'accord : - l'ajax à tout va : non ! - amélioration du client léger pour simplifier "l'ajax" (et le rendre accessible)
Il est vrai que XUL, j'y ai quasiment jamais touché, j'ai trouvé ça très/trop complexe à mettre en oeuvre, à chaque fois que j'ai tenté. Comprendre : il faut une sacrée volonté pour s'y mettre. Etant un adepte du KISS, et un fan de python ; j'ai vraiment du mal à m'y mettre (je suis aussi un peu flemmard, mais très fan de technos, et je crois au xul) ... Cependant, j'attends avec impatience le mariage XUL/python ; ça me permettra d'y rentrer plus facilement (on est beaucoup dans ce cas là)
C'est bien ce que je dis : Ajax c'est trop complexe, puisque tu es obligé, comme tout le monde, de créer ta propre bibliothèque pour masquer toute cette complexité génante, qui t'emmerde tout le temps. Si c'était si simple, prototype &cie n'existerait pas. Cela prouve bien que c'est une solution de bricolo, pas du tout élégante, sans compter que cela nous fait revenir des années en arrière au niveau accessibilité. C'est ça qui me gène. Et ce qui me gène le plus, c'est l'engouement pour cette façon de faire, alors que ce n'est absolument pas la bonne voie comme je l'ai expliqué. (oui oui je connais l'une des raisons, sur tout les navigateurs bla bla bla).
Conçernant la complexité de XUL, il faudra que tu m'expliques en quoi ça, <menupopup> <menuitem /></menupopup>, pour faire un menu déroulant, c'est plus compliqué que toute cette tripoté de script/html, comme ici par exemple : http://openweb.eu.org/articles/menu_universel/ ;-) . Et encore celui-ci est le plus propre qu'on puisse faire en HTML.
Alors là ! Je suis très content de voir une évolution vers l'argumentation par rapport à tes billets précédents ! Je dis OUI OUI OUI et re OUI (celui là c'est pour XUL). Certe AJAX n'est pas le must mais il le restera en tout cas pour combler les trous de l'HTML et évidemment le temps - comme tu le dit si bien - que tous les internautes ailles vers Firefox pour que les applications XUL tournent sur toutes les plateformes. (je fait aussi référence aux dires de Paul Rouget). ;)
oui, tout comme le menu d'openweb ... et en general tout ce qu'on est obligé de développer pour que nos applis web ressemblent à de vrais applis ... on ne fait que du "bricolage", on compose avec ce qu'on a
On dit pareil ... Mais en attendant du xul partout, si on veut faire des "choses biens" dans 99% des navigateurs : on n'a pas d'autres choix que manipuler à tout va l'hmlt/css/js C'est un autre débat ...
Ajax apporte le truc qu'il manquait pour vraiment faire du 'top' ... en attendant : y a pas mieux, et faut composer avec ... Mais on ne m'otera pas l'idée que ça peut apporter énorme quand c'est bien utilisé ... et que ça permet de pouvoir commencer à faire des choses vraiment sympa (infaisable avant sans utiliser des technos encore mois accessible, et "très diffusé", comme le flash ou le java)
compare ces mêmes services de "cartes", y a pas photo pour moi. - google maps, et son ajax - mappy et son flash - map24 et son java - viamichelin et son html
bon on attends toujours les routes françaises dans google maps, mais admettons qu'elles soient dispos ;-)
le xul, n'est malheureusement pas encore à la porte de tout le monde ... et on peut pas se permettre d'attendre xulrunner (et que nos chers dsi reflechissent) pour faire des "choses biens" ... comme déjà dit, si c pas l'ajax, ça sera du java, du flash ou pire encore, de l'activex : donc l'ajax, en attendant, y a pas mieux
Mais je crois qu'on dit pareil, en gros ... a nous de continuer à propulser ffox/Gecko partout ...
chose marrante également : c'est que microsoft aussi a tendance à bloquer l'ajax ;-)
chez nous, pour une grosse appli intranet (dot.net), on avait préconiser l'utilisation d'ajax, pour obtenir des interfaces dignes dans IE only. Les experts microsoft sont intervenus, et ont mis le véto au niveau des instances ; en pretextant que IE ne marche pas bien avec ajax, que c'était pas au point et trop risqué. (alors que c'est eux qui ont inventé xmlhttprequest)
mais à mon humble avis; il ne font que ralentir la chose, en attendant que leur atlas sorte ... et on sera obligé de composer avec atlas ;-(
Tant qu'à faire des métaphores pourries : vive les bricolos, à bas les sémaphores.
En 2002 j'ai été impliqué dans un projet de portage d'une application vers J2EE. Il est rapidement apparu que les pages HTML ne pouvaient être utilisées compte tenu des contraintes qui portaient sur les interactions homme/machine. En l'absence de client léger adequat, j'ai décidé de réaliser une applet dont le seul rôle serait d'afficher des écrans au look Windows et de permettre la sasie des champs et déclenchement d'événements sur le serveur. Tout cela est maintenant disponible sur le marché. En début d'année 2005 j'ai dû entamer un projet similaire. J'ai regardé ce qui existait depuis. On commençait à parler d'AJAX de XUL ... Mais aucune des solutions ne semblaient satisfaisantes. Donc nouvelle applet. Elle gère le multi fenêtrage, les fenêtre modales et non modales et une multitude d'événements "windows".
Tout cela pour dire qu'il existe une alternative interessante à ces solutions (qui le sont elles même d'ailleur) et vous libère de pas mal de dépendances vis-a-vis de projets open sources ou de solutions commerciales dont la pérénité n'est peut-être pas garantie. La réalisation d'une applet complète et de son interface sur le serveur ne représente pas plus de 100 jours hommes d'investissement et est donc économiquemtn viable face aux côut d'appropriation de Ajax et XUL par exemple.
Tes 100 jours, ils comprennent la formation java, le cout d'"appropriation" de Java ? Parce que si ce n'est pas le cas, tu fais la même chose en XUL en beaucoup moins de temps à mon avis (et sans avoir les contraintes et la lourdeur d'une applet java).
Les 100 jours ne comprennent pas la formation Java. D'expérience elle est nettement plus longue. J'ai encadré assez de projets incluants des developpeurs récemment venus à cette techno pour en avoir fait l'amère expérience :).
Pour éviter tout mal entendu, je ne suis en aucune façon un adversaire ou un critique de XUL ni d'Ajax. Mon seul propos était de faire valoir q'uil existe une alternative interessante à ces 2 technos. Telle que mon équipe les ont développées les 2 applets (bientôt la première sera mise a la retraite et remplacée par la 2eme) ne nécessitent pas de qualification particulière pour être utilisées. Tout ce qui a trait aux écran est entièrement décrit en XML, en encore un XML simple. Il s'est avéré de plus que la modification du look de certains écrans pour des raisons de préférence des utilisateurs étaient aisée et pouvait être réalisée par des consultants sur site et sans intervention de développeurs. Nous réfléchissons en ce moment à la réalisation d'un outil de configuration des-dits écrans.
Bonjour, Je viens de tomber par hasard sur ce site et je tiens à faire une remarque.
Je fais actuellement des applications extranet en J2EE. J'utilise de l'AJAX par que c'est une demande du client. En effet, celui-ci à lu dans la presse le terme AJAX et à voulu l'utiliser absolument et ceux malgré le fait que dans ce cas, c'etait inutile.
Donc c'est bien de discuter des différentes technos à disposition, mais on n'a pas toujours le choix.