Un peu de courage sur les formu­laires


La fainéan­tise est une superbe qualité pour un infor­ma­ti­cien. C’est ce qui fait que l’in­for­ma­ti­cien est capable de coder 20 minutes un script pour lui auto­ma­ti­ser une tâche qui prend 5 minutes de boulot tous les mois.

Main­te­nant parfois c’est abusé, et c’est trop souvent le cas sur les formu­laires.

[saisir le ] nom utilisé lors de votre commande en majuscule et sans accent [et] le téléphone fixe actuel

Sans rire, préci­ser « en majus­cules et sans accents » en gras c’est que le problème a été repéré lors de la concep­tion du formu­laire, ou que les retours clients en assis­tance télé­pho­nique ont été assez impor­tants pour justi­fier la modi­fi­ca­tion du texte.

Dans ce cas, vous ne croyez pas que la saisie devrait être libre ? À votre appli­ca­tion de mettre en majus­cules et de reti­rer les accents si ça lui chante, mais ne faites pas faire votre boulot à l’uti­li­sa­teur.

Le pire c’est pour le numéro de télé­phone parce que je l’ai vu dans *tous* les formu­laires d’opé­ra­teurs télé­pho­nie et inter­net. Le champ est bloqué à dix carac­tères, donc un numéro de télé­phone sans espaces.

Bon, c’est juste agaçant à la saisie, mais c’est surtout inuti­li­sable au copier-coller car quasi­ment tout le reste de la France utilise des espaces comme sépa­ra­teur. C’est donc à l’uti­li­sa­teur d’al­ler copier-coller le numéro dans un éditeur de texte pour reti­rer les espace et le copier-coller à nouveau dans le formu­laire.

Fran­che­ment, le déve­lop­peur n’avait pas la capa­cité de reti­rer lui même espaces et ponc­tua­tion côté serveur ? Ça coutait vrai­ment trop cher ?

Déve­lop­peurs : Soyez fainéants, mais ne faites pas faire votre boulot par vos utili­sa­teurs !

,

7 réponses à “Un peu de courage sur les formu­laires”

  1. 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.

    • 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

  2. 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.

    • 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.

  3. 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 ;-)

  4. 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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.