Meilleure interface utilisateur pour permettre aux utilisateurs experts d'entrer une adresse IP? (IPv4)
Je travaille sur une application Web qui oblige les utilisateurs à entrer une adresse IPv4 (en notation décimale à quatre points) pour la plupart des tâches principales dont ils ont besoin pour effectuer. Notre "utilisateur" cible principal est un administrateur informatique de petite entreprise. Ils connaissent très bien les adresses IP.
Je me demande quel style d'acceptation de saisie de formulaire est le meilleur? Nous utilisons actuellement l'option 1 .
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Option 3 sans validation intrusive.
1 suce parce que c'est hors norme. Le copier-coller peut ou non fonctionner. La tabulation vers le champ suivant peut ou peut ne pas fonctionner. Les gens sont bons pour corriger les erreurs et les champs limités gâchent leur mémoire musculaire. Par exemple, je pourrais taper
1912
Quand je voulais dire
192
Mes doigts vont presque instantanément corriger cela, mais le champ qui m'oblige à 3 chiffres signifie que si j'appuie deux fois sur la touche Retour arrière puis en tapant "2" pour le corriger, on obtient "12" ou jusqu'à 191 dans la première case et rien dans le premier seconde. Dans les deux cas, je maudis le concepteur UX qui, en essayant d'être intelligent, a aggravé la situation.
L'option 2 est vraiment la même que l'option 1, juste visuellement différente. Un espace qui se sépare ou une période qui se sépare. Les mêmes problèmes se posent. Peut-être plus que maintenant que je tape des périodes ou non? Si je fais ce qui se passe? Si vous tapez à nouveau la période, puis avec la mémoire musculaire, appuyez sur DEL pour effacer mon erreur uniquement pour qu'il efface un chiffre car il n'a pas inséré la période. Pouah!
L'option 3 est la meilleure, mais la validation doit attendre jusqu'à ce que je clique sur Soumettre ou, au moins, la validation doit être discrète. En d'autres termes, il devrait apparaître ailleurs sur la page, ne pas être une fenêtre contextuelle ou quelque chose qui affecte ma frappe pour les mêmes raisons mentionnées ci-dessus.
Je pourrais taper
19w
Quand je voulais dire
192
Parce que mes doigts ont glissé mais la perception et ma mémoire musculaire sont assez rapides pour que j'essaye immédiatement de la corriger. Si la validation interrompt ma saisie, je maudirai à nouveau le concepteur UX. Par exemple, j'ai utilisé des formulaires avec validation que lorsque je tape le 'w' une boîte de dialogue d'alerte ou modale apparaît "Numéros seulement!" ce qui finit par me faire trébucher puisque j'étais déjà en train de le réparer.
Pendant que nous y étions, alors que aaa.bbb.ccc.ddd est la norme pour une adresse IP, pourquoi ne pas vous soucier de ce qu'est le séparateur? Si je tape
1-2-3-4
ou
1 2 3 4
Pourquoi ne peuvent-ils pas être tout aussi acceptables? Cela vient parce que c'est tellement ennuyeux lorsqu'on lui demande un numéro de téléphone et qu'on lui dit qu'il doit être XXXYYYZZZZ au lieu d'accepter simplement XXX-YYY-ZZZZ ou (XXX) YYY-ZZZZ, etc. et que l'ordinateur le comprenne. De même pour les numéros CC. Acceptez AAAABBBBCCCCDDDD et AAAA BBBB CCCC DDDD et AAAA-BBBB-CCCC-DDDD; en fait, que diriez-vous d'extraire les chiffres, puis de déterminer si les chiffres constituent des numéros CC valides. De même pour les adresses IP. Peut-être l'analyser en cherchant
- zéro ou plusieurs chiffres non
- un ou plusieurs chiffres
- un ou plusieurs chiffres non
- un ou plusieurs chiffres
- un ou plusieurs chiffres non
- un ou plusieurs chiffres
- un ou plusieurs chiffres non
- un ou plusieurs chiffres
- zéro ou plusieurs chiffres non
De cette façon
[espace] 1.2.3.4 [espace]
fonctionnera également et n'ennuiera pas l'utilisateur avec des messages stupides sur la correction de leur entrée lorsque l'ordinateur est parfaitement capable de les gérer.
Pour faire un petit remue-méninges sur la façon de mieux présenter les adresses IP aux utilisateurs experts, je choisirais un mélange d'options 1 et 3.
La façon dont je l'implémenter serait remarquablement similaire au propre système de marquage de StackExchange, sauf qu'au lieu d'utiliser une clé d'espace comme délimiteur, j'utiliserais un . afin que, lors de la frappe, il puisse regrouper vos entrées dans des cases distinctes:
C'est beaucoup plus facile à expliquer avec un exemple. Pardonnez ma bâtardise du <kbd> élément:
1
19
192
192.
192.1
192.16
192.168
192.168.
192.168.1
192.168.1.
192.168.1.2
192.168.1.20
[le champ perd le focus]
192.168.1.20
Il y a, bien sûr, beaucoup de détails de mise en œuvre qui devraient être élaborés dans cette méthode. Comme pour la plupart des choses, il est plus facile de le faire mal que de le faire correctement.
Pas option 1. 90% du temps je copie et colle des adresses IP d'une autre source et je parie que ces utilisateurs experts le font aussi. Pour cette raison, je dois dire que l'option 3 est le meilleur pari.
L'option 2 ou 3 serait probablement la plus utilisable - personne ne peut être sûr sans le tester. Probablement l'option 3, car les experts sauraient qu'il y a des périodes dans une adresse IP (pas besoin de masque).
L'option 1, souvent vue dans les formulaires de saisie de numéros de téléphone sur le Web, peut devenir délicate en raison du manque de convention dans la conception d'interaction. Parfois, le champ avance automatiquement, parfois non, donc vous vous retrouverez souvent avec des utilisateurs avertis tabulant une fois de plus après que le curseur ait déjà avancé.
Étant donné que tout ce que vous collectez sur le terrain est des nombres et des périodes, la validation devrait être assez simple et, puisque vos utilisateurs sont des experts, ils sauront de toute façon comment formater correctement l'entrée.
J'ai déjà vu l'option 1 en entrant dans les domaines de la sécurité sociale. Il se peut que ce soit juste moi mais je pousse toujours par erreur "tab" pour aller au champ de saisie suivant lors de leur utilisation. Pour une raison quelconque, je suppose toujours que la fonction n'avance pas automatiquement. Cela peut être dû au fait qu'il apparaît visuellement comme deux champs de saisie distincts au lieu d'un.
Pour les utilisateurs expérimentés, seule l'option 3. Pour le profane, l'un des trois, bien que probablement classé dans l'ordre.
Une adresse IPv4 est composée de quatre octets binaires séparés par des points lorsqu'elle est écrite en notation décimale. L'utilisateur expérimenté le sait et est habitué à taper correctement une adresse IP.
Souvent, la meilleure interface utilisateur est celle qui reste à l'écart.
Comme Tim l'a indiqué, l'option 1 sera légèrement frustrante pour l'utilisateur expérimenté car il n'aura pas besoin de la main. L'intuition me dit que l'option 1 sera la plus intuitive pour le profane, car l'ambiguïté entre la tabulation ou la frappe du clavier entre les octets de l'option 2 sera source de confusion.
En passant, l'autre avantage de l'utilisation du champ de boîte unique de l'option 3 est qu'il vous permet également de prendre en charge les adresses IPv6 sans changer l'interface (et il est facile sur le backend de les différencier, car IPv4 est de 32 bits et IPv6 de 128. morceaux).
Option 3! Utilisez une rétroaction instantanée de Nice à droite du champ sur le flou.
Je suis d'accord, vous copiez si souvent ces informations car vous n'avez pas d'IP mémorisée et les gens ne sont pas si stupides. Surtout les administrateurs informatiques des petites entreprises.
Les autres formulaires gênent les utilisateurs (un peu comme le gouvernement fédéral)!
Option 3, plus la possibilité d'utiliser la notation barre oblique si un masque est également requis. De plus, je devrais être capable de taper également une représentation décimale ou hexadécimale, et il devrait la prendre.
Option 3 définitivement.
Vous traitez avec des utilisateurs expérimentés, selon votre propre mémoire, donc l'option 1 est sortie.
L'option 2 n'est pas nécessaire. Les utilisateurs expérimentés savent ce qu'est une adresse IP. Ils veulent juste y entrer le plus rapidement possible. Ils peuvent également taper, vous avez donc simplement besoin de les laisser continuer.
Option # 3 avec un gestionnaire onchange fournissant des commentaires en changeant la couleur de la bordure. Un seul champ est une promesse que l'utilisateur peut saisir les choses comme il le souhaite, corriger les fautes de frappe et ne pas être bogue par un processus de validation trop zélé
Les 3 options peuvent fonctionner correctement en fonction des détails de l'implémentation - par exemple, vous pouvez implémenter un copier-coller complet sur l'option # 1 en divisant la chaîne sur les points et en remplissant automatiquement le reste des cases, permettant à l'utilisateur de taper/supprimer de d'un champ au suivant, passez au champ suivant avec tabulation ou point ... mais comme il y a beaucoup de champs IP mal implémentés, un utilisateur expérimenté ne s'attendra pas à ce que le vôtre soit bien implémenté.
Option 3. S'il s'agissait d'une adresse e-mail, vous n'afficheriez pas un champ de saisie pour la partie locale et un autre pour le domaine, d'autant plus que les utilisateurs savent ce qu'ils font.
Sûrement l'option 3. Mais il serait approprié d'implémenter des commentaires pour ce genre de choses afin que les utilisateurs voient le bon format d'adresse IP en cas de mauvaise entrée.
L'option 3 serait la meilleure. Windows utilise l'option 1 qui est très irritante lorsque vous faites une erreur, comme l'ont souligné d'autres commentaires.
Extension: pourrait utiliser l'option 3 et entrer automatiquement un point (.) Après avoir tapé trois chiffres. Ainsi, l'utilisateur peut simplement taper 1921681001 entraînerait 192.168.100.1. Il suffit d'avoir une note de bas de page en entrée pour suggérer que cette fonction entraînera beaucoup de retour en arrière pour supprimer exstra 192..168 si l'utilisateur tape rapidement.