L'adresse de champ unique est-elle acceptable?
Les adresses de livraison doivent comporter plusieurs champs pour la ligne d'adresse 1, la ligne d'adresse 2, la ville, l'état/la province et le code postal. C'est bien sûr assez standard.
Cependant, que se passe-t-il si les informations d'une adresse ne sont pas destinées à l'expédition? Est-il alors acceptable d'avoir un seul champ pour saisir une adresse?
Par exemple, une application comme urbanspoon exigera que chaque restaurant saisisse son adresse. L'adresse sera répertoriée sur leur page et sur la carte. Le fait d'avoir un seul domaine aura-t-il un inconvénient à cela? Cela affectera-t-il le référencement? Backend? Ou y a-t-il une psychologie derrière le fait d'avoir plusieurs domaines (moins encombrants)?
C'est sûr!
Permettez-moi de vous proposer deux exemples concrets tirés des produits Google.
Google Maps
Google Agenda
La question actuelle est un peu large. Les autres réponses apportent des points valables, mais ce sont principalement des défis de mise en œuvre .
Problèmes d'implémentation
La façon dont Google résout tous ces problèmes est de transmettre ce que vous tapez en temps réel à une API qui fournit ensuite des suggestions en fonction de ce que vous avez tapé. Ensuite, l'utilisateur peut choisir parmi une adresse que le service connaît - est déjà validée - ou peut simplement choisir quelle que soit sa saisie de texte sous forme libre.
Si vous vous souciez de l'intégrité des données, je dirais que c'est la seule façon d'y parvenir avec fiabilité.
UX?
Cela fournit également sans doute une expérience utilisateur améliorée sur un formulaire multi-champs car l'utilisateur peut entrer une adresse partielle mais obtenir une adresse complète via le service de validation, via l'auto-complétion. Beaucoup existent.
Des recherches devraient être effectuées pour voir si la mise en œuvre panique comme les lecteurs d'écran. Vous voudrez peut-être envisager de fournir l'alternative multi-ligne que les gens connaissent.
Si vous ne vous souciez pas de l'intégrité des données - par exemple, l'adresse est uniquement à l'usage de l'utilisateur qui l'a saisie, donc ils la reconnaîtront même si elle n'est pas livrable - vous pouvez certainement le faire.
Il y a deux raisons:
- Convivialité. Les gens sont habitués à séparer les champs d'un formulaire d'adresse.
- Données/backend. Si vous autorisez l'utilisateur à utiliser un champ de forme libre pour saisir son adresse complète, vous obtiendrez une tonne de variations différentes. C'est aussi une douleur dans le cul sur le backend. Vous aurez beaucoup de temps à désinfecter, trier et stocker les données.
Exemple:
123 Main st. Some State, Zip
123 Main STREET, Zip CODE, STATE
123 main street state Zip
Les trois exemples sont la même adresse, mais ils sont tous différents.
Il est possible que ce soit plus utilisable, mais cela demanderait énormément de travail. Je pense que ce serait bien de simplement copier et coller votre adresse dans un champ et d'avoir le backend du reste.
Il y a tellement de problèmes d'utilisation et de difficultés techniques qui devraient être recherchés, testés et résolus avant d'avoir une seule adresse de terrain aurait du sens. Même alors, après avoir fait des tests utilisateur, il pourrait être plus utile de s'en tenir au statu quo.
Questions possibles qui nécessitent des réponses
- Comment le backend stockera-t-il les données?
- Comment le backend analysera-t-il les données?
- Comment le backend permettra-t-il de modifier les données?
- Comment l'utilisateur recevra-t-il les messages d'erreur?
- Comment allez-vous valider l'adresse?
- Le pavé numérique n'apparaîtra-t-il pas sur le mobile pour que le code postal affecte la convivialité?
- L'utilisateur s'adaptera-t-il facilement à la nouvelle façon de saisir son adresse?
- Sera-t-il plus utilisable que les formulaires standard?
Un seul champ avec un exemple de référence à côté suffira si vous ne prévoyez pas d'automatiser le travail avec ces données.
Voir Luke Wroblewski fournissant des arguments en faveur d'une entrée de numéro de téléphone à une entrée.