Quelles erreurs commettent vos utilisateurs et comment pouvez-vous mettre à jour votre application pour les gérer? [fermé]


12

En fait, cette question concerne les précautions à prendre pour améliorer l'expérience utilisateur de qualité et réduire les appels d'assistance évitables.


2
Considérez ce titre: "Quelles erreurs commettent vos utilisateurs et comment pouvez-vous mettre à jour votre application pour les gérer?"
Peter Boughton

Réponses:


25

Un manque de validation d'entrée appropriée est l'une de ces choses qui a tendance à conduire assez rapidement les utilisateurs à faire de "mauvaises" choses avec votre application, alors qu'elle devrait vraiment être gérée par le programmeur.

J'ai vu des applications héritées où les utilisateurs ont été formés pour:

  • ne pas entrer d'apostrophes dans les noms
  • ne pas entrer d'autre symbole que a-z0-9,
  • assurez-vous qu'il n'y a pas d'espace avant ou après le texte qu'ils ont entré
  • vérifiez qu'une adresse e-mail correctement formatée est entrée dans le emailchamp, sinon les envois ultérieurs à cet utilisateur utiliseront tout ce qui est dans le champ et échouera
  • assurez-vous que " http://" est placé avant les adresses Web

etc

Tous les problèmes ci-dessus doivent être traités par un développeur d'applications. Lorsque la validation de votre entrée est essentiellement "assurez-vous que l'utilisateur sait dans quel format ce champ doit être et qu'il a confiance que ce qu'il a entré est correct", alors des choses inattendues trouveront forcément leur chemin dans l'application. Outre les implications évidentes en matière de sécurité, les utilisateurs font des erreurs. En tant que programmeurs, nous produisons souvent nos meilleurs produits en nous penchant en arrière pour nous assurer que l'utilisateur ne peut pas se tromper, peu importe ses efforts!


C'est si souvent négligé ... Je ne peux pas croire que nous rencontrons encore ces problèmes aujourd'hui! @
mpeterson

2
+1 parce que je l'ai vu. MAIS: Une "adresse e-mail correctement formatée" est notoirement difficile à valider Fightforalostcause.net/misc/2006/compare-email-regex.php assurez-vous de savoir ce que vous faites. Si vous traitez simplement le sous-ensemble d'e-mails que votre entreprise utilise en interne, cela devrait être bien, sinon il y a plus de complexité que ce que la plupart attendent. Même histoire pour le http://point de validation. Par exemple, le ASDFfait de manière naïve, et le résultat est que vous ne pouvez pas héberger de packages sur des domaines qui utilisent https://.
Inaimathi

Cela ne fonctionne pas ... il n'accepte pas les e-mails avec des chemins de détonation (oui je sais qui s'en soucie, mais quand même, la validation des e-mails vers le RFC EST difficile.)
Spudd86

7

Une fois, j'ai reçu un appel du service client car mon application a tout simplement disparu. Il s'est avéré qu'ils ont ouvert une autre application par-dessus.

... J'ai décidé de ne pas m'assurer que cela ne se reproduise plus, car c'est l'analphabétisme informatique des utilisateurs qui a causé le problème, pas l'application. Tout ce que j'aurais pu faire pour y remédier aurait conduit à une mauvaise expérience utilisateur pour les autres.


1
Veuillez transmettre ce message à tous les développeurs qui mettent en œuvre une fonctionnalité forcée de "rester au top" dans leur application. Même si c'est le PDG qui le demande, nous devrions avoir le droit de dire «non».

7

Presque tous les programmes que j'écris sont invoqués strictement à partir de la ligne de commande. J'ai également écrit des choses plus sophistiquées qui ont commencé comme des interfaces CLI et sont rapidement devenues quelque chose de plus shell que n'importe quoi.

Donc, je ne peux parler que pour ce que je sais. Voici quelques problèmes courants avec les programmes de ligne de commande:

Beaucoup trop d'options

Sauf si vous écrivez un compilateur ou un éditeur de ligne, essayez de garder les options limitées à un écran plein sur un tampon de trame 80x25 quand --helpou /?est passé. Il est parfaitement bien d'avoir plus d'options que cela, mais les diviser en sous-catégories. Par exemple

foo --help

foo --help option_name

Aucune option longue

Il est beaucoup plus facile de s'en souvenir foo --attach_to [argument] --volatile --verboseque de s'en souvenir foo -a [arg] -v +V. Ce n'est pas toujours possible, mais dans la plupart des cas, ça l'est.

Aucune validation d'entrée

Presque chaque plate-forme possède plusieurs bibliothèques qui sont testées, vérifiées et vraies en ce qui concerne l'analyse et la validation des arguments. Presque chaque plate-forme a un lexer éprouvé, testé et véritable qui valide les entrées d'une CLI. Utilisez l'un, l'autre ou les deux. Si votre programme se sépare ou se divise par zéro en raison de quelque chose qu'un utilisateur a fourni, c'est juste embarrassant.

Vous pourriez ne pas avoir besoin de quelque chose d'aussi complexe qu'un lexer, peut-être pouvez-vous simplement symboliser la chaîne si vous vous attendez à des choses dans un certain ordre avec certaines choses à certains endroits.

J'ai en fait reçu un rapport de bogue une fois où un entier était attendu et quelqu'un a tapé des f*** my lifeguillemets. Je n'ai pas écrit ce programme, j'ai eu le malheur d'en hériter.

Pas de bouton 'verbocity'

Permettez aux utilisateurs expérimentés de découvrir facilement comment éliminer beaucoup plus de bruit de votre programme que la plupart des gens ne le toléreraient, mais par défaut, n'imprimez que les choses sérieuses et critiques. Je ne peux pas vous dire combien de fois j'ai dû déclencher stracejuste pour me rendre compte que quelque chose s'est défectueux parce qu'il fonctionnait sur un flux de fichiers NULL.

Vous pouvez également encapsuler des assertions de sorte que leur désactivation via NDEBUG ou d'autres moyens entraîne toujours quelque chose imprimé ou enregistré pour que l'utilisateur le trouve.

En parlant de fichiers journaux, essayez de vous assurer que tout ce que vous y placez a du sens (au moins un peu) pour quelqu'un d'autre que vous. Si le début de chaque entrée est une date d'époque UNIX, vous allez aggraver la frustration de quelqu'un qui veut vraiment vous aider à reproduire le bogue.

Pas de «bug buddy» en mode débogage

De nombreux programmes proposent une sorte de commutateur de «débogage» qui offre un bavardage supplémentaire concernant ce qui se passe avec le programme, mais très peu proposent les options suivantes:

  • Un moyen d'envoyer automatiquement un rapport via HTTP / HTTPS et d'obtenir une sorte de numéro de référence de service
  • Un moyen de vider des informations utiles dans un fichier qui pourrait être envoyé en tant que pièce jointe à une demande de support

Ou, peut-être que vous aimez entendre les gens lire ce qui suit au téléphone:

Il indique une condition inattendue à zéro eff oh quatre zéro oh .... OK lemme vous a lu ça ...

Fichiers de configuration trop complexes

Ne justifiez pas la nécessité d'analyser une config comme excuse pour obtenir un buzz sur beaucoup de sucre syntaxique. Essayez d'utiliser un format que les gens connaissent réellement, même si cela signifie un travail supplémentaire lors de l'analyse. J'essaie d'utiliser le format de style INI autant que possible. Vous seriez étonné de ce que vous pouvez retirer avec un simple dictionnaire clé-valeur.

Aucun fichier de configuration

Ne forcez pas les gens à écrire des scripts shell ou des fichiers batch uniquement pour utiliser votre programme, sauf s'il était destiné à être un outil pour l'une ou l'autre tâche. Donnez-moi un moyen de pointer un fichier contenant mes options habituelles et de ne fournir que quelques arguments supplémentaires.

Pas de panneaux «sol mouillé»

Si une fonctionnalité peut causer des problèmes à l'utilisateur (peut-être qu'elle est là pour les utilisateurs avancés), marquez-la clairement comme telle. De plus, si quelqu'un entre de gros doigts ou oublie quelque chose, demandez à votre programme d'imprimer un lien très convivial vers la documentation en ligne. Vous avez peut-être affaire à quelqu'un qui utilise votre programme via KVM et ne peut pas copier-coller.

Dans la mesure du possible (cela coïncide avec la validation des entrées), utilisez l'appli Google:

Voulez-vous dire foo --bar FILENME, vous avez tapé uniquement foo --bar

Offrir un moyen de sortir des instructions destructrices

Le but est de dire à l'utilisateur pourquoi cela n'a pas fonctionné et de le faire essayer plusieurs fois, tout en s'assurant que vous ne faites rien de potentiellement destructeur à moins qu'il ne semble que l'utilisateur veuille vraiment que vous le fassiez. Autorisez un interrupteur qui désactive le «harcelant», par exemple -You /Ysinon autorisez une sortie pour quelqu'un qui a simplement des «gros doigts».

J'oublie probablement quelques conseils. Je traite cela fréquemment car il est très, très difficile de créer une interface «bas niveau» pour quelque chose d'assez intuitif pour que la plupart des gens évitent de faire des erreurs.


3

"Êtes-vous sûr de vouloir supprimer ce fichier / enregistrement? Oui / Non". J'ai cliqué sur Oui, puis j'ai reçu un appel m'informant qu'il "cliquait par erreur" sur le bouton rouge de suppression et qu'il avait besoin de ces données en retour :)


7
Pourquoi les "citations". Suggérez-vous qu'ils ont délibérément cliqué sur Oui, juste pour qu'ils puissent vous téléphoner?
Peter Boughton

1
Résolu facilement en utilisant des "suppressions progressives" qui peuvent être annulées.
Robert Harvey

1
oui, ils peuvent être annulés, mais pourquoi les supprimer en premier lieu? C'est pourquoi j'ai mis cet avertissement là-bas, en leur demandant de confirmer deux fois qu'ils veulent le supprimer :)
Quamis

2
@Quamis: Les boîtes de dialogue sont devenues tellement ennuyeuses pour de nombreux utilisateurs qu'ils cliquent simplement sur OK, oui, peu importe, juste pour passer à travers la boîte de dialogue. C'est pourquoi de nombreux nouveaux systèmes utilisent une suppression logicielle sans confirmation et donnent à l'utilisateur un moyen d'annuler. La plupart des systèmes de messagerie fonctionnent désormais de cette façon, par exemple.
Robert Harvey

1
@Robert Harvey - Je comprends, et oui, c'est la raison spécifique pour laquelle une suppression matérielle a dû être implémentée. Cet exemple spécifique pourrait être résolu en suivant les politiques de rétention, mais il y a probablement des cas où les gens appuient sur «Supprimer» s'attendant à juste titre à ce que la conséquence de cette opération soit une véritable suppression. Je suis moi-même favorable à la suppression progressive, mais mon point de vue était que ce n'est parfois pas une option.
Inaimathi

3

Je n'ai pas l'impression que l'obtention d'exemples de rupture / correction spécifiques est aussi important que de réaliser ceci:

  • Les utilisateurs ne lisent pas votre manuel ni ne regardent vos didacticiels. Ils apprennent votre logiciel par l'exploration.

Si, à travers cette exploration, ils cassent quelque chose, en tant que programmeur, c'est votre travail de les avertir du danger ou de l'empêcher de se produire en premier lieu. Je ne me souviens plus où je l'ai vu maintenant, mais dans le fond de mon esprit, j'essaie toujours de " faire en sorte que la bonne chose soit facile " pour l'utilisateur de mon logiciel.

Si vous insistez sur des exemples:

  • L'utilisateur a pu entrer un nom en minuscule qui a brisé le code d'intégration / corrigé en effectuant une validation d'entrée
  • L'utilisateur a pu cliquer sur le mauvais bouton après avoir effectué une action / corrigé en affichant uniquement les bons boutons.
  • L'utilisateur a pu faire X accidentellement / corrigé en l'avertissant qu'il était sur le point de faire X.

Vous voyez où cela va? :)


2
Les avertissements ne devraient être réservés qu'aux opérations les plus destructrices, et vous devriez éviter d'en avoir, annuler est BEAUCOUP BEAUCOUP mieux, les gens ont maintenant été formés pour cliquer sur 'OK' sans même lire la boîte, c'est la mémoire musculaire maintenant, évitez les pour toute opération que l'utilisateur pourrait éventuellement faire sur toute sorte de base régulière pour éviter cet effet.
Spudd86

3

En voici un que j'ai entendu cette semaine. Un utilisateur demande une fonctionnalité "envoyez-moi une notification lorsqu'un événement se produit". Assez simple et le développeur va de l'avant et le met en œuvre. Bien sûr, la première question aurait dû être "à quoi tentent de répondre par cette notification?". Je n'entrerai pas là-dedans. Quelques jours plus tard, l'utilisateur s'arrête auprès du développeur et demande "J'ai reçu cette notification. Que dois-je en faire?".

Je me suis souvenu de cette bande dessinée Dilbert et ai suggéré au développeur "d'écrire une application pour comprendre ce que l'utilisateur devrait faire avec cette notification".

Comme l'a dit mpeterson, l'utilisateur est très compétitif dans son domaine d'expertise. Ils ne pensent tout simplement pas comme un développeur ou un concepteur de logiciels.


2

Je ne pense pas que les utilisateurs soient stupides. Ils ne veulent pas du tout utiliser votre programme. Tout ce qu'ils veulent, c'est faire avancer les choses. Aidez-les et évitez que des blessures ne leur arrivent en cours de route.


1
Vous ne comprenez pas la question. Vous répétez ce que j'ai écrit en d'autres mots. Ce n'est pas une réponse à la question. Quelles pratiques pouvons-nous faire pour prévenir les dommages?
Maniero

1
Je comprends bien la question, merci. La question comprend quelque chose qui n'est pas vrai: "l'utilisateur est stupide".
LennyProgrammers

1
Non, ce n'est pas le cas. C'est votre incompris. Votre devis n'existe pas!
Maniero

1
Ok, les gens ne font pas de bêtises, le monde est parfait :-) C'est mon inférence à propos de ces opinions.
Maniero

1
Pas de rancune, d'accord? ;)
LennyProgrammers

1

Une bonne interface utilisateur et une expérience d'apprentissage adéquate contribuent grandement à empêcher les utilisateurs de faire de mauvaises choses.

  • De bonnes interfaces utilisateur doivent être sans friction.

    Au lieu de lancer une boîte de dialogue (une opération coûteuse et que les utilisateurs ignorent après un certain temps) pour confirmer une suppression, effectuer la suppression et offrir un moyen d'annuler.

  • De bonnes interfaces utilisateur doivent être détectables.

    Bien que le ruban dans Microsoft Office reçoive beaucoup de flak car il oblige les anciens utilisateurs de Word à changer leurs manières, le ruban est un exemple brillant de la façon dont vous pouvez rendre une interface détectable (c'est-à-dire facile à découvrir).

  • De bonnes interfaces utilisateur, comme un bon code, devraient être explicites.

    Personne ne lit le manuel. Le seul manuel que j'ai jamais fait lire à mes utilisateurs était une présentation PowerPoint contenant des procédures pas à pas du logiciel. J'ai vu cela avec des outils vidéo comme Camtasia, mais les PowerPoints sont meilleurs parce que vous pouvez facilement parcourir les étapes en avant et en arrière.


-1

L'utilisateur ne fait pas d'erreurs. Les erreurs résident dans le programmeur qui n'a pas réussi à créer une interface utilisable.

Faites donc des tests d'utilisabilité avec chaque version!


2
À l'époque où je vivais avec mes parents, mon père m'a demandé pourquoi il était déconnecté d'Internet à chaque fois qu'il vérifiait son courrier électronique (oui, c'était à l'époque de la pierre lorsque nous avions une connexion téléphonique - je suis juste aussi vieux ). Je lui ai demandé de me montrer - devinez ce que j'ai vu? Lorsque la boîte de dialogue Envoyer et recevoir d'Outlook Express est apparue, l'option de se déconnecter après l'envoi et la réception a été cochée. Je pense que tout
dépend de

3
Pas vraiment John. Si les programmeurs d'Outlook avaient réfléchi à cela, ils n'auraient pas placé cette CheckBox là-bas ni lui auraient donné une étiquette plus significative. Votre père n'est pas un idiot: cette fonctionnalité n'a pas été réfléchie ou a fait l'objet de tests d'utilisabilité. Le logiciel n'est pas là pour nous faire sentir stupides! :)
Arcturus

1
-1: Les utilisateurs font des erreurs de maquillage, même si elles pourraient être évités avec des choses comme un meilleur étiquetage. Le fait est que cette question demande des problèmes spécifiques qui ont des solutions spécifiques. Dire simplement "tester" est tout simplement une mauvaise réponse.
Maxpm
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.