11402 sujets

JavaScript, DOM et API Web HTML5

Pages :
Bon allez, Cedric m'ayant grillé la politesse, je vais prendre sur moi de poser la première VRAIE question de ce forum.
Pour un projet futur, j'envisage l'utilisation d'Ajax.
Je compte bien sûr l'utiliser de façon respectueuse, mais je me demande comment l'intégrer de la façon la plus respectueuse, pour les standards ET l'utilisateur : proposer la possibilité de passer d'un mode Ajax à un mode non-Ajax ? L'activer par défaut ? L'activer à la demande ? Smiley murf
Modifié par Marvin Le Rouge (07 Jan 2006 - 16:23)
Bonjour,

Ah. Voilà précisément l'une des raisons pour lesquels j'ai souhaité la création de ce salon. Ta première question est aussi la première vraie question à se poser Smiley cligne

AJAX pose de nombreux problèmes d'accessibilité et d'ergonomie, sur lesquels il y a encore aucun recul. Selon la manière dont il est utilisé (tableau volontairement noirci) :
- prévoir le fonctionnement alternatif sans javascript... mais aussi avec javascript mais sans XMLHTTPRequest . Voire également le comportement avec javascript, AJAX etc... mais sans souris, tout bêtement.
- nécessité de tester systématiquement sur le plus large éventail possible de navigateurs et de versions de navigateurs, afin de savoir précisément qui sera exclu et comment se comporte la solution de repli adoptée
- signalétique de l'interface utilisateur à inventer, pour que l'utilisateur sache immédiatement qu'il n'est pas sur une page Web au comportement "normal", et qu'il doit adopter de nouveaux réflexes. En particulier : signaler ce qui est cliquable, signaler les "zones neutres" où cliquer pour "soumettre".
- En reprenant l'approche de la WCAG2.0, on pourrait dire qu'AJAX crée constament un nouveau contexte de navigation, et que l'utilisateur doit au moins en être averti. En revanche, il est totalement faux de postuler qu'on peut remplacer la simplicité d'apprentissage par la simplicité d'usage au prix d'une plus grande tolérance de l'utilisateur envers ses propres erreurs, comme le prétend John Rhodes, repris dans le web francophone par Fred Cavazza.
- mise en page qui "bouge", ce qui désoriente ou qui perturbe l'attention. Un contenu inséré à la volée, par exemple, ne doit pas provoquer de déplacements massifs du reste de la page... Il ne doit pas non plu s'insérer à un endroit inattendu, perturber l'action en cours de l'utilisateur, ou tout simplement s'afficher hors de la zone de visualiation suite à une utilisation imprudente de CSS (plus fréquent qu'on ne le croierait).
- très médiocre interaction avec le scroll, et pire avec la molette. Entre le moment où l'utilisateur a déclenché une action et celui où elle se manifeste, l'utilisateur peut avoir eu toutes sortes d'idées farfelues. Notemment celle de scroller parce que quelque-chose d'autre a attiré son attention. AJAX requiert parfois un utilisateur très très sage, qui ne fait que ce qu'on (ne lui a pas/lui a) expliqué qu'il pouvait faire.
- lenteur des traitements javascripts massifs sur des clients de faible capacité ou simplement occupé en même temps à autre chose.
- incitation à surutiliser GET au détriment de POST. Problèmes de sécurisation.
- incompatibilité avec les moteurs de recherche et indexation nulle ou médiocre d'un contenu AJAX
- impossibilité d'utilisation hors-connection
- impossibilité d'utiliser l'historique du navigateur
- impossibilité de conserver en signet l'état précis de la page
- relations conflictuelles avec les habitudes de l'utilisateur d'onglets
- etc.

Il y a donc beaucoup de points à examiner pour chaque application AJAX.

Plus précisément, maintenant : dans certaines applications, où le fonctionnement d'AJAX n'est pas totalement transparent et non -obstructif, je crois de plus en plus qu'il faut donner à l'utilisateur la possibilité de passer en mode "SANS AJAX" (pour tout ou partie des fonctionnalités de la page, mais sans avoir à désactiver localement javascript).

Voir par exemple notre version bêta de Mon-Opquast où nous avons utilisé AJAX de différentes manières : nous travaillons actuellement sur ce point, pour la fonctionnalité d'édition des tableaux de suivis de qualité...

Il est finalement dommage qu'AJAX ait été introduit (ou plutôt mis au goût du jour) par Google, qui ne pouvait le faire que sur le mode "vous rentrez dans ma cible commerciale et ça passe. Sinon, tant pis." C'était un départ très handicapant, qu'il s'agit de rattraper dans les usages de cette technique...
Modifié par Laurent Denis (07 Jan 2006 - 10:49)
a écrit :
- incompatibilité avec les moteurs de recherche et indexation nulle ou médiocre d'un contenu AJAX


Ca dépend comment on s'y prend : si on a par exemple un lien, dont on modifie le comportement au "onload" de la page via javascript, les moteurs de recherche ne se rendront compte de rien.

En ce qui concerne le comportement de l'utilisateur durant la requète asynchrone, j'avais pensé qu'un simple message bien visible l'informant qu'on est en train de charger un contenu serait suffisant. S'il veut scroller ou autre chose dans l'intervalle, libre à lui. Mais comme est au courant, il ne fera probablement pas des bonds de 15m lorsque le contenu changera.
Interessant d'évoquer toutes ces problématique. Pour ne pas perdre ce sujet, il serait bon de donner un titre représentatif au topic Smiley cligne

"Comment bien utiliser AJAX ?" par exemple
Modifié par Olivier (07 Jan 2006 - 12:36)
Laurent Denis a écrit :
Le titre actuel a un petit côté devinette qui siet bien au sujet... Smiley ravi


... mais très mal à la recherche...
Bonjour, je suis tombé par hasard sur ce post et je ne suis pas tout a fait d'accord avec certains points.

Laurent Denis a écrit :

...tous pleins de conseils...

Tous ces premiers conseils ne sont pas particuliers à l'utilisation d'AJAX, mais de manière plus générale à la conception d'un site web.
Ils pourraient aussi s'appliquer à la réalisation d'un site entierement en flash.

Laurent Denis a écrit :

AJAX requiert parfois un utilisateur très très sage, qui ne fait que ce qu'on (ne lui a pas/lui a) expliqué qu'il pouvait faire.

J'ai envie de dire comme n'importe quelle application/site web!!! Combien de sites supportent mal que l'on fasse back après la soumission d'un formulaire.

Laurent Denis a écrit :

- lenteur des traitements javascripts massifs sur des clients de faible capacité ou simplement occupé en même temps à autre chose.

Il n'y a pas de raisons d'avoir des traitements "massifs" en javascript. Le flux retourné est juste "affiché" par le js. Ce sont les "fioritures" graphiques qui peuvent avoir ces effets, mais cela n'a rien a voir avec Ajax.

Laurent Denis a écrit :

- incitation à surutiliser GET au détriment de POST. Problèmes de sécurisation.

Pas d'accord, il est aussi facile d'utiliser GET ou POST. Comme d'habitude il suffit de penser(faire) les choses proprement dès le début.

Laurent Denis a écrit :

- incompatibilité avec les moteurs de recherche et indexation nulle ou médiocre d'un contenu AJAX

totalement vrai

Laurent Denis a écrit :

- impossibilité d'utilisation hors-connection

Comme avec quasiment n'importe quel site "dynamique". Dès qu'il y a des traitements sur un serveur, il est dur de rendre le site utilisable hors-connection.

a écrit :

- impossibilité d'utiliser l'historique du navigateur
- impossibilité de conserver en signet l'état précis de la page
- relations conflictuelles avec les habitudes de l'utilisateur d'onglets

Totalement vrai, mais encore en fois ce n'est pas particulier à ajax, on retrouve le même genre de problème en utilisant des frames ou du flash.

Laurent Denis a écrit :

-obstructif, je crois de plus en plus qu'il faut donner à l'utilisateur la possibilité de passer en mode "SANS AJAX" (pour tout ou partie des fonctionnalités de la page, mais sans avoir à désactiver localement javascript).

Tout est une question de contraintes, coûts et délais.
Pour un "petit site perso" il est envisageable de prévoir les deux options. Dès que l'on passe à quelque chose de plus important, il est difficile d'expliquer au client que tous les developpements devront être doubler pour les gens qui contrairement à lieu ne surfe pas sur IE avec tout activé.
Attention je n'ai jamais dit qu'il ne fallait prévoir que cela marche que pour IE avec le javascript activé, juste que "tout" envisager multipliait considérablement les temps de developpement et donc les couts.

Laurent Denis a écrit :

Il est finalement dommage qu'AJAX ait été introduit (ou plutôt mis au goût du jour) par Google, qui ne pouvait le faire que sur le mode "vous rentrez dans ma cible commerciale et ça passe. Sinon, tant pis." C'était un départ très handicapant, qu'il s'agit de rattraper dans les usages de cette technique...

Oui et non Smiley murf !!!
IMHO, Ajax ne doit pas être vu comme un moyen de remplacer le mode de fonctionnement classique d'un site web.
C'est un moyen de faire les choses différement, généralement en essayant d'apporter un plus "ergonomique" à l'utilisateur.


Par contre la chose qui me chagrine c'est que dans le POST il n'est nulle part fait allusion au XML. Or AJAX n'existe réellement que si les echanges sont fait en XML.
Dans le cas contraire on se trouve dans un cadre batard où il s'agit essentiellement de Javascript.

Le vrai avantage d'ajax se situe pour moi dans l'utilisation du XML. A condition de penser correctement ces traitements serveurs et ces flux, il devient possible des les utiliser avec un autre interface que le navigateur+js (par exemple un webservice).
On se retrouvre alors avec un (preque) vrai modèle MVC pour une appli web.
L'envers de la médaille c'est que l'utilisation du XML entraine l'utilisation des XSLT, de préférence coté client, ce qui amène de nouveaux problèmes de comptatibilité entre les navigateurs.
Modifié par Maat (09 Jan 2006 - 13:53)
Merci beaucoup Laurent Denis pour la liste des points sensible lors de l'utilisation d'AJAX.

Cependant, j'ai une question concernant ce point :
Laurent Denis a écrit :
- prévoir le fonctionnement alternatif sans javascript... mais aussi avec javascript mais sans XMLHTTPRequest . Voire également le comportement avec javascript, AJAX etc... mais sans souris, tout bêtement.
Comment détecter si l'utlisateur a ou non XMLHTTPRequest?


Merci beaucoup,
Modifié par agilis (23 Jan 2006 - 20:31)
Merci beaucoup!

Je ne me souvenais plus qu'il y avait des tests dans les exemples de ce tutoriel.
Bonjour,

a écrit :
AJAX pose de nombreux problèmes d'accessibilité et d'ergonomie, sur lesquels il y a encore aucun recul. Selon la manière dont il est utilisé (tableau volontairement noirci)


Et j'ajouterai : et selon la manière dont il est envisagé, notamment du point de vue des interfaces qui tournent sur de (très) vieilles recettes DHTML relookées WEB 2.0, et qui posent les mêmes problèmes qu'avant la (re)découverte de l'objet XMLHttpRequest.

De ce point de vue, les promoteurs de " l'AJAX sinon rien " devraient se souvenir de la période 2000-2002 quand on nous promettait que Flash était l'outil du futur pour produire des "clients riches".

a écrit :
En reprenant l'approche de la WCAG2.0, on pourrait dire qu'AJAX crée constament un nouveau contexte de navigation...


Ca c'est la chose la plus intelligente que j'ai entendu sur AJAX, ( même si Laurent est coutumier du fait... Smiley smile )
C'est un problème très épineux, très difficile à envisager, parcequ'il est consubstanciel à la méthode de l'objet XMLHttpRequest.

Et le soucis c'est que les solutions à ce problème ne peuvent être fournies que par l'auteur en dehors de tout formalisme, ce qui renvoie également aux remarques sur la signalétique des objets de l'interface, des actions qui y sont associés et de leurs résultats.

a écrit :
... je crois de plus en plus qu'il faut donner à l'utilisateur la possibilité de passer en mode "SANS AJAX" (pour tout ou partie des fonctionnalités de la page, mais sans avoir à désactiver localement javascript).


La remarque que je me fais en imagineant des solutions alternatives "sans ajax" est la suivante : Dans le cas d'une interface complexe, où la concentration de nombreux traitements se justifie, la solution alternative "sans ajax" elle ne le supportera pas.
Ce qui pourrait nécessiter de devoir entretenir deux applications en parallèle, méthode dont on connait, par ailleurs, les funestes augures.

Jean-pierre
Modifié par jpv (26 Jan 2006 - 04:27)
Ceci est une question que je me suis trés souvent posé :

Comment utilisé ajax ?! Le problème est que l'on a pas encore de recul sur cette technologie.

Tout d'abord je ne suis pas entierement d'accord avec Maat
Maat a écrit :

Par contre la chose qui me chagrine c'est que dans le POST il n'est nulle part fait allusion au XML. Or AJAX n'existe réellement que si les echanges sont fait en XML.
Dans le cas contraire on se trouve dans un cadre batard où il s'agit essentiellement de Javascript.



Certes dans Ajax, il y a le terme Xml, mais je ne pense qu'on doit limiter les requetes via js pour appeler du XML, le terme ajax / XMLHTTPRequest est donc relativement mal choisis.
Perso la plupart de mes requetes Ajax se font sur du JSON : http://en.wikipedia.org/wiki/JSON, le json a plus ou moins la meme structure que le XML, mais il a l'avantage d'être directement utilisable par js, sans meme être parsé!

Aprés si l'on fait que de la mis à jour d'un "panel" la oui il vaut mieux utiliser XML / XSL mais cela entraine des problèmes de compatibilité (Opéra ne le fait pas il me semble)


Ensuite sur les problèmes que pose Ajax, je ne pense pas qu'il y en ait autant que le dit Laurent.

La plupart des problèmes cités par Laurent, peuvent être résolus si le programmeur travail correctement, et pense avant tout à l'utilisateur !!! tout en sachant que l'utilisateur est ultra stupide Smiley cligne

Pour moi les problèmes sont :

- Indexation dans google !

pour cela la réponse que j'ai est

<a href="mapageClassique" onclick="doAjax('mapage'); return false;">


- Pas de possibilité de bookmarker une page, pour cela il suffirait de donner un lien qui repointe vers le meme contenu mais c'est pas encore ca

- Pas d'historique : idem coder ses propres boutons back mais bof

- Pour les sites ou le financement vient de la pub, on génére moins de page, la pub change donc moins souvent, les revenus risquent donc de s'amenuir Smiley decu

En résumé les principaux problèmes sont que l'url ne changent pas, le reste il suffit que le programmeur pense beaucoup à l'utilisateur (stupide et hackeur)

PS : Je trouve l'idée de ce forum vraiment trés interessant, je vais vite en devenir un accro Smiley cligne
Tous ces débats sont bien intéressants, ma foi. Mais je me demande si on ne fait pas tous, d'une certaine manière, fausse route.

En effet, la majorité des problèmes qui ont été soulevés reviennent, comme l'a fait remarqué CyrilCS, au fait que l'URL ne change pas. Mais cela n'est effectivement un problème que pour un site web utilisant AJAX pour sa navigation.

Mais finalement, AJAX n'est-il pas plutôt destiné à la création d'interface d'application web, et non de site web classique pour contenu ?


Bon, en même temps ça me va bien de dire ça, je bosse sur un site mélant Flash et AJAX. Mais bon, c'est pour apprendre, montrer l'étendue de mes compétences, et surtout rabattre le caquet à tout les trollers du flashcémalcépasaccessible. Car je vais tout faire pour que le contenu soit accessible avec ou sans flash, avec ou sans javascript, avec ou sans XHR.
Bonjour,

j'essaye d'utiliser Ajax de la facon suivante (a travers un exemple basique) :

j'ai une page qui comporte seulement un bouton ; quand je clique dessus, le serveur me renvoie une chaine de caracteres et un nombre aleatoire qui s'affichent a cote du bouton, sur la meme page donc.

J'essaye de demander au serveur de renvoyer du html aussi, mais ce dernier n'est pas interprete par le navigateur, car j'utilise dans mes fonctions javascript (je me suis inspiree du Head Rush Ajax) :


     request.open("GET", url, true);
     request.onreadystatechange = updatePage;
     request.send(null);


puis dans updatePage():

var code = request.responseText;


Le probleme est que si j'ai, dans mon script php, un
echo "<b>coucou</b>"
, la page html est rechargee localement en affichant "<b>coucou</b>".

Comment proceder pour recharger la page localement en affichant du html?

Je debute, ma question est bien naive et peut etre pas tres claire (je m'en excuse, je n'ai pas le code sur moi, je m'exprimerai mieux un autre jour), mais je galere depuis quelques jours la-dessus Smiley sweatdrop Smiley confused

En esperant trouver de l'aide ici,
bonne prog a tous!
Modifié par pix (26 Jul 2006 - 19:48)
pix a écrit :

Comment proceder pour recharger la page localement en affichant du html?

Je debute, ma question est bien naive et peut etre pas tres claire (je m'en excuse, je n'ai pas le code sur moi, je m'exprimerai mieux un autre jour), mais je galere depuis quelques jours la-dessus Smiley sweatdrop Smiley confused

En esperant trouver de l'aide ici,
bonne prog a tous!


L'affichage de la réponse peut se faire par l'utilisation du DOM (Document Object Model).
Le DOM, est gros, c'est un abres avec tous les noeuds de ton code HTML, des attributs et même des fonctions.
Tu devrais faire des recherches sur l'utilisation et la modification du DOM.
à quoi sert AJAX ? my two cents.

à rien

AJAX permet de faire un traitement de l'information côté utilisateur au lieu de le faire côté serveur. Rien de nouveau, AJAX c'est et ce n'est que ECMAScript, rien de moins, rien de plus.

Normalement, ECMAScript ne doit être utilisé que dans un but cosmétique, et la structuration de la présentation des données doit être réservée côté serveur.
Normalement, car dans la réalité, le serveur du pauvre est bien souvent incapable de répondre à l'utilisateur aux heures de pointe, et (stupidité des utilisateurs ? Smiley cligne les utilisateurs utilisent aux heures de pointe sinon il n'y aurait pas d'heures de pointe.
Le webmestre du pauvre est donc contraint d'utiliser des techniques asynchrones côté serveur, cad produire des fichiers statiques à chaque modification de la base d'informations.
Ce qui a des limites, car le serveur du pauvre n'est pas limité qu'en temps de traitement, mais aussi en espace de stockage, alors que l'utilisateur n'est pas limité en originalité.

AJAX ça sert aux pauvres

du point de vue du pauvre AJAX cad « ECMAScript think XMLHttpRequest »,
permet de :
diviser par deux le temps de développement
diviser par deux le cout de maintenance

pensez XML !
votre base de données : des fichiers XML,
vos structures de navigation : des fichiers XML,
votre serveur : un script utilisé une seule fois, de façon asynchrone lors de chaque modification de votre base d'informations.

ECMAScript est ton ami

;) c'est un peu polémique et plaisant,
mais j'ai des exemples,

bien amicalement,
fal7i
Modifié par clansco (16 Jan 2007 - 15:28)
Pages :