Gestion des indicatifs régionaux dans les champs des numéros de téléphone
Ok, donc je sais qu'une question similaire (ish) a été posée avant re: format convivial pour les numéros de téléphone .
Ma question se concentre cependant sur une partie plus spécifique de cette question, à savoir le premier problème "abandonné" dans le code de la ville.
Je cherche à repenser un formulaire Web dans lequel l'utilisateur entre actuellement son téléphone et j'essaie de rendre les problèmes de code ville/code local moins ambigus.
J'ai inclus quelques exemples dans l'image ci-jointe.
L'option A est telle que le formulaire est actuellement. Dans ce cas, l'utilisateur (en supposant de Londres) pourrait entrer de nombreuses variantes sur le code de la ville. Je sais que je m'arrête parfois et pense quand j'arrive à ce point dans un formulaire "Quel est le format le plus approprié"?
dois-je entrer le zéro ou non, donc j'entre le signe plus, les crochets, les tirets ou tout autre caractère, etc.
Option B - comporte une note sous le champ qui affiche à l'utilisateur le format préféré à saisir.
L'option C pré-saisit le code de ville et entre le 0 initial pour l'utilisateur, donc 207 pourrait être entré ici.
Option D - une liste déroulante dynamique dont le contenu change en fonction de l'option choisie par l'utilisateur dans la première liste déroulante (pays).
Qu'en pensez-vous? Il y a un élément d'orientation/d'information que j'aime au sujet de l'option C bien que peut-être qu'il soit toujours un peu ambigu à sa manière. Option D Je pense que ce n'est tout simplement pas possible pour diverses raisons.
Ou si quelqu'un sait que quelqu'un a d'autres idées ou connaît des modèles existants qui gèrent bien ce problème, je serais intéressé d'en discuter ici.
Il y avait quelques grandes recherches effectuées par Jessica Enders sur ce sujet fin 2009 (en se concentrant sur les numéros de téléphone australiens). Ses recherches ont montré que les utilisateurs entrent généralement les numéros de téléphone comme une longue chaîne de chiffres
Comme les numéros de téléphone mobile, une longue chaîne de chiffres - y compris l'indicatif régional - était la méthode la plus courante de saisie des données: sur 640 numéros de téléphone fixe fournis par les participants à la recherche intéressés, 39% ont été saisis comme une longue chaîne de 10 chiffres (c.-à-d. sans espace ni segmentation).
Mais, compte tenu de votre question, de nombreux utilisateurs n'entrent pas leur code régional, même lorsqu'ils y sont explicitement invités:
Fait intéressant, dans 11% des cas, les 8 chiffres de la partie principale du numéro de téléphone fixe ont été fournis, sans interruption, mais aussi sans l'indicatif régional, bien qu'il soit explicitement demandé via une légende à côté du champ. Si nous avions eu une validation sur le terrain, cela signifie que plus de 10% des utilisateurs auraient connu un échec de validation .
Avec cette recherche incorporée, l'option B semble être la plus appropriée, d'autant plus que vous fournissez un exemple de la façon de remplir votre numéro de téléphone. Un avantage supplémentaire est que vous pouvez utiliser le HTML5 input type=tel type de champ pour permettre aux agents utilisateurs de fournir une aide à la saisie ( en particulier sur les appareils mobiles ).
Attendez-vous à ce que les utilisateurs saisissent des traits d'union, des espaces, des astérisques, des touches de hachage/dièse et des parenthèses (au moins) si vous prenez en charge les variations régionales et internationales. Idéalement, votre implémentation devrait permettre toute combinaison de ponctuation pour la saisie (supprimer la ponctuation pour la validation). L'idéal étant que si quelqu'un considère son numéro de téléphone comme une valeur continue, il est également soutenu comme quelqu'un qui pense son numéro de téléphone par paires de chiffres.
L'option B est la meilleure car elle guide les utilisateurs sans être trop restrictive.
Dans l'option A, le format est absolument inconnu, ce qui déroute les utilisateurs. Le zéro de tête dans l'option C peut confondre les utilisateurs qui ont déjà développé la mémoire du moteur d'entrer leur numéro de téléphone avec l'indicatif régional et le zéro de tête. Et l'option D est carrément compliquée car il existe des centaines d'indicatifs régionaux (et certains sont attribués à plusieurs localités), les utilisateurs devront donc effectuer des recherches considérables.
Une autre méthode consisterait à séparer l'indicatif régional du numéro de téléphone (comme les options C et D) mais en indiquant clairement le masque des données sous la zone de saisie (c'est-à-dire en donnant un exemple comme dans votre option B) et en passant automatiquement à la zone suivante (zone code au numéro de téléphone) en ignorant la ponctuation afin que les utilisateurs puissent les saisir comme ils le souhaitent. Cependant, vous devez savoir que les formats des numéros de téléphone changent d'un pays à l'autre, votre masque doit donc changer en fonction du pays sélectionné par l'utilisateur.
Vous pouvez ajouter une autre couche de validation en séparant les 4 premiers caractères des données saisies par les utilisateurs et en les comparant à votre liste d'indicatifs régionaux valides.
Je suis d'accord avec Paweł & Denis pour l'option B
J'ajouterais à la réponse de @dnbrv, qu'il vaudrait mieux que vous deviniez l'emplacement de l'utilisateur, afin qu'il ne doive pas trop défiler.
En ce qui concerne les indicatifs régionaux et les formats de numéros de téléphone, il y en a tellement qu'ils peuvent nécessiter beaucoup de travail pour tous les énumérer. Et cela ne tient pas compte du fait que ces chiffres pourraient changer ... À moins que vous n'autorisiez la modification (saisie d'autres indicatifs régionaux) pour ce menu déroulant, ce n'est qu'une question de temps pour verrouiller certaines personnes ...
Pour la saisie de données et le tableau, utilisez une zone de texte au lieu de numérique. À la recherche, convertissez-le si nécessaire. Convertissez le texte en nombres et s'il y a un 0 en tête, ajoutez-le à nouveau. Voir ce fil. https://www.pcreview.co.uk/threads/how-do-i-allow-a-leading-zero-in-an-access-number-field.3692368/
En français (ma langue maternelle) il n'y a pas d'extension. J'ai l'habitude d'ajouter l'indicatif régional lors de la soumission de formulaires sur des sites Web étrangers, donc dans ma solution d'utilisation quotidienne A, ce serait le meilleur.