Ma critique sur l'intégration du site a25.com

Tags

Dans la série "Revue de code en Intégration web" qui se veut une série de remarques pour améliorer le résultat final du site je commence avec ce premier site.

Le site a25.com est un service web qui sert a amasser les paiements dus pour l'usage du pont de l'Autoroute 25. Une caméra capture les plaques d'immatriculation et envoit une enveloppe réclamant son dû.

 

Quoi que très fonctionnel comme service, j'ai pas pu m'empêcher de regarder le code HTML envoyé aux visiteurs et remarquer ces détails.

Ce qui m'a frappé et incité a faire ces remarques est la mention "Optimisé pour Internet Explorer". J'ai tout de suite eu un flashback des années 2000.

 

Mes observations

Remarque Je suis conscient que la réalisation du site a pu être fait a la sauvette et qu'il y a peut être eu à faire plusieurs coins ronds, c'est malheureusement monaie courrante dans l'industrie du web. Le choix technologique imposé par la politique plutôt que l'expérience de celui réalisant le site peut aussi affecter la qualité. Pour contre-carrer les argumentaires vides, pourquoi ne pas s'armer en explications. Le but est constructif après tout :)

 

Annonce pour support spécifique Internet Explorer

Nous sommes en 2012. Le HTML5 est supporté et possible depuis 2009... même sous IE6.

Les conventions de navigation et la fonte du contenu par défaut est beaucoup trop petite, plus petite que la moyenne des sites

 

Données tableau en image

Votre page tarifs donne des données tabulaire en image

Quoi que très jolie image, des données alignées par des colones, un tableau est là pour ordonner des données par colones et rangées. La synthèse peut très mal se faire sur une image.

Je pourrai sortir l'argument de l'Accessibilité et vous allez me dire, un mal-voyant ne peut pas conduire. Peu importe. Une image c'est pour décorer.

 

Changement de pages en AJAX et URLs

Les pages changent sous en AJAX (exemple #joindre dans l'adresse) plutot qu'un URL unique par contenu avec adressage de langue au URL.

Si vous voulez réellement faire un changement à la AJAX, vous pouvez simplement capturer le clic sur certains liens (par usage d'une classe qui décrit le fonctionnement) puis un court bloc jQuery pourrait s'occuper de capturer le clic et changer le DOM via un $.ajax

Le pire n'est pas que si votre visiteur n'utilise pas javascript pour des prétextes de sécurité. Mais aussi le SEO, vous perdez du contenu et ce sont pourtant des pages légitimes avec contenus qui vaudraient la peine d'être indexés et augumenteraient la qualité du point de vue SEO.

J'insiste sur ce fait car c'est du contenu référence. Un cas acceptable serait si ce serait du contenu en relation au temps (comme twitter par exemple) ou une vue spécifique a un utilisateur dans une application web.

 

Le SEO. Je l'ai dit

D'accord, le SEO sert a optimiser la trouvabilité d'un document parmi plusieurs. Chaque partie d'un URI a son utilité. Jonas Jacek le décrit bien dans son billet à ce sujet.

Je ne suis pas un expert du SEO, mais regardons plus loin que cet argument. peut etre la valeut du mot dans le URL ou simplement un mauvais usage detourné.

Un URI dans ses composantes represente chaque element a son role. e.g. http://host/corps/du/uri?query=value#anchor alors le document pour me contacter serait dans le corps du url.

Le #hash dans le URL est normalement la pour representer un anchor (partie) dans UN document (parmi plusieurs) pas une page complete. Le Javascript supporte le history avec le #hash. Mais encore. Il degrade sans JS. Cool. Un hash est pour un anchor.

Pourquoi donc ne pas faire <div onclick="javascript:window.location=http://foo.bar/">Hola!</div>?. Parce que le <a /> sert a faire un lien. Meme chose pour un anchor.

 

Fichiers attachés utilisé pour toutes les "sauces"

Vos fichiers attachés sont des fichiers PDF plutot que d'être vers d'autres pages, encore perte de contenu cohérent et un signe d'echec d'usage d'un site web (un PDF est bon sur le web pour des formulaires ou on nécécessite impression et signature)

Les fichiers attachés ont des noms sous forme de phrases avec caractères spéciaux, nous ne sommes plus a l'époque du 8.3 (exemple de nom à l'époque: MONFIC~1.BMP) mais quand même.

Un fichier avec un nom résumé de deux trois mots ne nuit pas. Investissez plutôt du temps sur les méta données avant conversion au PDF et éviter d'avoir une tonne de fichiers au titre "Document Microsoft Word".

 

CSS sur-spécifique avec utilisation de #ID inutile

Les fichiers CSS et Javascript ne sont pas minifiés et/ou combinés, vous pourriez sauver du temps de chargement

Mais à mon opinion, la structure CSS démontre un certain manque de maîtrise de la structure en intégration de votre développeur web. Je ne suis pas parfait moi même, j'ai fait mon lot d'erreur, mais j'aimerai vous mettre au courrant qu'il y a beaucoup d'ouvrages et documentation sur les pratiques d'aujourd'hui que votre site pourrait profiter. La facilité de rendre votre site fonctionnel pour le mobile n'est qu'un parmi tant d'autres avantages.

Avez-vous déjà entendu parler de OOCSSou SMACSS?

Fin

Voilà, c'est mon premier billet dans la série de "Revue de code en Intégration web". J'espère que vous trouverez inspirant