Les 4 pièges les plus fréquents du développement Web front-end

    Un guide pratique pour quiconque souhaitant se lancer dans le développement front-end ou avoir un rappel sur les principes essentiels de conception et les bonnes pratiques en matière d'expérience utilisateur pour la création de sites Web et d'applications en ligne interactifs.

    Abonnez-vous à notre blog

    Avec plus de dix ans d'expérience en tant que développeur Web front-end, j'ai connu un bon nombre de pratiques de développement et, en tant que visiteur de pages Web pendant bien plus longtemps, j'ai expérimenté leur effet. Cette sensation subjective d'utiliser efficacement une application interactive, cette pierre angulaire de mon travail, est connue sous le nom d'expérience utilisateur ou UX.

    Je pense qu’il existe un bon nombre de philosophies, de schémas et de styles de codage qui devraient être utilisés selon les préférences personnelles de chaque développeur, mais lorsqu'il s'agit de l'effet produit sur l'utilisateur final, j'ai un point de vue bien plus restrictif. Les interfaces Web qui sèment la confusion ou tout simplement hérissent l’utilisateur ont très peu de chances d'être de nouveau visitées.

    Parmi ces violations de l'étiquette de conception de l'UX, il y a une foule de mauvaises pratiques qui semblent revenir sans cesse. Je pense qu'il est temps d'en désigner quelques-unes dans l'espoir qu'elles disparaissent définitivement. Certaines d'entre elles sont un peu techniques, mais toutes ont un impact négatif profond sur ce qui devrait être une expérience utilisateur agréable − elles doivent donc toutes disparaître.

    1. Évolutivité de l'utilisateur : non

    Les développeurs Web utilisent des méta-balises pour fournir des informations supplémentaires et invisibles sur la page Web qu'ils présentent à un visiteur. Il peut s'agir d'informations permettant aux moteurs de recherche d'identifier le contenu, mais qui peuvent également affecter l'aspect de la page sur l'appareil de l'utilisateur.

    L'émergence de périphériques de navigation plus petits a entraîné l'apparition de la méta-balise viewport, qui permet à un développeur d'adapter la présentation du contenu de la page à la taille de l'écran de l'utilisateur, pour une mise en page plus réactive et conviviale. Toutefois, la méta-balise viewport permet également à un développeur de spécifier qu'un utilisateur ne peut agrandir une page Web.

    Cela peut s'avérer approprié dans des applications très complexes, mais ce n'est absolument pas le cas dans la majorité des pages Web. Le fait d'entraver un comportement inhérent au périphérique utilisé (tout le monde sait comment zoomer avec ses doigts) ne semble pas seulement paradoxal, mais empêche potentiellement les personnes avec une déficience visuelle d'accéder aux contenus. La méta-balise viewport « évolutivité de l'utilisateur : non » est souvent à l'origine de plusieurs problèmes de mise en page. En tant que développeur Web front-end, votre objectif est de créer des mises en page réactives et sans défaut pour une expérience utilisateur optimale.

    2. Touches cibles minuscules

    Les concepteurs Web créent souvent un magnifique objet graphique qui provoque chez l'internaute une réponse émotionnelle immédiate, mais ils peuvent oublier que le visiteur doit pouvoir naviguer facilement en quelques clics ou en effleurant l'écran. Le développeur de sites Web front-end doit s'assurer de la facilité d'utilisation du design créé et l'ajuster si nécessaire.

    Si l'aspect d'un élément avec lequel l'utilisateur doit interagir (tel qu'un lien ou un bouton) est trop petit, l'interaction avec l'espace qui l'entoure doit également pouvoir l'activer. L'espace visuel qui active un élément est désigné par le terme « touche cible » et il est trop souvent identique à l'élément lui-même, ce qui est potentiellement à l'origine d'une expérience utilisateur frustrante, en particulier sur les appareils tactiles.

    Exemple : Mise en place de touches cibles pour une navigation par carrousel

    Left: touch targets are too small and break the website visitor experience. Right: the way to implement carousel navigation, with a larger touch targets.

    Gauche : les touches cibles sont trop petites et nuisent à l'expérience du visiteur du site Web. Droite : la bonne façon de mettre en place une navigation par carrousel avec des touches cibles plus grandes.

    3. Manque d'étiquettes de formulaires, validation et navigation par clavier

    La saisie de l'utilisateur est essentielle pour produire des mises en page réactives.  Lorsque cette saisie est claire et rationalisée, elle profite indubitablement à la fois au visiteur et au créateur de l'application interactive. Nous savons maintenant reconnaître un champ de saisie de texte dès que nous voyons un rectangle indiquant que l'on peut saisir un texte à l'intérieur à l'aide d'indices visuels (tels que le pointeur de la souris qui se transforme en symbole de saisie lorsqu'il le survole).

    Un ensemble de champs de saisie groupés sur une page est nommé formulaire et il est essentiel que l'utilisateur sache ce qu'il faut saisir dans chaque champ. Pour ce faire, il faut placer une étiquette adjacente dans le code, qui identifie spécifiquement le type de saisie attendu. Il s'agit d'une pratique obligatoire en ce qui concerne l'accessibilité du Web, mais elle est souvent oubliée pour des raisons esthétiques ou par négligence. Un espace de texte réservé apparaît alors, un court exemple de texte qui occupe le champ avant que l'utilisateur ait saisi quoi que ce soit, qui est souvent utilisé à mauvais escient comme l'étiquette du champ. Le problème avec cette pratique apparaît clairement lorsque l'utilisateur a rempli les champs et a oublié ce qu'ils sont supposés représenter.

    Tout aussi importante : la validation de la saisie de l'utilisateur et l'application indiquant ce qui doit être corrigé. Il n'existe pas encore de moyen standardisé de mettre en place une validation de saisie de formulaire sur les principaux navigateurs. C'est un domaine où un code intelligent et fonctionnel peut inspirer la mise en œuvre de nouvelles fonctionnalités sur les navigateurs.

    Un autre point qui fait souvent défaut sur les sites Web, c'est la possibilité de faire défiler les différents champs uniquement à l'aide du clavier. Puisque l'utilisateur a sélectionné un mode de « saisie » dans lequel le clavier est la source d'entrée primaire, il devrait être possible de remplir tout le formulaire sans avoir à revenir sur les autres dispositifs de saisie.

    Exemple : Voici le problème lorsque l'espace de texte réservé dans un formulaire est utilisé comme étiquette. Le contexte est perdu lorsque les champs sont remplis.

    Using form placeholder text as labels

    4. Ambiguïté sur la façon de fermer une fenêtre contextuelle

    Heureusement, c'en est fini des pages Web ouvrant de nouvelles fenêtres de navigateur, plus petites, parce que le bloqueur de fenêtre contextuelle est devenu un composant intrinsèque des navigateurs modernes. Il reste néanmoins un cas d'utilisation clairement identifié pour fournir de l'information par-dessus le contenu normal et c'est à présent le rôle des développeurs Web de mettre en place ces fenêtres modales, selon le terme consacré, au sein de leur propre code HTML. Le problème le plus récurrent, est que l'utilisateur ne dispose pas de moyen clair de fermer la fenêtre. Il peut y avoir un bouton de fermeture (et il devrait y en avoir un selon les directives sur l'accessibilité), mais il peut ne pas être là où vous vous attendez à le trouver. Il n'y a également aucune norme définie sur ce qui devrait se produire lorsque l'utilisateur interagit avec le contenu qui se trouve sous la fenêtre. Cette action devrait-elle fermer la fenêtre, provoquant la perte potentielle de toute information fournie par l'utilisateur dans la fenêtre modale ou non ? De mon point de vue, l'utilisateur devrait au moins recevoir une notification pour vérifier que la fermeture de la fenêtre était véritablement l'action souhaitée. La même logique devrait s'appliquer à l'utilisation de la touche Echap sur le clavier qui est une action courante sur de nombreuses interfaces utilisateur interactives.

    Conclusion

    Le développement front-end est une activité de plus en plus complexe avec l'apparition constante de nouveaux outils et de meilleures pratiques. Travailler dans le développement front-end ou la conception de sites Web revient à créer des mises en page parfaites, aussi vous n'aurez jamais assez d'astuces pour rester sur la voie d'une bonne conception UX. Les développeurs front-end devraient connaître ces erreurs courantes, mais également les concepteurs UI, les développeurs back-end, les analystes fonctionnels, ainsi que les autres membres de votre équipe de projet digital. Au final, nous œuvrons tous à élaborer des sites Web interactifs, des services en ligne ou des portails de e-commerce aussi efficaces et conviviaux que possible, pour garantir des expériences client exceptionnelles.

    Publié sur    Dernière mise à jour le 20/12/2018

    #Développement Web

    À propos de l'auteur

    Mathijs Provoost is a Front-end Web Developer at Amplexor, based in Belgium. He’s responsible for writing and maintaining well designed, testable, efficient code for our clients’ public facing web-sites, web applications and lines of IT infrastructures. Mathijs also works closely with designers, developers, QA testers and support services teams to set the direction of our front-end technologies and lead their implementation.

    SUBSCRIBE TO OUR BLOG