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 la conception de formulaires est une compétence hautement spécialisée. Cela nécessite de comprendre comment les gens interagissent avecformation et comprendre les meilleures façons de collecter et de présenter dansformation. Là où la conception Web générale est principalement centrée sur la présentation dansformation et images de manière attrayante mais pratique, la conception des formes exige que nous concentrions notre attention sur la nature de l'intérieurformation, puis décidez de la meilleure façon de le structurer sur la page afin qu'il fonctionne comme prévu. L'esthétique est une considération moins importante dans ce cas, mais ne devrait toujours pas être pourgotten.
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 par ainsi que. 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 façon dont les formulaires peuvent être construits de manière plus intelligente. Pour ce faire, nous devons penser bien au-delà des valeurs par défaut. Nous devons être conscients de la desktop-les racines liées des contrôles de formulaire, ainsi que le besoin de compatibilité mobile. Et nous devons nous soucier de choses comme la convivialité 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 sont également utilisés pour afficher les données stockées. L'internaute moyen est (et devrait être) plus intéressé à entrerformation de vous que de céderformation à vous.
La collecte de données est facile. Les gens rempliront tout ce que vous collerez devant eux, même si c'est un gâchis. Mais en ce qui concerne l'affichage 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 l'affichage demande 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 écran mobile, alors les formulaires sont un meilleur choix que les tableaux… parfois!
2. Concevoir le desktop disposition
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 modéliser une conception de formulaire est d'utiliser InkScape. Dans cet exemple, nous allons créer un système de gestion des dossiers RH. Voici la maquette pour le desktop prototype:
Le rectangle extérieur représente tout l'espace d'un écran de 1024 x 768 px. Sur n'importe quel desktop navigateur, 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 de 900 x 600px, ce qui devrait tenir dans la zone disponible de la plupart desktop Écrans.
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 définissons simplement la propriété d'affichage des éléments d'étiquette sur «block», définissons 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 consiste à créer une rangée de colonnes imbriquées à l'intérieur de notre colonne principale, ce qui aidera à maintenir les contrôles correctement espacés. Le nombre de colonnes et leur taille changent en fonction des exigences de chaque ensemble de contrôles. Rappelez-vous que tout est responsive, ainsi, lorsqu'une colonne est redimensionnée, tout ce qui se trouve à l'intérieur de la colonne essaie de se redimensionner pour correspondre au changement. C'est une bonne nouvelle pour les utilisateurs malvoyants, car ils peuvent agrandir le grossissement sur leur écran et tout sera aligné correctement 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 les données relatives à la religion, il est nécessaire de choisir parmi une liste prédéfinie de religions officielles prédéfinies (y compris "autres"). Développer les colonnes de droite était encore plus facile et utilisait simplement les mêmes techniques que celles du premier ensemble de contrôles sur la colonne de gauche, en organisant les contrôles dans un tableau format, mais sans utiliser de table.
Pour que ce projet soit un succès, il devait fournir une parfaite responsiveness sur toutes les tailles d'affichage 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 qu'on puisse s'en contenter. En fait, c'est même une amélioration. Voyons maintenant le responsive mise en page à chacune des différentes sections de la page :
Bootstrap et HTML5 ont rendu le développement de formulaires plus rapide et plus facile que jamais, mais de nombreux développeurs compromettent ce progrès en rendant les formulaires trop compliqués (en utilisant les éléments de formulaire spéciaux HTML5 simplement parce qu'ils sont là pour être utilisés plutôt que parce qu'ils sont nécessaires pour le projet ), et en créant des formes entièrement unidimensionnelles qui ne tentent même pas de tirer parti de responsive motif. Avec juste un peu de soin et de travail supplémentaire, toutes les données peuvent être rendues plus présentables sur n'importe quelle taille 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
Commentaires Réponses 0