33.3 Développer un formulaire Web ergonomique

La majorité des sites Web comportent au moins un formulaire : pour entrer en contact avec l'administrateur, pour gérer les données (si on détient les droits requis), etc.

Votre expérience en tant qu'utilisateur de différents sites Web vous a sans doute démontré que certains formulaires sont très rapides à remplir alors que d'autres prennent une éternité. Certains sont agréables alors que d'autres sont carrément mal conçus. Certains sont clairs alors que pour d'autres, on se demande qu'est-ce qui est attendu de nous.

Voici à titre indicatif quelques commentaires positifs et constructifs sur un formulaire réel.

En tant que développeur Web, vous devez connaître les principales règles qui permettront de rendre un formulaire Web ergonomique. Voici donc quelques-unes des meilleures pratiques pour développer un formulaire.

Titre

Le formulaire débutera toujours par un titre clair suivi, si nécessaire, d'une indication du rôle de ce formulaire.

Focus

Le focus doit être dans la première case de saisie dès le départ.

Libellés

L'usager doit savoir ce qui doit être entré dans une zone de saisie dès le premier coup d'oeil et ce, même lorsque certains champs sont déjà remplis. Il faut donc éviter de n'utiliser comme libellé que le filigrane (en anglais : watermark), identifié par l'attribut placeholder.

Validation

L'usager doit connaître les règles de validation des informations saisies dès le premier coup d'oeil.

• Les champs obligatoires seront marqués d'un astérisque.

  Petit truc : il est possible d'ajouter une règle CSS qui insère automatiquement un astérisque devant les libellés qui ont la classe "requis".

  Ex :

  CSS

  /* ************************************************************************************* */

  /* champs de saisie obligatoires */

  /* source : christianelagace.com */

  /* ************************************************************************************* */

  label.requis:before {

      content: "* ";

  }

  HTML

  <div class="form-group col-lg-4">

      <label for="nom" class="requis">Nom</label>

      <input type="text" class="form-control" name="nom" id="nom">

  </div>

• La taille des contrôles sera une indication de la taille de l'information attendue (ex : la case de saisie d'une quantité sera plus petite que celle pour saisir un nom).

  

• Les formats de validation seront indiqués à côté des champs (ex : format du numéro de téléphone, nombre de caractères du mot de passe).

  

• La rétroaction sur les erreurs de validation (et sur les données valides, pourquoi pas!) doit être fournie à l'usager le plus rapidement possible. C'est pourquoi la validation côté client avec JavaScript et plus intéressante que la validation côté client avec HTML : elle permet de fournir une rétroaction dès qu'un caractère est entré ou dès qu'un champ perd le focus, alors que la validation HTML n'entre en jeu que lorsque l'usager soumet le formulaire. N'oubliez pas que seule la validation côté serveur joue un rôle au niveau de la sécurité.

  Voici à titre d'exemple un formulaire qui fournit une rétroaction intéressante.

  

  Formulaire tiré de https://community.silabs.com/SL_CommunitiesSelfReg

Informations saisies

Le formulaire doit être aussi court que possible (lire : facile à remplir).

• Les seules informations obligatoires sont celles qui sont vraiment nécessaires (ex : la saisie d'un avatar pour un usager devrait être optionnelle car on pourra utiliser un avatar par défaut pour ceux qui n'en ont pas choisi un).
• Dans un formulaire qui saisit un mot de passe, toujours placer le mot de passe juste après le code d'usager. En effet, le navigateur saura quel champ est le mot de passe (type="password"). Pour retrouver le champ qui est le code d'usager, il prendra celui qui est juste avant. C'est ainsi que le navigateur pourra enregistrer la combinaison code d'usager/mot de passe pour une page Web.
• N'afficher à l'écran que les informations qui ajoutent à la compréhension des données. Par exemple, lorsqu'un nouvel usager est créé, si son statut est obligatoirement "nouveau", il n'est pas utile d'afficher cette information à l'écran.
• Si certaines informations ne doivent être saisies que dans un cas particulier, elles ne doivent apparaître que lorsque le cas se présente (ex : on ne demandera le numéro de produit que si la requête concerne un produit).
• Le choix du type de zone de saisie (case de saisie, boutons radio, cases à cocher, liste déroulante, etc.) est également important. Voir des exemples ici : http://www.lukew.com/ff/entry.asp?1950

Valeurs par défaut

• Dans le cas d'un formulaire de modification, toutes les cases doivent afficher au départ les informations actuelles.
• Dans le cas d'un formulaire d'ajout, il faut s'assurer que lors d'un second ajout, les cases ont été remises à blanc après le premier enregistrement. 
• Certaines cases pourraient être pré-remplies. Par exemple la date d'une réservation pourrait être la date du jour par défaut. L'usager pourra modifier cette information si désiré.

Pour plus d'information

« 10 Best Practices for Web Forms ». JotForm. http://www.jotform.com/help/121-10-Best-Practices-for-Web-Forms 

« Contact Us Page Best Practices with 22 Fabulous Showcases ». OXP. http://www.onextrapixel.com/2009/10/15/contact-us-page-best-practices-with-22-fabulous-showcases/