Pourquoi utiliser "saisir le nom du projet pour confirmer"?
Si vous êtes un utilisateur de longue date de GitHub, vous avez probablement vu quelque chose comme ceci:
Cela se produit chaque fois que vous effectuez une action potentiellement destructrice sur un référentiel, comme changer son statut public/privé ou l'archiver/supprimer.
L'invite apparaît dans un modal après avoir cliqué sur le bouton d'action, c'est donc une mesure supplémentaire pour éviter les actions accidentelles.
Mais en ce qui me concerne, cela est soit inefficace pour "établir une autre barrière", soit trop lourd comme "une confirmation supplémentaire". On peut simplement copier le nom du référentiel depuis l'URL ou juste au-dessus de la zone de saisie (le texte en gras ci-dessus), mais c'est encore plus complexe que de simplement cliquer sur un bouton supplémentaire.
À mon avis, un modal supplémentaire avec un rouge vif button qui ne répond pas aux actions du clavier (comme la touche Entrée) suffirait. Il faudrait déplacer sa souris sur le bouton rouge vif pour le cliquer pour une couche supplémentaire de prudence. C'est moins lourd et l'incapacité à simplement appuyer sur la touche Entrée est à la fois simple et efficace.
Quelqu'un peut-il expliquer en quoi ce "saisir le nom du projet" est une bonne conception d'interface utilisateur?
Il ne s'agit pas nécessairement d'une "bonne conception de l'interface utilisateur", mais bien plus de prendre toutes les mesures pour empêcher la suppression accidentelle et s'assurer que l'utilisateur est pleinement conscient de ce qu'il supprime .
Cette entrée de blog le capture très bien:
Au lieu de donner aux utilisateurs un bouton de confirmation sur lequel ils pourraient appuyer par erreur, donnez-leur un champ de texte et demandez-leur de taper le mot "supprimer" pour confirmer. Lorsque l'utilisateur tape "supprimer" dans le champ de texte, il ne fait aucun doute qu'il souhaite supprimer. Il n'y a pas de pression accidentelle sur le bouton Supprimer. Il n'y a aucun regret lorsque l'utilisateur supprime, car le champ de texte de confirmation lui permet de savoir ce qu'il va faire avant de le faire.
Comment s'assurer que les utilisateurs ne suppriment pas accidentellement - Mouvement UX
Bien sûr, appuyer sur un bouton est plus facile, mais cela laisse toujours la possibilité que vous lisiez mal le nom et supprimiez le mauvais élément.
Lorsque vous devez taper le nom (ou même le copier-coller), vous pouvez être sûr à 99% qu'un utilisateur ne le fera pas par erreur. Ils le réaliseraient au plus tard lorsqu'ils mettraient en évidence le nom du copier-coller.
En outre, cela n'est généralement utilisé que pour les opérations de suppression très critiques. Ceux-ci se produisent très rarement, donc l'argument selon lequel il est plus facile ou moins ennuyeux ne tient pas vraiment.
Voici quelques questions connexes:
Juste pour être clair, une "bonne" conception d'interface utilisateur ne signifie pas donner à l'utilisateur ce qu'il veut. Cela signifie souvent aider l'utilisateur à être une meilleure version d'eux-mêmes.
En plus de ce qui a déjà été mentionné, ce modèle (et plusieurs similaires) permet à l'interface utilisateur de réduire la vitesse. En général muscle memory -> speed -> mistakes -> sad path.
Imaginez que vous travaillez dans les soins de santé. Si les utilisateurs créent trop de "flux" dans les tâches courantes, ils pourraient potentiellement commettre une simple erreur qui tue quelqu'un. Bien que contre-intuitif, il est souvent bon de retirer l'utilisateur de son flux en exigeant une interaction (plus qu'une simple boîte de dialogue de confirmation qui apparaît toujours au même endroit et peut être ajoutée à la mémoire musculaire).
La saisie de texte n'en est qu'un exemple. J'ai aussi vu:
- ajouter un délai d'attente aux boutons avant qu'ils ne deviennent disponibles.
- Placement aléatoire des boutons de continuation du processus.
- Ajout d'un verrou (par exemple, exécuter le processus en tant qu'administrateur avec mot de passe)
Tous ces modèles sont destinés à ennuyer suffisamment l'utilisateur pour qu'ils arrêtent d'évaluer mentalement le processus avant d'aller de l'avant.
Il s'agit de s'assurer que:
- Vous comprenez le danger de ce que vous faites.
- Plus important encore, que vous supprimiez réellement le bon dépôt.
Si un utilisateur a beaucoup de dépôts avec des noms longs, il peut être facile de les mélanger. Taper le nom est un bon moyen de s'assurer que vous ne nukez pas au mauvais, ce qui serait vraiment très mauvais.
Je remappe une touche de clavier inutilisée (via AutoHotKey) pour une utilisation intermittente comme un clic gauche de la souris pour réduire la tension due à la surutilisation de mon poignet de souris, et parfois (rarement) frappe cette touche au mauvais endroit lors du multitâche. J'ai également occasionnellement heurté la souris elle-même et cliqué involontairement sur un bouton d'une boîte de dialogue.
Bien que "ne me faites pas penser" est une très bonne règle, il est logique d'aider l'utilisateur à se concentrer exactement sur ce que l'exécution d'une commande destructrice peu fréquente fera réellement. J'envisagerais même de demander à l'utilisateur de taper une phrase complète du formulaire, "Veuillez supprimer le référentiel iBug/example-repository, y compris son wiki, ses problèmes et ses commentaires" textuellement pour clarifier l'intention de l'utilisateur de lui-même = dans cette situation, car l'utilisateur ne le fera qu'une seule fois sur ce référentiel.
Toute personne qui écrit du code doit taper très fréquemment des lignes de texte complètes, claires et correctement orthographiées, donc une ligne de plus pour confirmer l'action la plus destructrice que vous pouvez effectuer sur un projet n'est pas déraisonnable.
À mon avis, un modal supplémentaire avec un bouton rouge vif qui ne répond pas aux actions du clavier (comme la touche Entrée) suffirait. Il faudrait déplacer leur souris sur le bouton rouge vif pour cliquer dessus pour une couche supplémentaire de prudence. C'est moins lourd et l'incapacité à simplement appuyer sur la touche Entrée est à la fois simple et efficace.
(pas d'italique dans l'original)
Êtes-vous bien sûr qu'ils devraient "bouger leur souris"? À chaque fois? Même s'ils sont sur un appareil avec une résolution différente, où peut-être que les choses ne s'alignent pas comme prévu? Ou s'ils sont zoomés? Qu'en est-il de la saisie tactile? Qu'en est-il des personnes qui n'utilisent pas de souris (en raison de différences de capacité/etc)? Maintenant, vous devez vous assurer qu'il répond au clavier d'une manière qui ne rompt pas l'accessibilité, mais ne permet pas une suppression accidentelle.
Bien qu'il y ait des arguments contre sans discernement suivant les meilleures pratiques simplement parce que ce sont les meilleures pratiques (par opposition au fait de comprendre pourquoi elles sont en place) ou au moins " ce que tout le monde fait ", en particulier quand ils ne sont pas toujours réellement si bon, je voudrais souligner qu’ils sont généralement devenus une meilleure pratique car il y a des problèmes imprévus qui surgiront , et essayer d'aller contre eux simplement parce que vous ne voyez pas leur intérêt est généralement une mauvaise idée. Lorsque vous examinez quelque chose qui est une bonne pratique répandue/largement adoptée, commencez par supposer qu'elle est significative et significative et qu'elle a probablement de fortes raisons sous-jacentes qui se sont développées au fil du temps (et probablement parmi plus de personnes qu'une seule, et certainement examinés par plus d'une seule personne) que vous seul avez probablement consacré au même ensemble de problèmes (et avec seulement votre propre perspective qui vous guide). Sans parler des problèmes de cohérence globale.
@ la réponse de BigChair aux côtés de @ la réponse de Bryce Howitson les deux Découvrez pourquoi c'est une meilleure pratique pour les actions irrécupérables en général. Dans la conception de l'interface utilisateur, il est important de créer des frictions pour les actions critiques qui ne seront pas récupérables, et ces deux couvrent assez bien le sujet dans ce contexte.
Dans la mesure du possible , cependant, je conseillerais de prendre un chemin différent dans tous les cas où il serait possible de l'implémenter:
Évitez de laisser les actions irrécupérables en premier lieu
Cela dit, la meilleure façon d'aller de l'avant est de ne pas avoir les actions de l'utilisateur entraînent des états logiciels irrécupérables en premier lieu. N'oubliez pas que ce qu'une interface utilisateur expose à la personne utilisant un logiciel n'a pas à faire correspondre ce que le logiciel fait à son état en interne, dans un rapport 1: 1 de sémantique connexe. C'est correct pour la façon dont quelque chose est représenté à la personne qui l'utilise pour ne pas correspondre à l'implémentation technique de ce qui se passe quand ils activent une action connexe.
Ne supprimez pas les éléments de votre représentation logicielle en fonction de la saisie de l'utilisateur uniquement. Mark les supprimer dans votre représentation de stockage d'entre eux et fournir un moyen de les récupérer (une corbeille/etc). Ne permettez pas la création de situations où une personne utilisant votre produit peut se reculer dans un coin dont elle ne peut pas se sortir. Non seulement il vaut mieux UX pour éviter la nécessité de ces types de confirmations partout où cela est possible, mais cela réduit également les exigences de support et les niveaux de friction associés dans les problèmes de support associés (qui sont également des aspects UX). Quand quelqu'un "supprime" quelque chose, expliquez clairement qu'il sera également en mesure de revenir sur l'action qu'il a prise à la fois tout en s'engageant dans l'action et après (de sorte que s'ils ont accidentellement "supprimé" quelque chose sans lire les écrans jusqu'à et y compris l'action, ils peuvent maintenant voir où aller pour l'annuler).
J'ai déjà fait ce que j'appelle des erreurs accidentelles:
- ma main s'est déplacée à la seconde où j'ai appuyé sur le bouton (je voulais "Annuler", j'ai "OK"). Alternativement: une annonce est apparue et a déplacé la page.
- l'instruction était si confuse que j'ai appuyé sur le mauvais bouton (bien sûr pas le moins destructeur)
- J'étais "oh non non non" et paniqué j'ai appuyé sur le mauvais bouton
- Je peux ou ne pas être Juan Pablo Davila
C'est pourquoi je préfère vraiment, vraiment dans de tels cas, un processus qui me fait agir différemment de ce que suggère la mémoire musculaire.
Ce que Github essaie de faire ici, c'est d'éviter les erreurs des utilisateurs, mais spécifiquement les "glissements" comme Don Norman les mentionne dans La conception des choses de tous les jours.
Des glissements se produisent lorsque les utilisateurs ont l'intention d'effectuer une action, mais finissent par effectuer une autre action (souvent similaire). Par exemple, taper un "i" au lieu d'un "o" compte comme un glissement; mettre accidentellement du savon liquide pour les mains sur sa brosse à dents au lieu du dentifrice est aussi un glissement. Les glissements sont généralement effectués lorsque les utilisateurs sont sur le pilote automatique et lorsqu'ils ne consacrent pas pleinement leurs ressources d'attention à la tâche à accomplir.
Je souligne que la dernière partie de la citation est particulièrement pertinente.
L'article suivant de nngroup explique comment éviter les glissements
les erreurs de type glissement sont souvent commises par des utilisateurs experts qui connaissent très bien le processus en cours; contrairement aux nouveaux utilisateurs qui apprennent encore à utiliser le système
https://www.nngroup.com/articles/slips/
Compte tenu des types de personnes qui utiliseraient Github, vous les considéreriez très haut sur quelque chose comme GDS Digital Inclusion Scale ce qui impliquerait qu'ils sont des utilisateurs experts plus susceptibles de faire des glissades.
Ensuite, assemblez les deux et sympathisez avec un utilisateur expert de Github qui a consacré des centaines d'heures à un projet, mais est fatigué, a oublié dans quel projet il se trouvait et glisse pour appuyer sur Supprimer quand il ne le voulait pas. Comment se sentent-ils?
De nombreux utilisateurs de Github ont un grand nombre de référentiels et sur la page de suppression, il n'y a pas grand-chose à leur dire si vous n'y prêtez pas attention, peut-être que vous vouliez supprimer le référentiel "projet en millions de livres - brouillon", mais vous étiez dans "projet de millions de livres".
C'est ce qu'ils font et je considère que c'est une conception d'interface utilisateur efficace pour cela. Mettre des contraintes utiles dans la manière d'opérations irrécupérables est une bonne pratique.