Saisie d'adresses à l'aide de la saisie semi-automatique
J'ai une application Web où l'utilisateur devra remplir de nombreuses adresses (quelques utilisateurs saisissant les adresses d'autres personnes ). Il utilise la saisie semi-automatique pour accélérer les choses et réduire la duplication (la base de données contient presque toutes les rues de la ville). Le plus souvent, la rue dans laquelle l'utilisateur entre existe déjà, mais dans les rares cas, l'utilisateur ne peut pas la taper régulièrement et le back-end la créera à nouveau.
J'utilise un champ input distinct pour chaque partie d'adresse (enter ou tab - et parfois space - passe à la suivante), car même si la rue n'est pas connue, peut-être le quartier, et à défaut la ville le sera probablement, etc. Je m'attends à ce que dans le "cas commun" l'utilisateur tape environ 5 caractères au total et tout le reste (rue, quartier, ville, état, pays , code postal) sera automatiquement renseigné pour lui, afin qu'il puisse procéder au numéro et au complément (qui sera différent à chaque fois).
Mon problème est que, dans mon pays, l'ordre "naturel" des adresses est le suivant:
St. Foo 123/456 ...
au lieu de:
Foo St. 123/456 ...
Comment dois-je configurer l'ordre des champs? J'ai vu dans ne autre question que ce n'est pas une bonne idée de changer l'ordre d'affichage, mais si je garde d'abord le "type" (rue, avenue, etc.), l'utilisateur perdra du temps à tout taper le moment où le champ "rue" pouvait le remplir automatiquement pour lui. Cependant, lors de la saisie d'une adresse inconnue, ce champ devra être tapé (afin qu'il puisse être correctement enregistré dans la base de données), il devra donc y revenir.
J'ai pensé à quelques possibilités (avec différents degrés de difficulté à mettre en œuvre), et j'aimerais avoir des commentaires sur la meilleure utilisation possible:
- Le champ "rue" commence concentré; si l'utilisateur sélectionne quelque chose dans le menu déroulant, alors le "numéro de rue" est focalisé ("type" est rempli automatiquement); s'il essaie de passer au champ suivant à la place (une nouvelle rue sera créée), alors le focus revient sur "type" au lieu de passer sur "numéro".
- ... et en s'éloignant de "type", il saute "rue" et passe au "nombre"; ou:
- ... et en s'éloignant de "type" il revient à "rue", et la prochaine fois qu'il s'éloigne, il passe en "nombre".
- Le champ "rue" commence focalisé, et le cycle de focalisation normalement; si l'utilisateur entre dans une nouvelle rue, le champ "type" obtient une bordure rouge, et l'utilisateur décide quand et comment il reviendra pour la remplir.
- J'utilise un seul champ pour "type" et "rue", et j'essaie de perfectionner ma saisie semi-automatique pour tenir compte des différentes combinaisons que l'utilisateur peut taper ("Av Foo", "Av. Foo", "Avenida Foo", "A. Foo "," Foo ").
Toute autre suggestion est également la bienvenue.
La dernière option, en utilisant un seul champ pour le type et la rue est probablement la meilleure. Cela dit, passons en revue les trois options et voyons où sont les forces/faiblesses de chacune:
Le champ "rue" commence concentré; si l'utilisateur sélectionne quelque chose dans le menu déroulant, alors le "numéro de rue" est focalisé ("type" est rempli automatiquement); s'il essaie de passer au champ suivant à la place (une nouvelle rue sera créée), le focus revient sur "type" au lieu de passer sur "numéro".
Que se passe-t-il, par exemple, dans le cas d'une ville où existent la 49th Avenue et la 49th Street? Si l'utilisateur entre "49" dans le champ du nom de la rue, que remplit-il alors automatiquement dans le champ "type"? Je ne sais pas comment vous mettriez en œuvre la 2e moitié de ce scénario ("s'il essaie de passer au champ suivant à la place (nouvelle rue
sera créé), puis le focus reviendra au "type" "), mais cela pourrait provoquer une incohérence pour l'utilisateur. à "numéro de rue". Ensuite, ils utilisent le formulaire une deuxième fois et saisissent un nom de rue. Le formulaire se comportera différemment les deux fois, et peut être déroutant.
Le champ "rue" commence focalisé, et le cycle de focalisation normalement; si l'utilisateur entre dans une nouvelle rue, le champ "type" obtient une bordure rouge, et l'utilisateur décide quand et comment il reviendra pour la remplir.
Cela est problématique car, dans le cas où l'utilisateur saisit (sciemment) un nouveau nom de rue, cela donne une indication qu'il fait une erreur (le rouge indique généralement une erreur commise, dans les formulaires), alors qu'en fait il n'est pas - il vient d'ajouter un nouveau nom de rue.
J'utilise un seul champ pour "type" et "rue", et j'essaie de perfectionner ma saisie semi-automatique pour tenir compte des différentes combinaisons que l'utilisateur peut taper ("Av Foo", "Av. Foo", "Avenida Foo", "A. Foo "," Foo ").
Peut-être la plus problématique à mettre en œuvre, mais aussi la meilleure:
Il offre à l'utilisateur une flexibilité dans l'identification d'une rue via des recherches de sous-chaîne. Parfois, les noms de rue prêtent à confusion - c'est-à-dire que dans le nom de rue "Cherry Hinton Road", quelqu'un peut ne se souvenir que de "Cherry Road", "Hinton Road" ou "Cherry Hinton". Cela prend également en charge le problème de la 49th Avenue/49th Street que j'ai mentionné ci-dessus.
Il permet une flexibilité dans le placement du "type". Parce que, alors que la notation d'adresse standard dans votre pays peut être Type. Nom. Nombre, les formulaires Web s'adressent si souvent à un public américain que les gens apprennent à utiliser des normes qui ne sont pas les leurs. Cela permettra à vos utilisateurs, même s'ils ne savent pas quel format vous souhaitez, de continuer à utiliser le formulaire correctement.
Il associe automatiquement le type de rue au nom de la rue dans la plupart des cas. Un champ de formulaire en moins à remplir, et encore une fois, explique la mémoire potentiellement mauvaise des gens. Si quelqu'un se souvient d'une rue comme Foo St, mais en fait, seule Foo Avenue existe en option .. :)
La manière la plus flexible est utilisée par Google Maps. Essayez d'entrer votre échantillon de test avec 49th et vous verrez que c'est comme votre troisième variante. C'est ce que vous recherchez?
Mais il y a un autre problème - une telle solution conviviale peut devenir difficile pour les développeurs de la mettre en œuvre. De plus, l'utilisation d'un formulaire simple et bien structuré peut être simple dans la programmation et entraîner une livraison rapide de votre produit aux clients. Est-il essentiel que votre candidature reçoive l'adresse exacte? Ou peut-être pouvez-vous obtenir une approximation puis exécuter la procédure principale pour la corriger ou trouver l'adresse la plus similaire dans votre base de données. Je veux seulement dire que parfois, la lutte pour la précision n'en vaut pas la peine. Vous décidez de ce qui est le plus précieux pour vous.