Ai-je vraiment besoin d'un bouton de connexion?
Nous avons eu une discussion au bureau autour d'une page de connexion que nous développons pour une nouvelle application Web. L'application Web est basée sur une application intranet et est principalement utilisée par les utilisateurs qui doivent utiliser des applications Telnet dans 80% des tâches quotidiennes.
J'ai créé la conception de la page initiale dans Photoshop, que nous avons discutée et approuvée. Cependant, maintenant que je l'ai donné à l'un des autres développeurs pour commencer à construire, il a remarqué qu'il n'y avait pas de bouton de connexion (ou autre) sur la page - il y a simplement deux champs; un pour le nom d'utilisateur et l'autre pour le mot de passe. Après l'avoir interrogé avec moi, j'ai déclaré que c'était intentionnel, car je ne voyais pas le besoin - la plupart des gens appuieraient simplement sur entrée de toute façon, car c'est ce qu'ils doivent faire dans leur application telnet. Puis la discussion a commencé ...
Il y a eu plusieurs remarques dans la mesure où "s'il n'y a pas de bouton, ils ne sauront pas quoi faire" et "ils attendront le bouton et lèveront des appels d'assistance sur la page qui ne fonctionne pas". Il a même été suggéré que les utilisateurs "restent là" sans savoir quoi faire.
Maintenant .. ma question est: Les utilisateurs ont-ils vraiment besoin d'un bouton de connexion?
Je suis vraiment intéressé à savoir quel type de pourcentage d'utilisateurs finaux serait capable de gérer une simple page de connexion qui les obligerait à appuyer sur Entrée après avoir entré leurs coordonnées pour continuer. Il est important de noter qu'il n'y aurait pas d'invite à l'écran pour appuyer sur Entrée - ils verraient une info-bulle sur le mot de passe indiquant quoi faire, mais c'est tout!
(Exclure les utilisateurs mobiles de la mêlée - en ciblant simplement les ordinateurs de bureau et les ordinateurs portables ordinaires :))
Un exemple de la boîte de connexion:
En fin de compte, ce n'est probablement pas une bonne idée de s'engager dans cette voie sans tests sérieux en raison des attentes des utilisateurs basées sur les conventions existantes.
C'est un point important, car ce que je retiens de votre description, c'est que cela n'est actuellement pas testé et que vous avez conçu cette interface utilisateur en supposant que vos utilisateurs comprendraient. C'est généralement une mauvaise idée: obtenez toujours les commentaires de votre public, surtout lorsque vous essayez quelque chose de nouveau, et surtout dans un domaine clé comme la connexion.
Votre argument telnet est quelque chose à prendre en considération, mais comprenez également que vous construisez une application Web ici et que vous allez probablement être confronté aux attentes des utilisateurs des applications Web, pas à Telnet. Votre cerveau change de contexte: lorsque vous utilisez une application Web, vous vous attendez à un simple clic sur les éléments pour les suivre, tandis que dans les applications de bureau, vous pouvez vous attendre à double-cliquer. Reconnaître le modèle mental des utilisateurs lorsqu'ils utilisent votre application Web par opposition à un espace différent comme telnet est un aspect important de la conception d'une interface utilisateur.
Cependant, certains modèles émergent qui commencent à diverger un peu de la convention standard "se connecter ou s'inscrire". Chacun de ces défis est confronté aux mêmes défis: qu'attendent les utilisateurs et comment établir la confiance, l'attente et la découvrabilité autour de certaines de ces nouvelles idées? Par exemple, StackExchange utilise l'authentification unique, ce qui peut être déroutant pour les utilisateurs qui ne connaissent pas ce modèle. Amazon (avec succès) intègre l'enregistrement et la connexion dans un seul formulaire, bien qu'il reste à voir dans quelle mesure ce modèle serait efficace sur d'autres sites.
Le point est, lorsque vous brisez la convention, vous vous dirigez vers un territoire inconn et vous devez réaliser l'effet que cela peut avoir sur les gens. Si vous songez à le faire, je vous recommande de récupérer des utilisateurs de bureau et d'ordinateurs portables de votre environnement immédiat (par exemple, le chef de bureau et quelqu'un du bureau d'en face) et de leur demander de se connecter. Vous apprendrez beaucoup. Vous pourriez apprendre que votre hypothèse initiale était correcte. Mais au moins, vous aurez les données pour le prouver, au lieu de simplement l'hypothèse. :-)
Edit: Comme vous l'avez mentionné dans un commentaire dans une réponse à votre question sur les programmeurs, "remettre en question la validité de la convention" est un bon point de départ, mais vous devez vous assurer que votre réponse à cette question est fondée sur des données. Tout le monde peut remettre en question les conventions, mais les conventions sont devenues des conventions pour une raison: ce sont des solutions efficaces au problème. S'éloigner de ceux sans bonne raison (et une bonne raison dans le monde de l'interface utilisateur signifie avoir des données ou une certaine forme de métriques) fera généralement plus de mal que de bien.
Au travail, nous avons un système de développement du personnel qui n'affiche le bouton de connexion que si vous naviguez dans Firefox. Chaque fois qu'un cours est organisé, notre service d'assistance reçoit des appels de personnes qui ne peuvent pas se connecter. Chaque appel est lié au fait qu'ils ne voient pas de bouton de connexion. Nous devons maintenant faire tout notre possible pour dire aux utilisateurs qu'ils doivent appuyer sur Entrée pour se connecter.
Vos utilisateurs peuvent être un peu plus avertis en informatique, mais je suppose que vous aurez beaucoup d'appels d'assistance à ce sujet si vous laissez le bouton éteint.
J'aime vraiment la réponse de Rahul, mais j'ajouterai mes propres 2 cents. Je suis devenu extrêmement hésitant à utiliser la touche Entrée sur n'importe quel formulaire Web en raison de l'incertitude quant à sa fonction par défaut. Je ne sais juste pas ce que ça va faire! Certaines personnes ne sont pas aussi prudentes dans leurs efforts de développement et ne parviennent pas à spécifier correctement les boutons par défaut pour un formulaire, ce qui déroute les utilisateurs qui font appuyez sur Entrée pour habitude.
En conséquence, je me suis entraîné à frapper Tab puis barre d'espace, en m'attendant à ce que le prochain contrôle après la zone de mot de passe soit le bouton de connexion (ou éventuellement le mot de passe d'enregistrement) case à cocher), car la barre d'espace équivaut à cliquer sur ma souris sur un bouton sans avoir à prendre le temps de lever les mains du clavier et de placer ma souris sur un élément de l'interface utilisateur.
Le point étant, je suppose, d'inclure un bouton, mais assurez-vous que c'est l'action par défaut du formulaire, et qu'il est correctement configuré pour être le prochain dans l'ordre de tabulation après la zone de mot de passe. De cette façon, vous satisfaites les deux groupes d'utilisateurs.
Si vous avez des utilisateurs aveugles, l'attente sera un bouton quelconque. Sinon, il n'y aura aucune indication sur la façon de se connecter, sauf si vous détectez en quelque sorte un lecteur d'écran et autorisez un bouton dans ce cas spécifique.
Avez-vous envisagé des utilisateurs qui n'ont pas de clavier physique? Les gens qui utilisent un iPad ou un téléphone avec un écran tactile?
Qu'en est-il de l'option permettant aux utilisateurs d'enregistrer leurs informations de connexion? Serait-il toujours raisonnable d'omettre le bouton de connexion? De cette façon, en tant qu'utilisateur, je devrais déplacer ma main de ma souris vers le clavier pour me connecter, puis de nouveau vers la souris pour continuer à interagir avec l'application.
Je dirais donc: oui, vous en avez besoin.
En ce qui concerne les éléments présents dans les autres applications Web, vous pouvez essayer de trouver une ressource de modèle et voir ce qu'ils disent: http://www.welie.com/patterns/showPattern.php?patternID= connexion
"Les utilisateurs peuvent utiliser la touche TAB pour passer du champ nom d'utilisateur au champ mot de passe et appuyer sur ENTRÉE au lieu de sélectionner le bouton" Connexion ".
Habituellement, les actions sont représentées à travers les boutons/liens et l'interaction supplémentaire avec le clavier est secondaire et considérée comme pour les utilisateurs "avancés".
Si vous êtes préoccupé par des raisons d'utilisabilité/d'accessibilité, vous devriez également avoir un bouton: de cette façon, les utilisateurs pourraient interagir avec le formulaire uniquement avec la souris/les périphériques de pointage (copier/coller les entrées | appuyer sur le bouton) ou uniquement avec le clavier.
Lorsque j'ai lu votre question pour la première fois, j'ai pensé au cas du "champ de recherche". http://www.welie.com/patterns/showPattern.php?patternID=search Le motif dit qu'il devrait avoir un bouton, mais avec le temps (utilisation en production), ce bouton est devenu une icône de loupe/dans le coin droit de l'entrée, puis il est devenu une icône d'identification alignée à gauche. Avec l'avancement des tendances (Google Instant) le bouton de recherche devient de moins en moins utilisé (mais toujours présent).
Il y a une différence entre la recherche et la connexion, tout d'abord parce que la connexion nécessite 2 entrées, donc si vous essayez d'ajouter par exemple une icône de connexion, au lieu du bouton (tout comme le cas de recherche), où le mettriez-vous, dans le première entrée, dans la dernière, ou dans les deux?
En tant que développeur, la réponse évidente est la dernière, car chaque utilisateur devrait avoir entré le nom d'utilisateur, puis le mot de passe, puis appuyez sur Entrée. Donc, dans votre cas, vous écoutez Entrée pour la dernière entrée, mais que se passe-t-il si l'utilisateur appuie sur Entrée dans la première entrée (nom d'utilisateur un)? Pour des raisons de cohérence, vous devez écouter les deux entrées, également parce qu'il y a des cas où l'utilisateur voit qu'il a fait une erreur et revient à la saisie du nom d'utilisateur.
Je pense que votre type d'utilisateurs réussira les tests et se connectera avec succès, mais ce type de formulaire n'est pas idéal pour tout le monde (vous avez également mentionné les utilisateurs de mobiles).
Exemples de formulaires de connexion: http://www.smileycat.com/design_elements/login_forms/
Tout d'abord, je suis arrivé à cela via Twitter et je ne suis pas programmeur, mais j'ai une culture informatique raisonnable.
Proposition intéressante car j'ai depuis longtemps abandonné le bouton de connexion lors de l'utilisation de sites Web - la plupart que j'utilise me semblent heureux d'appuyer sur Entrée.
Quelques points: le test des écoliers était intéressant, bien que je soupçonne qu'ils trouveraient les formulaires Web beaucoup plus intuitifs que les utilisateurs adultes, en particulier ceux qui n'utilisaient pas d'ordinateurs (ZX/C64/BBC) en grandissant. Je connais quelques-uns de mes amis qui auraient passé quelques instants (au moins) à réfléchir au bouton manquant - et ce sont des gens qui utilisent des ordinateurs tous les jours pour le travail, mais savent juste comment travailler les applications qu'ils utilisent.
Étant donné que le bouton n'est pas là, quelle est l'action du formulaire lorsque vous appuyez sur Entrée dans le champ du nom d'utilisateur? Ou moins probablement, que se passe-t-il s'ils ont d'abord saisi le mot de passe et appuyé sur Entrée? Vous devrez peut-être quelque chose qui a une action Tab jusqu'à ce que les deux champs soient remplis.
Je viens de verrouiller mon PC Windows (machine de travail, je n'ai pas le choix), de me reconnecter, le bouton "login" du champ de mot de passe est moins évident et n'est pas étiqueté. Encore une fois, j'utilise simplement enter.
Voilà, la perspective d'un vide;)
Si je tombe sur une telle page, je pourrais penser que le site Web n'est pas complètement chargé, ou qu'il y a un bug sur le script côté serveur. Pourquoi risquer la possibilité pour un utilisateur de s'éloigner du site?
De plus, lors de vos tests, avez-vous considéré que vous pourriez obtenir des taux de réussite supérieurs à ce que vous pourriez réellement obtenir lorsque le site sera mis en ligne? Lorsque les gens sentent qu'ils sont testés, ils peuvent s'attendre à surmonter une sorte de défi (par exemple, un bouton de connexion manquant) comme s'il s'agissait d'une sorte de test de QI. Cependant, s'ils sont à la maison sur leur propre navigateur Web, ils auraient probablement un état d'esprit complètement différent et agiraient différemment (par exemple, ils ne s'attendraient pas à surmonter des défis et pourraient en fait s'attendre à l'exact opposé. Ils peuvent attendez-vous à ce que le site Web fasse tout son possible pour accueillir tous les utilisateurs et facilite la connexion, car le site Web souhaite évidemment que beaucoup d'utilisateurs soient satisfaits).
Fondamentalement, votre scénario de test n'est pas 100% similaire à ce que les utilisateurs réels vivront (c'est-à-dire que vos sujets savent qu'ils sont testés et/ou testent quelque chose), sauf si vous pouvez reproduire les mêmes conditions exactes (c'est-à-dire ne pas faire savoir aux sujets que c'est un test), vous pouvez tirer des conclusions inexactes sur la base de tests inexacts.
Je ne sais pas exactement comment vous effectuez vos tests, mais une autre chose qui pourrait affecter la qualité de vos tests est que les autres étudiants voient que personne d'autre n'a de problèmes/questions et qu'ils peuvent se connecter très bien. Cela pourrait les amener à essayer différentes choses (par exemple, appuyez sur le bouton `` retour '') jusqu'à ce qu'ils obtiennent les mêmes résultats que leurs pairs. Ainsi, vous voudrez peut-être également isoler les sujets.
Des tests précis peuvent être une tâche très difficile car vous devez vous assurer que toutes les variables sont exactement les mêmes, à l'exception de la variable que vous testez. D'après le peu de temps que j'ai passé à réfléchir à ce problème, j'ai déjà identifié deux autres variables qui peuvent affecter la précision de votre test. Il y en a peut-être d'autres auxquels je n'ai pas pensé.
Faites des tests d'utilisabilité et découvrez ce que font les utilisateurs. Je comprends que c'est un projet, mais si cela compte, il est suffisamment important pour être testé.
Faites les deux
Demandez au formulaire de se soumettre dès que quelqu'un appuie sur Entrée (et les deux champs ont été remplis), et également ont un bouton à appuyer pour les personnes qui aiment en utilisant la souris.
Quoi qu'il en soit, votre utilisateur est heureux de faire ce à quoi il est habitué.
Je dirais que la meilleure chose à faire serait quelque chose comme ceci:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Vous pouvez également faire une petite flèche en dehors du champ de texte, comme c'est fait dans l'écran de connexion de Windows 7 .
Vous voudrez probablement remodeler le bouton ... en le faisant peut-être se fondre dans la zone de texte jusqu'à ce que vous le survoliez.
Le seul inconvénient étant à l'intérieur le champ du mot de passe est difficile à modifier si vous avez un mot de passe long. Assurez-vous simplement de ne pas l'oublier!
En fin de compte, comme d'autres réponses suggèrent, vous devez vous demander qui est votre public. Votre test sur les écoliers, bien qu'intéressant, ne vous fournit pas suffisamment de valeur pour dire "Mon test a prouvé qu'il n'était pas nécessaire".
Si vous supprimiez le bouton de connexion, voici certaines des choses que vous auriez à combattre:
- Problèmes d'accessibilité
- Ce que l'utilisateur attend
- Futurs appareils tactiles (Windows 7 et tablettes)
Je travaille personnellement avec des applications Web dans Flash Builder et dans le cadre de la validation de principe, nous effectuons des tests d'utilisabilité. En tant que concepteurs/développeurs, vous ne pouvez pas sous-estimer le niveau d'intelligence de certains de vos utilisateurs. En règle générale, je dirais toujours de fournir à vos utilisateurs ce qu'ils attendent. Ce n'est que dans des circonstances exceptionnelles que vous devez vous éloigner d'une convention qui est devenue si largement utilisée.
Si cela prend quelques secondes à un utilisateur pour déterminer quoi faire ensuite, vous devez réévaluer la façon dont vous avez présenté l'interface utilisateur.
Avec la technologie de l'écran tactile de plus en plus utilisée, je ne vois pas que ce modèle particulier changera de si tôt. Il peut évoluer mais le noyau restera très probablement le même.
En tant que recommandation, je garderais personnellement le bouton de connexion et autoriserais l'utilisateur à appuyer sur la touche Entrée pour continuer, inclurais un bouton de connexion qui peut être cliqué en utilisant l'onglet de la souris et sélectionner le bouton de connexion en utilisant le clavier uniquement.
Cela couvre ensuite vos utilisateurs avancés, les règles d'accessibilité et vos utilisateurs IT illettrés en conservant la configuration standard pour un écran de connexion.
En note - Excellente réponse de Rahul bravo!
L'une des préoccupations est de s'assurer de ne pas recevoir trop d'appels de support au sujet d'un bouton/d'une modification de conception manquant et de ne pas dérouter les utilisateurs.
Pour résoudre cela, j'ajouterais le message suivant
Press Enter key to login
juste en dessous du champ du mot de passe.
Cela aidera les utilisateurs (qui pourraient s'attendre à ce qu'un bouton de connexion clique pour se connecter) à savoir qu'ils peuvent appuyer sur la touche Entrée pour se connecter après avoir lu le message. Cela peut être gênant pour eux pour la première fois, mais ils ne seront au moins pas confus et n'appelleront pas à l'assistance, et la prochaine fois qu'ils visiteront le site Web, ils sauront quoi faire.
Les yeux des utilisateurs expérimentés ignoreront le message car ils utilisent déjà la touche Entrée pour se connecter.
Une solution sans bouton ne permettrait pas à l'utilisateur d'avoir 5 tentatives de connexion avant de verrouiller son mot de passe.
Par conséquent, votre système est ouvert à une attaque par force brute, car un pirate pourrait avoir un nombre illimité de tentatives pour deviner le mot de passe?
Vous pouvez ajouter de la logique à la connexion pour éviter un tel piratage, mais c'est quelque chose que vous devez considérer.
Je ne sais pas à quel point c'est pertinent, mais j'ai été assez intrigué par cela et j'ai créé une page un peu comme votre capture d'écran, puis j'ai demandé à ma femme de l'essayer.
elle a réussi à se connecter ok sans avoir à demander de l'aide, mais j'ai remarqué qu'après avoir tapé son mot de passe, elle a choisi d'utiliser la souris et a commencé à chercher un bouton. Seulement quand elle ne l'a pas trouvé, elle a fait une pause pendant quelques instants puis a essayé d'appuyer sur Retour, la laissant entrer.
Lui demandant ce qu'elle en pensait, elle a d'abord dit que c'était ok et juste normal, mais après lui avoir demandé ce qu'elle pensait du bouton manquant, elle a dit qu'elle était un peu confuse, mais a pensé que si elle appuyait sur le bouton de retour, cela pourrait passer à l'écran suivant comme si vous vouliez une nouvelle page dans Word.
Je ne sais pas exactement ce qu'elle veut dire, mais le résultat a été qu'elle a réussi à entrer sans aide, même si elle a passé un moment à chercher un bouton.
J'ai vu un type d'approche similaire dans les logiciels où ils ne nécessitent pas d'entrée pour vérifier les informations d'identification. Une fois vos informations d'identification saisies et que vous cessez de taper, elles vérifient instantanément la validité desdites informations d'identification.
Si vos informations d'identification sont erronées, un message d'erreur très visible s'affiche automatiquement pour vous informer de ce qui s'est mal passé et vous devez simplement ressaisir ou essayer de nouvelles informations d'identification et le processus se répète jusqu'à ce que vous vous soyez connecté avec succès.
Je dirais que vous avez besoin d'un bouton de connexion, pour plusieurs raisons:
La plupart des applications que j'ai utilisées ramènent le focus au premier champ lorsque vous avez terminé de saisir des données dans le dernier champ. Maintenant, cela pourrait bien être une vieille pratique qui a été remplacée par de nouvelles préférences, mais c'est certainement la façon dont je m'attends à ce qu'un formulaire se comporte.
En supposant que votre application aura d'autres formulaires, ils seront probablement plus compliqués que le formulaire de connexion et nécessiteront la présence d'un bouton SOUMETTRE, qui est vraiment tout votre bouton de connexion. Étant donné que ces formulaires auront besoin du bouton, il est logique d'avoir le bouton sur tous les formulaires, pour éviter toute confusion.
Tous les navigateurs ne traitent pas la touche ENTER de la même manière. Encore une fois, cela peut bien être un problème à l'ancienne, mais je me souviens avoir eu des problèmes avec le comportement de la touche ENTRÉE alors qu'il n'y avait qu'un seul champ. Sur certains navigateurs, c'était la même chose que SUBMIT, sur d'autres navigateurs, le bouton SUBMIT devait encore être cliqué. Leur point clé était, il n'était pas contrôlé par votre application, il était contrôlé par le navigateur. J'ai donc appris il y a longtemps à ne jamais rien supposer de la touche ENTER et à toujours compter sur SUBMIT. Encore une fois, cela peut ne plus être un problème, mais je n'ai jamais eu de problème en respectant ce principe, donc je ne vois aucune raison de changer.
Pour nos applications Web utilisées en interne, nous avons utilisé une fonction de connexion automatique.
L'utilisateur tape simplement l'adresse ou clique sur le favori/signet brwoser et ils sont automatiquement reconnus et autorisés. Comment nous avons procédé, je ne suis pas sûr car je suis le graphiste résident.
Cela aurait pu être fait dans le cadre de la création par l'administrateur de profils, de sécurité et d'autorisations pour les employés connus? Peut-être à partir de leur IP?
En tant que personne entrant régulièrement dans l'application pour vérifier la conception, c'était bien de ne pas avoir à se connecter à chaque fois.
Encore une fois, je suis designer, donc il y a peut-être plusieurs choses que je ne prends pas en considération, mais pour les employés connus travaillant dans des applications internes, c'était plutôt sympa.
Je pense que la réponse ici est des scripts. Si un utilisateur n'appuie pas sur Entrée dans un délai prédéterminé, informez-le qu'il doit appuyer sur Entrée pour se connecter, car il est probable qu'il ne l'a pas compris. Pour les quelques personnes dont les scripts sont désactivés, vous pouvez le détecter de plusieurs façons et leur donner un bouton.