Formulaires

Les formulaires sont au cœur des applications métier. Cette rubrique aborde les meilleures pratiques pour la création de formulaires, en matière d'ordre, de regroupement, de libellés, etc. Regardez la vidéo pour en savoir plus.

Les formulaires sont au cœur des applications métier. Ils doivent être à la fois clairs, faciles à remplir, concis et efficaces.

Prenez soin de regrouper et d'ordonner logiquement tous les champs. Considérez votre formulaire comme un questionnaire et imaginez que vous demandez oralement des informations à l'utilisateur. 

Les champs du formulaire doivent être ordonnés et regroupés de manière logique, en fonction de la priorité et du contexte. Ils doivent se lire comme des questions orales, plutôt que comme un formulaire. Vous pouvez faire le test auprès d'une personne extérieure à votre équipe : lisez les libellés et voyez si la personne comprend quelles informations sont demandées. Cette technique permet de déceler les libellés manquant de clarté et les champs mal ordonnés.

Les champs obligatoires ou essentiels doivent être affichés avant les champs moins importants ou optionnels, pour vous assurer que l'utilisateur ne les manque pas. Évitez également de placer un champ obligatoire au milieu de champs optionnels, car l'utilisateur risque de ne pas le voir.

Selon nos recherches, les utilisateurs remplissent plus rapidement un formulaire à une colonne. Un équilibre doit toutefois être trouvé entre la vitesse de remplissage et d'autres considérations. 

Si vous manquez par exemple d'espace, vous pouvez utiliser un formulaire à deux colonnes. Mais veillez à regrouper horizontalement les champs fortement corrélés, nom et prénom par exemple, ou plages de dates. Pour des données connexes de ce type, le regroupement est logique et fournit le contexte nécessaire.

Les titres peuvent être utiles pour séparer des groupes de champs et apporter plus de clarté, mais essayez de ne pas en abuser.

La largeur totale d'un formulaire ne doit pas dépasser 80 caractères. Un formulaire plus large est extrêmement difficile à utiliser et échouera aux tests d'accessibilité.

Assurez-vous que l'utilisateur pourra facilement parcourir l'ensemble du formulaire et que le passage d'un champ à un autre par la touche de tabulation se fera de manière logique.

Ceci garantit l'efficacité d'une application métier et la conformité aux règles d'accessibilité.

Pega offre une grande marge de manœuvre quant à la manière dont les données sont collectées. Vous pouvez ainsi utiliser, entre autres, des champs de texte, des zones de texte, des listes déroulantes et de la saisie semi-automatique. Cette grande liberté ne doit cependant pas vous empêcher de bien réfléchir aux meilleurs contrôles pour la collecte de données dans les formulaires. Par exemple, vous devez toujours utiliser un contrôle téléphone pour collecter les numéros de téléphone et non un champ textuel normal.

Vous devez également être cohérent dans la manière de collecter les données. Par exemple, si vous collectez des données dans un champ Région dans votre formulaire, ne le faites pas via un champ de type texte dans une section, et via une saisie semi-automatique dans une autre. 

Les libellés indiquent à l'utilisateur quelles informations il doit fournir dans un champ. 

Contrairement aux placeholders ou aux info-bulles, les libellés sont utiles à l'utilisateur lorsqu'il complète le champ, mais persistent aussi après saisie de texte dans le champ.

Les libellés doivent être succincts, courts et descriptifs (généralement un mot ou deux) pour favoriser une lecture rapide du formulaire.

Si un champ de texte s'accompagne d'un libellé clair, plus besoin d'utiliser d'info-bulles ou de placeholders, sources de complexité sans avantage majeur.

Les placeholders font appel à la mémoire à court terme de votre utilisateur : ils disparaissent dès que l'utilisateur commence à taper dans le champ. Les placeholders surchargent le formulaire et nuisent à sa lisibilité. Les titres et libellés doivent être clairs et guider l'utilisateur dans le formulaire. Ils répondent à deux objectifs majeurs : la simplicité et la clarté.

Il en va de même pour le texte d'aide qui apparaît parfois sous les champs. Nous recommandons de veiller à la clarté des titres et libellés, plutôt que d'ajouter un texte d'aide.

Les champs de type zone de texte doivent être configurés de manière à s'étendre automatiquement.

Un affichage initial à deux lignes suffit en général. 

Lorsqu'un utilisateur doit choisir parmi une série d'options dans un formulaire, le choix de l'élément de contrôle est essentiel. Utilisez la logique suivante pour choisir le meilleur élément de contrôle :

Pour des choix généraux de type oui/non sur un formulaire (booléens) avec un bouton Enregistrer/Soumettre visible à l'écran, utilisez une case à cocher.

Pour des choix de type oui/non (booléens) ne nécessitant pas l'activation d'un bouton Enregistrer/Soumettre, utilisez un bouton bascule.

Pour une plage de nombres, utilisez un curseur ou une échelle à cinq étoiles.

Pour un affichage horizontal de 2 à 7 options, utilisez un segment de boutons radio. Pensez à vérifier l'affichage du texte !

Pour un affichage vertical de 2 à 7 options, utilisez un groupe de boutons d'option.

Pour un nombre d'options supérieur à 7, utilisez la saisie semi-automatique.

Les listes déroulantes doivent être utilisées uniquement lorsqu'il est logique d'afficher une option présélectionnée par défaut. Elles ne doivent pas être utilisées pour moins de 7 options et/ou plus de 15. Les listes déroulantes de grande taille sont inutilisables, car elles obligent les utilisateurs à faire défiler la liste, ce qui est incommode et inefficace.

Remarque sur les listes déroulantes : si vous créez une interface utilisateur pour un appareil mobile et que vous souhaitez exploiter un élément de contrôle natif du système d'exploitation, vous devrez utiliser une liste déroulante. 

Dans la mesure du possible, placez les champs les plus larges et les plus longs sous les plus courts. Il peut s'agir de zones de texte, de cartes ou d'autres éléments de plus de 60 pixels. Des champs longs et larges placés en haut de formulaire pourraient cacher d'autres champs en les faisant sortir de la zone visible de la fenêtre d'affichage.

Passons en revue un formulaire problématique. Ce formulaire, peut-être hérité d'une très ancienne application, présente un certain nombre de problèmes.

Le formulaire est trop large. Les formulaires ne doivent pas dépasser 80 em, soit environ 80 caractères, en largeur. Les formulaires dont la largeur dépasse 80 em sont très peu efficaces, génèrent des erreurs et échouent aux tests d'accessibilité. Ce formulaire présente une barre de défilement, ce qui ne facilite pas sa lecture.

Les champs sont de largeurs et de hauteurs différentes, certains libellés sont en haut, d'autres à gauche. Ce manque de cohérence rend le formulaire extrêmement confus.

La majeure partie du formulaire semble se trouver dans un tableau, ce qui est très bizarre. Les en-têtes de colonnes servent de libellés aux champs situés en dessous, ce qui force l'utilisateur à constamment regarder vers le haut du tableau pour savoir à quoi correspondent les champs. Paradoxalement, alors que le formulaire semble avoir été conçu pour économiser de l'espace, sa structure peu orthodoxe, incohérente avec les autres formulaires auxquels les utilisateurs sont habitués, se traduit par beaucoup de place perdue. Les défauts d'alignement aggravent encore les choses.
 

Vérifiez vos connaissances avec l’interaction suivante.