Un peu de courage sur les formulaires

La fainéantise est une superbe qualité pour un informaticien. C’est ce qui fait que l’informaticien est capable de coder 20 minutes un script pour lui automatiser une tâche qui prend 5 minutes de boulot tous les mois.

Maintenant parfois c’est abusé, et c’est trop souvent le cas sur les formulaires.

Sans rire, préciser « en majuscules et sans accents » en gras c’est que le problème a été repéré lors de la conception du formulaire, ou que les retours clients en assistance téléphonique ont été assez importants pour justifier la modification du texte.

Dans ce cas, vous ne croyez pas que la saisie devrait être libre ? À votre application de mettre en majuscules et de retirer les accents si ça lui chante, mais ne faites pas faire votre boulot à l’utilisateur.

Le pire c’est pour le numéro de téléphone parce que je l’ai vu dans *tous* les formulaires d’opérateurs téléphonie et internet. Le champ est bloqué à dix caractères, donc un numéro de téléphone sans espaces.

Bon, c’est juste agaçant à la saisie, mais c’est surtout inutilisable au copier-coller car quasiment tout le reste de la France utilise des espaces comme séparateur. C’est donc à l’utilisateur d’aller copier-coller le numéro dans un éditeur de texte pour retirer les espace et le copier-coller à nouveau dans le formulaire.

Franchement, le développeur n’avait pas la capacité de retirer lui même espaces et ponctuation côté serveur ? Ça coutait vraiment trop cher ?

Développeurs : Soyez fainéants, mais ne faites pas faire votre boulot par vos utilisateurs !

Publié

4 août 2012

dans

Développement web, Vie personnelle

par

Éric

Étiquettes :

Commentaires

7 réponses à “Un peu de courage sur les formulaires”

Vincent

4 août 2012

Je suis parfaitement d’accord avec ça mais je vais pourtant me faire l’avocat du diable. Il ne s’agit pas que de faire faire le boulot par les utilisateurs, il y a aussi une question de responsabilité.

Si j’ajoute la ligne de code qui retire les espaces et les ponctuations à mon numéro de téléphone, cela fait une fonctionnalité supplémentaire qui comme toute fonctionnalités doit être documentée dans la spec, dans la doc utilisateur, vérifier par des tests unitaires puis par les tests de recettes.

Parfois, le processus de développement est tellement rigide que le cout total d’ajout d’une simple fonctionnalité parait supérieur à passer la main au support : « Ajouter un message informatif », « Ajoutez ça dans la FAQ ».

Bref, ces petits détails d’ergonomie doivent absolument être mentionnées durant la conception car le développeur a vite fait de se retrouver cloisonné dans le processus de développement et choisir de minimiser les impacts en retenant la solution la plus rapide.

Répondre
1. Éric D.
  
  5 août 2012
  
  Si tu veux refuser ces saisies il faut aussi le documenter, le tester, etc. Ca ne coute pas aussi cher mais bon… quand même…
  
  Je crois que c’est surtout ce que tu exprimes dans ton dernier paragraphe : des développeurs cloisonnés, pas impliqués du tout sur le produit, probablement prestataires, qui ont appliqué ce qu’on leur demandait, puis par la suite ou pendant la recette on a précisé les messages d’erreur plutôt que corriger le code parce que personne n’avait de vision produit ou d’autorité pour imposer les correctifs
Jose

5 août 2012

Je ne suis pas développeur mais je pense qu’il s’agit aussi d’éduquer les utilisateurs, lorsque je remplis un formulaire papier j’ai les mêmes consignes (avec ou sans majuscule, avec ou sans tiret, date à inscrire dans un certain format, etc.). Ensuite, si j’entre mon prénom avec majuscule et avec accents (c’est d’ailleurs vraiment étrange en 2012 de devoir écrire son prénom/nom sans majuscule et sans accent, je me demande parfois à quoi servent l’ascii-étendu, l’unicode et compagnie, et si quelque chose doit être fait pour les utilisateurs c’est justement la prise en charge de ces caractères qui existent tout de même dans la langue française !) je trouverais vraiment étrange si je les retrouvais sans majuscule et sans accents dans une facture par exemple.

Pour le numéro de téléphone, il s’agit de celui de l’utilisateur, je ne vois d’où il ferait un copier-coller de son propre numéro qu’il devrait connaître non?

Dernièrement avez-vous testé le formulaire (ce n’est pas dit dans l’article) pour voir s’il ne fait pas cette vérification en plus d’en avertir l’utilisateur par un message ? Je rencontre pleins de formulaires de ce type.

Répondre
1. Éric D.
  
  5 août 2012
  
  C’est bien parce que je l’ai subit que j’écris là :) Moi aussi j’en vois plein de ces formulaires, et c’est bien le problème.
  
  Oui, sur papier on a parfois des contraintes… qui ont du sens sur papier. On demande généralement de saisir en majuscules pour la lisibilité, parce que les écritures cursives de chacun sont souvent illisibles pour d’autres. Par contre même et surtout dans la plupart des formulaires administratifs, on demande bien les accents (au passeport ils insistent même sur le fait que si tu oublies un accent ou une cédille, le dossier sera refusé).
  
  Mais tout ça, sur informatique n’a plus de sens. C’est 15 secondes pour un développeur de faire passer la saisie en majuscule. Il n’y a aucune raison de récupérer les contraintes du papier.
  
  Quant au numéro de téléphone, pour une inscription Internet, je suppose qu’il s’agit le plus souvent du numéro du voisin (pour tester si l’appartement est éligible) ou du numéro de l’ancien locataire (quand on emménage). Là on les prends dans l’annuaire avec un joli copier/coller. D’ailleurs c’est justement ce que ces mêmes opérateurs conseillent de faire dans ces cas là. Je suppose que la majorité des saisies viennent de là.
  
  Le mien c’était un numéro *de ligne*, c’est à dire ma ligne lors de l’inscription à mon FAI précédent qui depuis a donné un 09. Le numéro qui n’a servi que pour l’inscription je ne le connais pas par coeur (le numéro fixe actuel en 09 non plus d’ailleurs vu que je ne l’utilise quasiment pas). Je reconnais que ce cas ne doit pas être le plus courant, mais dans ce formulaire, celui où on tape son propre numéro qu’on connait par coeur doit probablement être le cas le plus rare.
Beta Testeurs

5 août 2012

Je suis d’accord avec l’intention de ce billet sur la nécessité de prendre en charge le maximum de traitement côté serveur.

J’apporterai toutefois un bémol sur les sites qui, a contratrio, en « font trop ». En effet, certains développeurs truffent les pages d’Ajax chargé de formater avant l’envoi les différents formats des saisies utilisateurs. Cela peut parfois créer des erreurs (je pense par exemple à l’ajout automatique de l’indicatif pays +33 pour la france après remplissage du champ numéro de téléphone, qui ne supprime pas le « 0 » de la ligne, et qui n’est pas rattrapable).

Il faut donc trouver le juste milieu, et beta-tester, faire tester moultes fois par des profils utilisateurs variés, avant la mise en production ;-)

Répondre
karl

5 août 2012

et j’imagine aussi que la société ne s’adresse qu’à un public bien local. Car imagine le sans majuscule, sans accent avec le nom 山田.

Répondre
Yvain Liechti

6 août 2012

J’ai remarqué que ce genre de problème venait rarement du développeur qui lui-même pensait à la liberté de l’utilisateur mais plutôt d’un contexte historique de l’entreprise comme une vielle base de donné ou tous les noms sont en majuscule qu’une autre application ancestrale utilise et qui plante si elle reçoit un accent. Dans l’absolu on se dit que c’est ce vieux bouzin qui doit être corrigé ou changé et non-pas le formulaire tout neuf. Donc en attendant on met un petit message … jusqu’à ce que le bouzin en question soit mis à jour ou pas

Répondre