La validation est l’un des aspects les plus importants d’une bonne conception Web. Voyons de quoi il s'agit et comment vérifier la validité du code HTML. À titre d’exemple, prenons le système de gestion de contenu (CMS) le plus courant : WordPress. Après quoi, nous partagerons une liste des erreurs que nous avons rencontrées dans la pratique et, surtout, nous proposerons nos propres méthodes éprouvées pour les éliminer.

Pourquoi est-il nécessaire de vérifier la validité d’un site internet ?

En termes simples, la vérification d'une page Web déterminera si elle répond aux normes développées par le World Wide Web Consortium (W3C). Cela se fait généralement en vérifiant la validité des pages individuelles à l'aide du service de validation en ligne du W3C.

Tout comme il existe des règles de grammaire dans différentes langues, il existe également des règles de programmation. La vérification vous permet de voir si la page est conforme à ces règles, et s'il y a des erreurs ou des avertissements, des recommandations seront fournies pour les résoudre. Nous discuterons plus en détail de la nécessité d’une telle vérification ci-dessous.

Qu’est-ce qui influence la validité d’un site ?

Vous êtes-vous déjà demandé comment les navigateurs « lisent » une page Web ? Ils disposent de « moteurs » pour analyser le code et le transformer en une forme visuelle pour les gens. Malheureusement, chaque navigateur possède son propre mécanisme de traitement de code, ce qui peut entraîner un affichage différent de vos pages.

Une page Web incorrecte peut être lue différemment par les navigateurs. Cela aura pour conséquence que vos visiteurs ne pourront même pas voir correctement le contenu de la page dans leur navigateur. La validation corrigera ultérieurement presque toutes les différences majeures et rendra votre page Web lisible par presque tous les navigateurs Web (l'exception la plus courante étant les anciennes versions d'Internet Explorer). C'est de là que vient le terme « mise en page multi-navigateur » – c'est-à-dire : mise en page qui est tout aussi bonne (compatible) pour tous les navigateurs populaires.

Comment cela affectera-t-il le référencement ? Il est important de comprendre que les robots des moteurs de recherche adorent les pages Web sémantiques. La mise en page sémantique, selon Wikipédia, est une approche de création de pages Web en HTML, basée sur l'utilisation de balises HTML conformément à leur sémantique (objectif). De plus, une page Web sémantique structurelle permet aux robots de recherche de déterminer plus précisément la signification des éléments individuels de la page Web et de l'ensemble du texte dans son ensemble. Selon Google, un code valide n’affecte en rien le classement des pages. Mais en même temps, la présence d'erreurs dans le code peut affecter négativement l'analyse du micro-balisage et l'adaptation aux appareils mobiles.

Outils de validation pour votre site Web

Comprenant la nécessité de l'absence d'erreurs de validation sur les pages du site, voyons comment rechercher ces erreurs.

Il existe de nombreux services gratuits pour la vérification de sites Web, tels que le service de validation de balisage du W3C, l'analyseur de pages Web, Browsershots et autres.

Les humains ont tendance à faire des erreurs. Des bugs se produisent lorsque les gens interagissent avec les interfaces utilisateur. Parfois, cela se produit parce que les utilisateurs font des erreurs. Parfois, des erreurs se produisent dans l'application elle-même. Quelle qu’en soit la cause, les erreurs et leur gestion ont un impact énorme sur l’UX. Une gestion incorrecte des erreurs ainsi que des messages d'erreur inutiles peuvent provoquer une réaction négative de la part de l'utilisateur, ce qui peut ensuite conduire l'utilisateur à refuser d'utiliser votre application.

Dans cet article, nous verrons comment optimiser la conception de votre application pour éviter les erreurs des utilisateurs et comment créer des messages d'erreur efficaces lorsque des erreurs se produisent, quel que soit ce que l'utilisateur tape. Nous verrons également comment une erreur bien gérée peut transformer l’échec en plaisir. Adobe a introduit une nouvelle application de conception et de conception, Experience Design (Adobe XD), qui vous permet de concevoir des conceptions interactives et des états d'erreur. Vous pouvez télécharger et essayer Adobe XD gratuitement.

Qu'est-ce qu'une condition d'erreur ?

Un état d'erreur est un écran qui s'affiche à l'utilisateur en cas de problème. Ceci est un exemple de situation dans laquelle l'utilisateur fait quelque chose qui est différent de l'état souhaité. Étant donné que des erreurs peuvent survenir dans des combinaisons inattendues, ces conditions peuvent inclure des problèmes allant d'opérations utilisateur incompatibles (telles qu'une saisie de données incorrecte) à l'incapacité d'une application à se connecter au serveur ou même à l'incapacité de traiter une demande utilisateur.

Écrans d'erreur

Chaque erreur, quelle que soit sa cause, devient une pierre d'achoppement pour l'utilisateur sur le chemin de l'avancement de l'UX. Heureusement, une erreur bien formatée peut réduire l’effet désagréable.

Mieux vaut prévenir que guérir

Si vous créez une application, vous devez comprendre quelles interactions utilisateur de base avec l'application peuvent provoquer une erreur. Par exemple, il est généralement très difficile de remplir correctement un formulaire du premier coup, ou il est impossible de synchroniser correctement les données si l'appareil dispose d'une mauvaise connexion réseau. Vous devez prendre ces points en compte pour minimiser les risques d'erreurs. En d’autres termes, il est préférable d’éviter la possibilité de commettre des erreurs en faisant preuve de conseils, en utilisant des limites et en faisant preuve de flexibilité.

Par exemple, si vous donnez aux gens la possibilité de rechercher et de réserver des hôtels, pourquoi laisser les dates passées disponibles et générer une erreur si l'utilisateur sélectionne cette date ?

Comme le montre l'exemple de Booking.com, vous pouvez simplement utiliser un sélecteur de date qui permet aux utilisateurs de sélectionner uniquement la date du jour et les dates futures. Cela encouragera les utilisateurs à sélectionner uniquement des dates valides.

Sélection de la date dans l'application Booking.com. Le mois complet est affiché, mais les dates passées ne sont pas disponibles. Écran d'erreur pour la validation du formulaire

La forme est communication. Comme toute communication, elle doit être représentée par une communication cohérente entre deux parties : l'utilisateur et votre application. La validation joue un rôle majeur dans ce processus de communication. La validation des formulaires est conçue pour guider les utilisateurs à travers les complications, les erreurs et les malentendus. Avec une validation appropriée, une telle communication devient claire et compréhensible. En général, une bonne validation de formulaire se compose de quatre éléments importants :

• Corriger le moment pour signaler les erreurs (ou la réussite)
• Le bon endroit pour le message de validation
• Corriger la couleur du message
• Langue de message claire

Timing correct (validation de chaîne)

La validation des erreurs de formulaire est inévitable et constitue une partie logique de la saisie des données utilisateur (puisque la saisie des données utilisateur peut être accompagnée d'erreurs). Bien entendu, les conditions pouvant provoquer une erreur doivent être minimisées, mais la validation des erreurs ne peut pas être supprimée. La question la plus importante est donc la suivante : « Comment puis-je faciliter le processus de récupération des erreurs pour l'utilisateur ? »

Les utilisateurs n'aiment pas le processus de remplissage d'un formulaire, surtout lorsqu'ils reçoivent un message d'erreur à la fin. Il est particulièrement frustrant de recevoir des messages d'erreur dans plusieurs champs après avoir rempli un long formulaire. Et le plus ennuyeux est le manque de clarté sur les erreurs que vous avez commises et où.

La validation doit immédiatement informer l'utilisateur de l'exactitude d'une réponse donnée immédiatement après que l'utilisateur a saisi les données. Le grand principe d’une bonne validation est : « Parlez aux utilisateurs ! Dites-leur ce qui ne va pas ! » et la validation des chaînes en temps réel informe les utilisateurs de l'exactitude des données saisies. Cette approche permet aux utilisateurs de corriger rapidement les erreurs et de ne pas attendre que les erreurs s'affichent après avoir cliqué sur le bouton de confirmation.

Cependant, vous devez éviter de valider chaque frappe car dans la plupart des cas, vous ne pourrez pas valider les données avant que l'utilisateur ait fini de taper sa réponse. Les formulaires qui valident la valeur immédiatement lors de la saisie commencent à irriter l'utilisateur dès qu'il commence à saisir des données.

Google Forms affiche une erreur d'e-mail même si vous n'avez pas encore fini de taper.

En revanche, les formulaires qui valident après la saisie des données n'informent pas assez rapidement l'utilisateur d'une erreur.

La validation dans l'Apple Store a lieu après la saisie des données.

Mikhail Konzhevich dans son article « Validation de chaînes dans les formulaires - créer une expérience ! a exploré différentes stratégies de validation et proposé une stratégie hybride : récompense précoce, punition tardive.

Hybride - Récompense précoce, punition tardive - Approche au bon endroit

L'orientation utilisateur est un autre outil important. Lorsque vous vous demandez où placer votre message de validation, suivez ce conseil : placez toujours le message dans le contexte d'une action. Si vous souhaitez signaler à l'utilisateur une erreur dans un champ spécifique, affichez-la à côté. La validation rapide est mieux placée à droite du champ de saisie ou en dessous.

Erreurs dans le formulaire en temps réel. La bonne couleur (design intuitif)

La couleur est l'un des meilleurs outils à utiliser lors de la création d'une validation. la façon dont cela fonctionne à un niveau intuitif, les couleurs rouge pour indiquer une erreur, jaune pour indiquer un avertissement et vert pour indiquer un succès sont particulièrement puissantes. Mais assurez-vous que les couleurs sont bien perçues par les utilisateurs. Il s’agit d’un aspect essentiel d’une bonne conception visuelle.

Le texte de l’erreur doit être clair et se démarquer clairement de l’arrière-plan de la candidature. Message clair

Un message d'erreur typique peut indiquer « l'e-mail est incorrect », sans expliquer à l'utilisateur pourquoi l'e-mail est incorrect. (Typographie ? E-mail pris par un autre utilisateur ?) Des instructions ou des directives simples peuvent rendre les choses différentes. Vous pouvez voir dans l'exemple comment le formulaire informe l'utilisateur que son email est déjà pris. Aussi, plusieurs suggestions apparaissent (récupération de login ou de mot de passe).

Il est donc temps d'afficher une page d'erreur pour montrer que quelque chose s'est mal passé. A titre d'exemple, imaginons une situation où la connexion est perdue et l'utilisateur se retrouve sur un écran qui est le seul disponible. Vous devez profiter de cette opportunité pour informer les gens de ce qui se passe et fournir un modèle d'aide rapide. Votre message doit être un coup de main pour les utilisateurs. Par conséquent, vous ne devez jamais afficher les éléments suivants :

• Message d'erreur critique. Les messages qui indiquent une erreur interne dans le code de l'application ou contiennent du texte comme « une erreur de type 2 s'est produite » sont énigmatiques et intimidants.

Un message d'erreur écrit par un développeur pour un développeur.

• Erreur de blocage. Tout simplement parce que de tels messages ne fournissent aucune information utile à l'utilisateur.

L'écran d'erreur sur Spotify indique « Une erreur s'est produite » et ne fournit aucune option ni étape pour résoudre le problème.

• Message d'erreur non spécifié. Cet écran (dans l'exemple ci-dessous) donne à l'utilisateur la même quantité d'informations que le précédent. Les utilisateurs n’ont aucune idée de ce que cela signifie ni de quoi faire à ce sujet.

L'application Buffer a un joli message d'erreur, mais elle ne fournit aucune information à l'utilisateur.

N'effrayez pas l'utilisateur avec des erreurs. N’essayez pas non plus de guider l’utilisateur dans les détails techniques du problème. Parlez de l’erreur dans un langage simple et compréhensible. Pour ce faire, essayez de ne pas utiliser de jargon technique et d'exprimer vos réflexions dans la langue de l'utilisateur.

Rendez vos messages lisibles et utiles : les erreurs doivent être polies, claires et instructives, et contenir des informations telles que :

• Qu'est-ce qui n'a pas fonctionné et pourquoi (peut-être).
• Que doit faire l'utilisateur pour corriger l'erreur.

L'application Remote explique pourquoi les utilisateurs ne peuvent rien voir et propose une solution. Incluez de l'humour et des images dans les messages d'erreur

Les messages d'erreur sont une excellente occasion d'utiliser des icônes et des illustrations, car les gens perçoivent mieux les informations visuelles que le simple texte. Mais vous pouvez aller plus loin et ajouter à votre application des images qui seront utiles aux utilisateurs. Cela personnalisera votre candidature et adoucira votre message.

Azendoo utilise l'illustration et l'humour pour inciter l'utilisateur à résoudre un problème.

L'humour prolonge la vie. Un peu d'humour ne fait jamais de mal et contribuera à atténuer la confusion liée à une erreur. Vous pouvez trouver des tonnes d’exemples de messages amusants sur Littlebigdetails. Voici quelques-uns de mes favoris:

• Basecamp : Lorsqu'il y a une erreur de validation de formulaire, le héros de gauche affiche une expression de surprise sur son visage.

• Un message d'erreur un peu coquin s'affiche lorsque vous essayez de saisir trop de points lors de la création d'un nouveau compte dans Gmail.

Attention cependant à l'humour car il n'est pas toujours approprié dans votre rapport de bug ; cela dépend de la gravité de l'erreur. Par exemple, l’humour fonctionne bien pour un simple problème de validation comme une « erreur 404 » (page introuvable). Mais lorsqu'un utilisateur passe un certain temps à regarder une page qui dit « Oh ! - cela semble inapproprié.

Liste de contrôle complète de la page d'erreur idéale

Les bonnes pages d’erreur sont un coup de main pour les utilisateurs et doivent répondre aux six critères suivants :

Le message d'erreur apparaît de manière dynamique, immédiatement après la détection d'une erreur. Il doit informer l'utilisateur du problème.

Soyez prudent pour les données saisies. Votre application ne doit pas interrompre, supprimer ou annuler ce que l'utilisateur a saisi ou téléchargé lorsque l'erreur s'est produite.

Parlez la même langue avec l’utilisateur. Le message doit fournir une compréhension claire de ce qui n'a pas fonctionné et pourquoi ; Que doit faire l’utilisateur pour corriger l’erreur ?

Ne choquez pas et ne confondez pas les utilisateurs. (Le message ne doit pas être très provocateur).

Ne perdez pas le contrôle du système. (Si le problème n'est pas critique, l'utilisateur devrait pouvoir le faire avec le reste de l'application).

Utilisez le sens de l'humour pour atténuer le problème.

Solutions aux erreurs les plus courantes Erreur 404 (page introuvable)

L’objectif principal d’une page d’erreur 404 est de rediriger votre utilisateur vers la page qu’il recherchait le plus rapidement possible. Votre page 404 doit proposer plusieurs liens clés vers lesquels l'utilisateur peut accéder. L’option la plus sûre est d’avoir un lien vers la « page d’accueil » du site sur la page 404. En outre, vous pouvez placer un « signaler un problème » pour permettre à l'utilisateur de vous informer que la page ne fonctionne pas. Mais assurez-vous que la transition vers la page d'accueil est une transition plus claire et se démarque davantage visuellement.

Problème de connexion

L'écran du formulaire de connexion semble souvent minimaliste et contient un champ pour saisir un nom d'utilisateur et un champ pour un mot de passe. Mais minimalisme n’est pas synonyme de simplicité. Il existe de nombreuses raisons pour lesquelles un utilisateur peut rester bloqué sur l'écran de connexion. La règle principale de la page de connexion est de ne pas laisser l’utilisateur deviner.

Examinons les solutions aux problèmes les plus courants à l'aide d'exemples de MailChimp, qui fait un excellent travail sur les messages d'erreur.

• L'utilisateur a oublié son nom sur le site. Si vous trouvez un bug comme celui-ci, vous devez proposer un lien permettant à l'utilisateur de le corriger. Indiquez à l'utilisateur où il peut l'obtenir (par exemple : « vérifiez votre courrier électronique, nous vous avons envoyé un courrier électronique ») ou fournissez un lien pour restaurer le nom sur le site.

Les utilisateurs font de nombreuses tentatives pour se connecter au site en utilisant un mauvais mot de passe. Pour éviter de telles attaques de serveur, les comptes d'utilisateurs sont bloqués après trop de tentatives infructueuses. Il s'agit d'une pratique de sécurité courante, mais l'utilisateur doit être averti avant que son compte ne soit suspendu.

Carte de crédit refusée

Un refus de carte de crédit peut survenir pour plusieurs raisons : une erreur de formatage des données (faute de frappe ou données manquantes), ou la carte peut être refusée car elle est expirée ou volée. Gabriel Tomescu, dans son article « Anatomie d'un formulaire de carte de crédit », a suggéré la stratégie suivante pour les deux erreurs :

Pour le premier problème, vous devez suivre la validation de chaîne standard et l'indication visuelle d'erreur :

Cependant, lorsqu’une carte de crédit est rejetée par un processeur de paiement pour une raison quelconque, cela ressemble généralement à un vol. Vous avez besoin de données claires de la part de l'utilisateur. Et même après cela, vous devez toujours informer l'utilisateur de ce qui s'est passé ; Le message d'erreur doit être très clair.

Problème de connection

La connexion Internet n'est pas disponible partout et le support hors ligne devrait être un aspect clé dans la vie de toute application moderne. Lorsque la connexion est interrompue, vous devez réfléchir attentivement à l'UX hors ligne. Les utilisateurs doivent pouvoir interagir avec autant de parties de votre application que possible. Cela signifie que l'application doit mettre en cache le contenu pour une bonne UX hors ligne.

Mots clés: , , ,

Il n’y a rien de plus fastidieux que de remplir un formulaire pour prospects mal conçu sur une page de destination. Rappelez-vous combien de fois vous avez dû remplir tous les champs parce que le mot de passe que vous avez trouvé ne correspondait pas au système selon certains critères, dont personne n'a essayé de vous informer à l'avance.

Gardez à l’esprit que l’optimisation des formulaires pour prospects est un élément clé du processus d’optimisation des conversions et que l’accent principal doit ici être mis sur la validation sur le terrain.

Qu'est-ce que la validation du formulaire pour prospects ?

La validation du formulaire pour prospects est un processus technique au cours duquel le système vérifie l'exactitude des données saisies par l'utilisateur. Si une personne a commis une erreur en remplissant le formulaire (par exemple, en indiquant des données dans un mauvais format), le système lui indiquera cette erreur (ou simplement sa présence) et lui proposera de la corriger. Si l'utilisateur a saisi correctement toutes les données, aucun message supplémentaire n'apparaîtra (ou une coche apparaîtra à côté du champ) et il passera à l'étape suivante d'enregistrement.

Par exemple, Twitter ne vous permettra pas de passer à l'étape d'inscription suivante si vous saisissez votre adresse e-mail dans un mauvais format :

Lorsque vous saisissez votre adresse e-mail au format requis par le système, une coche apparaîtra à côté du champ indiquant que le format des données saisies est correct :

L'essence de la validation est de garantir que les utilisateurs saisissent les données dans le format requis par le système (par exemple, l'adresse e-mail doit être conforme à la norme [email protégé], mais, par exemple, le mot de passe doit contenir au moins 7 caractères).

Il existe deux principaux types de formulaires de validation.

Analyse des erreurs de validation du site

Finalement, j'ai eu du temps libre entre les interminables séries de commandes et j'ai décidé de créer mon blog. Essayons de l'améliorer en termes de validation. Ci-dessous dans l'article, je vais vous expliquer ce qu'est la validation d'un site Web, du code html et css, pourquoi elle est nécessaire et comment mettre un site Web aux normes à l'aide d'un exemple spécifique.

Qu'est-ce que la validation de site ?

En termes simples, il s'agit d'un test de conformité aux normes. Pour que n’importe quel navigateur puisse afficher correctement votre site. La validité du site n’a pas un grand impact sur la promotion, mais cela n’aggravera certainement pas les choses.

Un exemple spécifique de réussite de la validation pour une page de site Web

Prenons la première page qui apparaît sur mon site Web - Encodage et décodage Base64 dans Java 8. Entrons l'adresse de la page dans le validateur et regardons le résultat :

Erreurs trouvées lors de la vérification de ce document au format HTML 4.01 Transitional ! Résultat : 105 erreurs, 67 avertissements Oui, le tableau qui se dégage est désagréable : plus d'une centaine d'erreurs et 67 avertissements - comment les moteurs de recherche indexent-ils mon blog et les gens le visitent-ils ? Mais ne nous énervons pas, mais apprenons à subir la validation et à corriger les erreurs. Alors, premier avertissement :

Impossible de déterminer le mode d'analyse ! Le validateur peut traiter les documents au format XML (pour les types de documents tels que XHTML, SVG, etc.) ou SGML (pour HTML 4.01 et versions antérieures). Pour ce document, les informations disponibles n'étaient pas suffisantes pour déterminer sans ambiguïté le mode d'analyse, car : Le type de média MIME (text/html) peut être utilisé pour les types de documents XML ou SGML Aucun type de document connu n'a pu être détecté Aucune déclaration XML (par exemple) se trouve au début du document. Aucun espace de noms XML (par exemple) n'a pu être trouvé à la racine du document. Par défaut, le validateur revient en mode SGML. Attention Aucun DOCTYPE trouvé ! Vérification avec le type de document de transition HTML 4.01 par défaut. Aucune déclaration DOCTYPE n'a pu être trouvée ou reconnue dans ce document. Cela signifie généralement que le document ne déclare pas son type de document en haut. Cela peut également signifier que la déclaration DOCTYPE contient une faute d'orthographe ou qu'elle n'utilise pas la syntaxe correcte. Le document a été vérifié à l'aide d'une définition de type de document « de secours » par défaut qui ressemble beaucoup à « HTML 4.01 Transitional ». C'est le même. Et le correctif est simple : ajoutez la balise au tout début de la page :

Vérifions ce que nous avons fait et voyons qu'avec cette seule balise, nous avons supprimé 105 erreurs et 3 avertissements ! Il ne nous reste plus que 64 avertissements. Commençons par les démonter un par un.

Avertissement : l'attribut type de l'élément style n'est pas nécessaire et doit être omis. À partir de la ligne 5, colonne 1 ; à la ligne 5, colonne 23 /x-icon">↩↩↩↩↩A Cela signifie que l'élément de style n'a pas besoin d'un attribut de type - c'est superflu. Nous avons deux commentaires de ce type sur la page. Un avertissement similaire s'applique à JavaScript :

Attention : L'attribut type n'est pas nécessaire pour les ressources JavaScript. De la ligne 418, colonne 1 ; à la ligne 418, colonne 31 ↩↩$(doc Nous avons 8 de ces erreurs. Nous supprimons ces attributs et hourra - encore 10 avertissements en moins !

Erreur : CSS : background : Le premier argument de la fonction de dégradé linéaire doit être top, pas top. À la ligne 39, colonne 61 0%,#E8E8E8 100%);↩ border-r L'erreur suivante est que le premier argument de gradient linéaire devrait être vers le haut, pas vers le haut. Nous allons le réparer. Erreur suivante :

Erreur : CSS : erreur d'analyse. De la ligne 65, colonne 13 ; à la ligne 65, colonne 16 margin: 0 auto;↩padd Ici, j'ai mal commenté le CSS. Il vous suffit de supprimer cette ligne. Ou commentez /* et */ différemment. Je l'ai fait comme avant.

Erreur : CSS : @import n'est pas autorisé après toute instruction valide autre que @charset et @import.. À la ligne 88, colonne 74 0,600,700,300);↩@import url(// Nous avons maintenant une erreur d'importation. Déplaçons ces lignes vers au tout début du fichier et il disparaîtra.

Erreur : valeur _blanck incorrecte pour la cible de l'attribut sur l'élément a : mot clé réservé vide utilisé. De la ligne 241, colonne 218 ; à la ligne 241, colonne 295 cookies..php?id=98" target="_blanck" style="display: inline;">Ici Ensuite, on n'aime pas la valeur de l'attribut target, on nous dit qu'il nous faut pour utiliser « vide » sans le trait de soulignement devant. Supprimons-le.

Erreur : la balise de fin a été vue, mais il y avait des éléments ouverts. De la ligne 379, colonne 2 ; à la ligne 379, colonne 6

↩ ↩↩

↩↩↩↩↩↩
↩↩
↩↩↩