5568 sujets

Sémantique web et HTML

Bonsoir !

Une agence de communication a réalisé un nouveau graphisme (sous forme de fichiers Photoshop), que je dois implémenter sur un e-commerce existant.

Mon gros soucis est que le graphisme qu'ils ont réalisé est une page unique contenant une succession verticale de sections contenant soit du contenu (produits, infos sur les paiements, livraisons,...), soit le catalogue (une seule section, mais bourrée de Javascript pour fonctionner).

La navigation dans le catalogue (qui est donc une section parmi d'autres dans cette page) contient toute une série de catégories et sous-catégories, une synthèse des produits et une fiche détaillée pour chaque produit. Le tout devant se faire sans quitter la page, ni la section de cette page. Ce e-commerce contient +/- 120 produits.

Ils (l'agence de communication, donc) m'ont expliqué qu'ils s'étaient basés sur ces trois sites pour réaliser le nouveau graphisme.

http://www.mediovski.com/
http://www.mediaparker.com/
http://www.divups.com/

Ils semblent tenir à cette succession verticale. Que ca soit uniquement pour du contenu, passe encore, mais de là à mettre dans une seule page tout le contenu mais en plus une section permettant de naviguer dans le catalogue (et faire ses achats !) à coup d'Ajax, là je tombe par terre !

Je ne sais pas ce que vous en pensez, mais moi je vois toute une série de problèmes :

1) Si le navigateur ne supporte pas le Javascript, la navigation dans le catalogue et le passage d'une commande sera impossible. Pour moi, le javascript doit apporter un plus de confort, mais sa présence ne doit pas être un pré-requis.

2) L'accessibilité du catalogue me parait plus que douteuse.

3) En termes de référencement, cette structure verticale me semble une très mauvaise tactique, même si Google commence à savoir référencer de l'Ajax. Le fait de mettre des contenus différents (ex. qualité du produit, infors sur les livraisons, les paiements,...) sur une même page me laisse craindre que les mots clefs des différentes sections seront moins facilements retenus par Google, du fait qu'ils soient dilués dans une grosse page, qui traite de sujets différents. Par ailleurs, je n'ai pas le souvenir d'avoir déjà vu Google référencer des ancres. Bref, j'ai le sentiment que le référencement existant va être flingué par ce genre de structure.

4) Enfin, vouloir envoyer à un client une URL directe vers la fiche d'un produit sera impossible sur ce genre de structure, à moins d'user encore d'ancres comme identifiant, et... encore une fois, de se reposer sur de l'Ajax.

5) ... Voyez-vous d'autres inconvénients ?

Même si je devine que non, voyez-vous une manière propre et accessible pour réaliser la structure qu'ils demandent ? Que feriez-vous si vous étiez confronté à une demande de ce style ?

Je serais ravis d'avoir d'autres avis et d'autres points de vue que le mien, afin que je puisse me forger une opinion en toute connaissance de cause ? En fonction de vos remarques, soit j'essayerai à nouveau d'orienter le client (et l'agence de communication) vers une structure plus "saine" (qui ne repose donc pas de manière vitale sur de l'ajax pour fonctionner) ou je développerai cette structure en tentant de réduire la casse, voire, décliner le projet.

J'avoue que je suis très frileux à priori sur une telle structure, donc (je me répète, mais tant pis), vos avis me seront très précieux !

D'avance un tout grand merci !
T'as de bonnes raisons d'être frileux. Et si tu n'arrives pas à leur faire comprendre, tu peux fuir, sans hésitation ! Sauf si le budget est vraiment conséquent, tu peux prendre sur toi Smiley murf

Les problèmes que tu cites ne seront qu'une partie de ceux que tu peux rencontrer, et sont déjà suffisamment contraignant. Sans compter le temps de chargement. Et qu'en est-il de l'implémentation du tunnel de commande, de l'espace client et les pages annexes de mentions légales / conditions générales / FAQ / etc.. ?

C'est pas gérable !
Modifié par mob (31 Jan 2012 - 10:03)
Bouchon a écrit :
1) Pour moi, le javascript doit apporter un plus de confort, mais sa présence ne doit pas être un pré-requis.

Pour ma part je ne suis pas gêné par le fait qu'un site requière JavaScript. JavaScript est une technologie largement standardisée et implémentée, et l'époque où les implémentations étaient divergentes (donc un script pouvait marcher dans IE4 mais pas dans NN4 ou inversement) et instables (un script pouvait marcher dans NN4 mais plus dans NN6) est révolue. Les années 1990 sont finies et JS fait partie des technos de base du Web. Smiley cligne

Bouchon a écrit :
2) L'accessibilité du catalogue me parait plus que douteuse.

Oui, sauf à utiliser ARIA à fond, ce qui aura un cout.

Bouchon a écrit :
3) En termes de référencement, cette structure verticale me semble une très mauvaise tactique, même si Google commence à savoir référencer de l'Ajax.

Effectivement. Il peut y avoir des solutions de contournement de ce problème, mais ça aura un cout aussi.

Bouchon a écrit :
Par ailleurs, je n'ai pas le souvenir d'avoir déjà vu Google référencer des ancres.

Dans l'idéal tu peux utiliser l'History API de HTML5. Google propose aussi un mécanisme pour les ancres «Ajax» que tu peux voir utilisé sur twitter.com par exemple.

Bouchon a écrit :
Bref, j'ai le sentiment que le référencement existant va être flingué par ce genre de structure.

C'est une quasi-certitude.

Bouchon a écrit :
Même si je devine que non, voyez-vous une manière propre et accessible pour réaliser la structure qu'ils demandent ?

- Des requêtes XHR pour récupérer les contenus et soumettre les infos, bien sûr.
- History API ou à minima des ancres identifiant les contenus affichés. À chaque changement d'ancre ou d'URL, être capable d'afficher le bon contenu.
- ARIA à fond.
- Doubler le tout d'un fonctionnement avec navigation sans JS dans le catalogue (le système de commande peut être fait en JS-only), à destination des moteurs de recherche.

Bouchon a écrit :
Que feriez-vous si vous étiez confronté à une demande de ce style ?

1. Estimer la faisabilité (voir ci-dessus).
2. Estimer le cout d'une solution qualitative (référencement et accessibilité), et celui d'une solution «je fais juste ce qu'il faut pour avoir le visuel du client». La première sera sans doute 500% plus chère.
3. Proposer les deux au client, qui est libre de flinguer le référencement, l'ergonomie et l'accessibilité de son site s'il le souhaite (solution pas chère), ou de mettre l'argent nécessaire s'il veut une solution qualitative (investissement).

Si ça ne t'intéresse pas de bosser sur la solution à l'arrache, tu peux aussi ne pas la proposer. Si tu ne te sens pas capable d'implémenter la solution qualitative (c'est pas un tort, c'est assez pointu...), tu peux aussi ne pas la proposer. Et donc au final passer ton tour en expliquant clairement pourquoi.
Modifié par fvsch (31 Jan 2012 - 11:04)
Modérateur
5) ... Voyez-vous d'autres inconvénients ?

Tout simplement le confort et la compréhension de l'utilisateur alpha. J'ai testé les sites proposés en exemple et le moins que l'on puisse dire c'est que c'est peu intuitif à comprendre la navigation.
Personnellement je n'aime pas trop ce genre de truc, proposer un système pour paraître original, mais qui n'apporte rien de concret, et un syndrome que l'on voit trop souvent dans des agences de com.
Enfin, bien sûr, une fois exprimé son point de vue, ce que le client veut...
Bonsoir !

Nous ne sommes pas belges pour rien, un compromis a finalement été trouvé !

Le contenu "rédactionnel" (pour dire ainsi) restera sous cette fameuse structure verticale, toute la partie catalogue et toute la procédure de commande se fera dans des pages séparées.

Bref, c'est un gros "ouf" de soulagement !

J'ai d'abord expliqué les problèmes que posaient cette structure et les conséquences (et de traduire en "francais simple sujet-verbe-complément et pas de termes techniques svp").

J'ai rappelé le niveau technique des clients (les clients sont loins d'être à l'aise avec la technique) et expliqué qu'il fallait rester dans le KISS.

J'ai ensuite proposé deux solutions :
- soit de faire le tout bien proprement dans des pages séparées
- soit de maintenir leur structure, tout en déclinant toute responsabilité pour la perte du référencement et en ajoutant que ce choix entrainait des coûts de développements plus importants puisque je refuse de bâcler l'aspect qualitatif.

A défaut, je préférais ne pas m'engager dans un travail pour lequel j'avais la conviction qu'il n'apporterai que des problèmes.

Enfin, en élément important est venu appuyer ma démarche, de très gros clients utilisent encore IE6 (et particulièrement dans le secteur bancaire, et au niveau de certains ministères belges !). Et, j'ai vu un UN client (dans le secteur de l'acier) en IE6, lui aussi, et pour lequel le Javascript n'était pas activé.

Merci à vous pour les arguments, et les pistes (je ne connaissais absolument pas HistoryAPI qui va remplacer une usine à gaz dans un autre projet).

Reste à développer tout ca, maintenant ! Smiley smile
Modifié par Bouchon (07 Feb 2012 - 21:42)
Je viens de lire le sujet, ravi qu'une solution raisonnable a été trouvé Smiley cligne

Car sinon j'aurais dit que les sites sur lesquelles ils se sont appuyés en exemple ne sont même pas des sites e-commerce...
Modérateur
ça me parait plus cohérent, sur une partie vitrine, le visuel peut primer. Mais en effet dans un système applicatif (e-commerce en l’occurrence) le graphiste devrait passer après le programmateur, car c'est la fonctionnalité qui prime.

Bouchon a écrit :
Enfin, en élément important est venu appuyer ma démarche, de très gros clients utilisent encore IE6 (et particulièrement dans le secteur bancaire, et au niveau de certains ministères belges !). Et, j'ai vu un UN client (dans le secteur de l'acier) en IE6, lui aussi, et pour lequel le Javascript n'était pas activé.

mdr! En effet si en plus c'est pour un shop pro, la question n'aurait même pas du se poser. J'ai aussi déjà constaté que dans certaines très grandes entreprises ou organisations, les systèmes restaient longtemps inchangés, du aux coûts monstrueux engendrés par des mises-à-jour de systèmes. En gros, les systèmes n'évoluent pas mais sont changés au bout de 10-15 ans... J'ai même vu une grosse ong travailler encore le traitement de texte sous lotus!!!