La quête de formulaires Web plus intelligents

Les formulaires en ligne sont l’un des domaines les plus difficiles du développement de sites Web à résoudre, en particulier avec tant de problèmes qui peuvent survenir. La nature changeante de la manière dont les gens accèdent au contenu en ligne a également eu une incidence sur une technologie mise au point des années avant que les gens ne sachent pouvoir utiliser un téléphone comme ils ne le feraient normalement avec un ordinateur. C'est une technologie qui a très peu évolué.

La conception de formulaires Web devrait être une profession autonome. Les concepteurs de site doivent faire appel aux services de concepteurs de formulaires Web professionnels à temps plein pour les aider dans leur tâche. Mais ceci n’est pas considéré comme étant suffisamment économique, et le plus souvent, le concepteur du site est également responsable de la conception des formulaires utilisés sur le site.

Mais concevoir des formes est une compétence hautement spécialisée. Cela nécessite de comprendre comment les gens interagissent avec l'information et de comprendre les meilleurs moyens de collecter et de présenter l'information. Lorsque la conception Web générale est principalement centrée sur la présentation des informations et des images de manière attrayante mais pratique, la conception de formulaires exige que nous concentrions notre attention sur la nature des informations, puis que nous décidions du meilleur moyen de les structurer de manière à ce qu'elles fonctionnent correctement. prévu. L'esthétique est une considération moins importante dans ce cas, mais ne doit pas être oubliée.

Dans cet article, nous allons examiner l'art de la conception de formulaires Web et voir si nous pouvons trouver un moyen de rendre nos formulaires Web plus intelligents, à la fois en termes d'apparence et de fonctionnement.

Les outils de création de formulaires Web

Les outils standard fournis par les développeurs de navigateurs et W3C pour assembler nos formulaires Web ne sont pas tout à fait idéaux. Avant de leur appliquer du CSS, ils étaient plutôt hideux. Voici à quoi ils ressemblent:

Il existe également un autre contrôle d’entrée standard appelé Sélectionner, mais évitez de l’utiliser sauf si vous gagnez de l’espace. Il existe de meilleurs moyens de gérer la tâche effectuée par le contrôle de sélection, comme nous le verrons plus tard. Les contrôles Textarea doivent également être évités lorsque cela est possible car ils sont tellement problématiques et antiquaires.

Outre ces éléments d’entrée standard, il existe également de nouveaux éléments spéciaux créés pour HTML5. Sauf lorsqu'un document est préparé exclusivement pour un usage interne et que l'environnement du navigateur est connu, seuls les composants fonctionnant à la fois dans Firefox et Chrome doivent être utilisés. C'est bien si un composant fonctionne aussi dans d'autres navigateurs, mais cela ne devrait pas uniquement. travailler dans d'autres navigateurs. Voici les composants HTML5 tels qu'ils apparaissent dans Firefox:

Et leur apparence légèrement différente dans Chrome:

Maintenant, évidemment, il est très important de savoir que vos entrées HTML5 ressembleront et fonctionneront différemment entre Chrome et Firefox, mais elles continueront de fonctionner. Les contrôles d’entrée standard sont également un peu plus agréables dans Chrome que dans Firefox. Notez que Chrome impose la norme de date nord-américaine, que les utilisateurs ne comprendront peut-être pas. De plus, la version Chrome du contrôle de date le rend inapproprié pour l'affichage et ne doit être utilisé que pour la saisie. L'ajout d'un sélecteur de date est la principale amélioration de Chrome, mais on peut probablement s'attendre à ce que cela se produise dans les futures versions de Firefox.

Étant donné que Firefox est une source ouverte, vous pouvez créer votre propre version personnelle de Firefox en rendant les entrées de la même manière que Chrome en téléchargeant le code source open source du navigateur Chromium sur lequel Chrome est basé et en transférant la section de code correspondante à la source Firefox. code (mais vous devrez le faire chaque fois que vous mettez Firefox à niveau vers une nouvelle version).

Le point principal est cependant que, même avec les améliorations de Chrome, l'apparence par défaut des contrôles de saisie est petite et peu attrayante. Il existe quelques autres contrôles disponibles, mais comme ils ne fonctionnent pas dans Chrome et Firefox, ils ne doivent pas être utilisés sur des sites destinés au public.

La réponse de Bootstrap (presque adéquate)

Bootstrap applique un style aux contrôles standard pour améliorer leur apparence dans une certaine mesure. Toutefois, en raison de la philosophie de conception centrée sur le mobile de Bootstrap, il provoque certains effets indésirables sur les formulaires qui ne sont pas destinés à être affichés sous forme de colonne unique, et donne un aspect amusant aux champs de saisie courts lorsqu'ils couvrent une colonne entière par défaut. Le monde est peut-être devenu mobile, mais les formulaires n'ont pas été inventés pour les utilisateurs mobiles.

Bootstrap développe les contrôles pour qu'ils remplissent la largeur horizontale de leur conteneur, ce qui signifie que tous les contrôles auront la même largeur, que vous le vouliez ou non (sauf si vous annulez manuellement ce comportement), et vous permet d'habiller certains types de contrôle avec davantage de bling. La solution de Bootstrap est élégante et résout certains problèmes de contrôles ayant des apparences différentes selon les navigateurs, mais elle ne fonctionne qu'avec les contrôles standard. Les contrôles HTML5 n'étant pas implémentés dans les versions actuelles de Bootstrap, vous devrez les personnaliser vous-même.

Bootstrap vous permet également de combiner des contrôles ensemble. Parfois c'est bon et parfois pas si bon. La combinaison d'une saisie de texte avec un bouton et une case à cocher peut sembler intéressante, mais elle peut induire l'utilisateur en erreur quant à la manière dont il doit interagir avec un contrôle aussi inconnu.

Ce que Bootstrap fournit, c’est deux de mes dispositifs de création de formulaires préférés, le panneau et le Puits. Celles-ci sont très utiles pour regrouper les données de formulaire afin de donner une indication visuelle des données associées à quelles autres données, ainsi que pour la séparation des données.

Smart Form Building 101

Nous sommes maintenant prêts à réfléchir à la manière dont les formulaires peuvent être construits de manière plus intelligente. Pour ce faire, nous devons penser au-delà des valeurs par défaut. Nous devons être conscients des racines des contrôles de formulaire liés au bureau, ainsi que de la nécessité de la compatibilité mobile. Et nous devons nous préoccuper de choses comme la facilité d'utilisation et la validation (si le formulaire sera utilisé pour la collecte de données).

Ce dernier point est bon, car si les contrôles de formulaire sont utilisés pour collecter les entrées, ils servent également à afficher les données stockées. L'internaute moyen est (et devrait être) plus intéressé à obtenir des informations de votre part qu'à vous donner des informations.

La collecte de données est facile. Les gens vont remplir tout ce que vous collez devant eux, même si c'est un gâchis. Mais quand il s'agit d'afficher des données, ils sont plus difficiles. Par conséquent, nous nous concentrerons ici davantage sur l’utilisation de formulaires pour afficher des données que pour les collecter, car leur affichage nécessite plus de soin et plus d’intelligence.

1. Avons-nous besoin d'un formulaire?

Avant de créer un formulaire, nous devons vérifier que nous en avons réellement besoin. Si les données peuvent être représentées de manière adéquate et sans confusion sous forme de tableau, un tableau sera généralement plus efficace et plus pratique.

Un formulaire est nécessaire si:

  • Nous recueillons les commentaires de l'utilisateur
  • Nous avons beaucoup de données à afficher
  • Les données doivent être clairement segmentées
  • L'utilisateur est susceptible d'accéder aux données à partir d'un appareil mobile

Si l'un des éléments ci-dessus n'est pas vrai, il n'est pas nécessaire d'utiliser un formulaire et un tableau suffit. Le défi auquel nous sommes confrontés avec la compatibilité mobile est que ni les tableaux ni les formulaires ne sont vraiment adaptés à un affichage mobile. Le fait que les concepteurs de smartphones aient donné à leurs utilisateurs la possibilité d’utiliser un navigateur en mode portrait et que la plupart des utilisateurs préfèrent tenir leur téléphone de cette manière est à l’origine de la plupart des problèmes de compatibilité mobile auxquels les concepteurs de site sont confrontés.

Quoi qu'il en soit, les formulaires sont plus adaptables à un affichage mobile que les tableaux. Donc, si vous devez vraiment vous assurer que toutes les données peuvent être facilement visualisées sur un affichage mobile, alors les formulaires sont un meilleur choix que les tableaux… parfois!

2. Concevoir la disposition du bureau

Il est vrai qu'en général, vous êtes censé concevoir d'abord une présentation mobile, mais en ce qui concerne les formulaires, ce n'est pas la meilleure solution, car nous avons besoin de savoir comment les données vont être regroupées et nous ne pouvons le faire que si nous: peut voir tous les champs en même temps, ce qui est impossible sur un mobile à moins d'afficher si peu de données qu'il ne soit pas inutile de concevoir le formulaire.

Le moyen le plus rapide de simuler une conception de formulaire consiste à utiliser InkScape. Dans cet exemple, nous construirons un système de gestion des enregistrements de ressources humaines. Voici la maquette du prototype de bureau:

Le rectangle extérieur représente tout l'espace d'un affichage 1024 x 768 px. Sur tous les navigateurs de bureau, nous n’avons accès à autant de pixels que si l’utilisateur est en mode plein écran (ce qui est rarement le cas). Donc notre

la conception est 900 x 600px, qui devrait tenir dans la zone disponible de la plupart des écrans de bureau.

Lorsque la surface disponible est inférieure à 900px, nos colonnes 2 x 450px se cassent et apparaissent sous la forme d’une colonne continue 450px. Cela résout le problème de la compatibilité mobile, du moins jusqu'à ce que Google demande à ce que tous nos sites s'adaptent sur un écran de montre-bracelet.

Vous remarquerez que la plupart des affichages sont juste composés de boîtes de saisie ordinaires, ce qui peut paraître ennuyeux, mais est en réalité presque toujours la meilleure façon de le faire. Notez également l'utilisation d'une police à largeur fixe. Cela aide à garder l’uniformité dans la conception des formulaires.

Nos colonnes auront en réalité un peu plus de 450px, ressemblant davantage à 600px, mais si nous voulons forcer la largeur de la colonne à environ 450px, nous réduisons simplement la taille de notre colonne de 6 à 5. Mais une colonne 600px devrait tenir sur un écran mobile en mode portrait sans envelopper, de toute façon.

Nous allons tester notre mise en page avec ce code:

Et nous pouvons voir que tout va bien (parce que nous avons temporairement ajouté des frontières pour nous montrer).

Le widget de règle d’écran Linux ne fait évidemment pas partie de la page Web, mais il est là pour nous montrer que nos colonnes ne se briseront pas mal sur un écran plus petit. Voyons ce qui se passe à différentes largeurs d'écran communes:

3. Création de tailles d’entrée et de position d’étiquette

Si nous laissons tout simplement par défaut, sans ajouter de CSS personnalisé, voici ce qui se passera lorsque nous ajouterons notre première ligne de contrôles d'entrée:

Cela est dû au fait que l'étiquette de chaque entrée est placée par défaut à gauche de l'entrée et que nous n'avons pas défini de largeur personnalisée pour les contrôles d'entrée. Nous pouvons résoudre les deux problèmes avec CSS.

Maintenant, nous venons de définir la propriété display des éléments d'étiquettes sur «block», les champs de First et Last sur la classe «in40w», et le champ MI sur la classe «in10w», et tout devrait être beaucoup plus joli.

Comme vous pouvez le constater, ça a l'air mieux, mais la mise en page n'est plus correcte. Maintenant les boîtes sont empilées. Nous avons donc résolu le problème en supprimant l'idée d'utiliser l'élément label, car nous n'en avons pas vraiment besoin. Nous allons simplement appliquer notre in40w et in10w classes, plus faire une nouvelle classe appelée inLeftOf.

Ce qui, une fois appliqué, corrige le problème que nous avons vu précédemment, comme ceci:

Mais cela ne laisse pas assez de place pour le champ SSN. C’est parce que notre colonne de gauche est plus grande que prévu, donc 40% représente en réalité plus d’espace que nécessaire pour ces champs, de sorte que nous pouvons réellement les réduire à in30w, et le champ intermédiaire est plus grand que nécessaire, pour que nous puissions le faire in5w. Voici ce qui se passe:

Alors maintenant, il y a plus de place que nécessaire pour ajouter le champ SSN, qui complète la première ligne de notre formulaire de saisie. Après avoir lissé tous ces détails, il sera très facile de construire le reste de la colonne de gauche. Nous pouvons supprimer la bordure temporaire maintenant et appliquer également le bon arrière-plan à la colonne. Voici la moitié supérieure du panneau, avant de passer aux zones spéciales du formulaire:

Quelques choses sont arrivées à ce stade. La première consistait à définir facilement la couleur d’arrière-plan de la colonne (rgb (235,235,246)). Bien que vous ne puissiez pas la voir ici, la couleur du texte de toutes les entrées a été définie sur #427DB4. a été mis en gras afin de réduire la fatigue oculaire. Le texte a été défini pour se transformer automatiquement en majuscule à l'aide de la propriété CSS text-transform, de manière à accélérer la saisie des données et à réduire les erreurs.

Le problème plus complexe consistant à aligner les contrôles et à s’assurer qu’ils garderaient un alignement correct sur tout type d’affichage nécessitait plus de réflexion. Vous avez déjà vu la technique utilisée pour la première ligne d'entrées et leurs étiquettes. Cette technique fonctionnera s'il n'y a pas besoin d'espacement supplémentaire entre les entrées, mais si nous avons besoin d'ajouter de l'espace, il est préférable d'utiliser une autre technique.

Cette autre technique implique la création d'une rangée imbriquée de colonnes dans notre colonne principale, ce qui aidera à garder les contrôles correctement espacés. Le nombre de colonnes et leur taille varient en fonction des exigences de chaque ensemble de contrôles. N'oubliez pas que tout est réactif. Ainsi, lorsqu'une colonne est redimensionnée, tout ce qu'il y a à l'intérieur tentera de le redimensionner en fonction du changement. C’est une bonne nouvelle pour les utilisateurs malvoyants, car ils peuvent agrandir l’agrandissement de leur affichage et tout sera correctement aligné comme pour tout autre utilisateur.

Passant maintenant à la partie plus complexe de la colonne de gauche, le concept initial décrit dans la maquette appelait une structure qui aurait été difficile à mettre en œuvre. Heureusement, j'ai réalisé que les données du panneau des droits pourraient être doublées si les cases à cocher standard étaient utilisées, ce qui a parfaitement résolu le problème de la complexité de la présentation:

Les panneaux plus légers autour des sections spéciales ne sont que des puits Bootstrap ordinaires. Pour saisir des données sur une religion, il est nécessaire de choisir parmi une liste de religions officielles prédéfinies (y compris «autre»). Développer les colonnes de droite était encore plus facile et utilisait les mêmes techniques que le premier jeu de contrôles de la colonne de gauche, organisant les contrôles dans un format de tableau, mais sans utiliser de tableau.

Pour que ce projet soit un succès, il fallait qu'il soit parfaitement réactif sur toutes les tailles d'écran officielles. Voyons comment le résultat s'est avéré. D'abord avec la version pleine résolution:

C'est assez proche du prototype pour que nous puissions en être satisfaits. En fait, c'est même une amélioration. Voyons maintenant la disposition sensible dans chacune des différentes sections de la page:

Bootstrap et HTML5 ont rendu le développement de formulaire plus rapide et plus simple qu'auparavant, mais de nombreux développeurs sapent cette avancée en rendant les formulaires trop compliqués (en utilisant les éléments de formulaire HTML5 spéciaux simplement parce qu'ils sont là pour être utilisés au lieu de parce qu'ils sont nécessaires au projet. ), et en créant des formes entièrement unidimensionnelles qui ne tentent même pas de tirer parti de la conception réactive. Avec juste un peu de soin et un travail supplémentaire, toutes les données peuvent être rendues plus présentables sur toutes les tailles d'écran.

Vous pouvez obtenir quelques problèmes mineurs sur la plus petite taille d'écran dans la mise en portrait de la plus petite taille (dans le cas de ce projet, le champ Initiale du milieu sur la première ligne est un peu plus petit que l'idéal), mais les utilisateurs mobiles en général accepter que c’est le compromis qu’ils doivent faire pour ne pas tenir leur téléphone correctement.

Faites-le correctement et vos formulaires de données peuvent ressembler à ceci:

Au lieu de, euh, ceci:

image d'en-tête avec la permission de

Avatar

Bogdan Rancea

Bogdan est un membre fondateur d’Inspired Mag, ayant accumulé près de 14 années d’expérience 6 au cours de cette période. Dans ses temps libres, il aime étudier la musique classique et explorer les arts visuels. Il est également obsédé par les fixies. Il possède déjà 5.