Cette page a démarré sur TooManyChoices
En général, le fait d'avoir des choix est une grande chose.
Mais souvent il y a BeaucoupTropDeChoix.
Si vous allez dans un restaurant, et que vous posiez des questions sur la manière spécifique dont vous voulez que votre dîner soit préparé, vous pourriez vous retrouver embarassé.
Logiciel :
- Vous voulez utiliser un programme d'une manière "normale", mais êtes inondé par le nombre de choix qui s'offre à vous.
- Vous voulez produire une personnalisation franchement commune, mais vous êtes inondé par les options qui n'ont pas de sens que les utilisateurs n'utiliseront jamais.
Wiki :
- Quelques personnes sont ennuyées par le nombre des moteurs wiki à choisir (Voir ChoisirUnMoteurWiki, WikiClone, MoteurWiki, BeaucoupTropDeMoteursWiki.)
- Si vous autorisez à la fois le LienLibre et la casse ChatMot, il est plus que probable que les personnes viendront avec des noms vraiment différents pour signifier la même chose. Par exemple, "Beaucoup Trop De Choix" et "!Beaucoup Trop De Choix" pourraient tous deux exister.
- Le fait de lier dans des pages wiki fait que le lecteur décide : "Dois-je suivre ce lien, ou non ?" Le fait de lier aussi souvent que possible force le lecteur à produire un nombre de choix, qui interrompent la compréhension du texte en lui-même.
Communication :
- Choisir entre des téléphones cellulaires, des téléphones fixes, des adresses email, l'IRC, les messageries instantanées et les sites web de communauté, peut rendre difficile de savoir comment communiquer.(ConfusionCanal? pourrait être traduit sur CanalConfusion? ou ChaîneConfusion? ?)
BeaucoupTropDeChoix est similaire à FeatureKarma en anglais.
C'est l'une des leçons-clés de l'InterfaceHumaine (traduire HumaneInterface). Le fait d'avoir seulement un chemin pour faire quelque chose (monotonie) est bon, parce ce que cela promeut le formatage d'habitudes.
::"Le choix supplémentaire requiert une pensée supplémentaire et le temps gagné à utiliser une technique optimale d'interaction est souvent inférieur au temps perdu à devoir penser au lieu de simplement migrer avec une unique technique d'interaction qui est toujours utilisée. Cela prend au moins une seconde et souvent deux secondes de décider entre deux techniques d'interactions possibles qui est de savoir la raison pour laquelle il est habituellement préférable de ne pas offrir un choix aux utilisateurs" – JakobNielsen [1]
Ceci semble "long-winded" (éventé ?). Quel est le raccourci pour dire ceci ?
Quelques moyens pour éviter BeaucoupTropDeChoix
- Ne servez pas des besoins hypothétiques. "Quelqu'un peut vouloir le faire comme ça." Consacrez votre temps à de vrais besoins. Assurez-vous que tous les contributeurs sachent cela.
- Faites que les choses soient extensibles. Si quelque cuisinier veut ajouter à la conception pour servir ses goût idiosyncrasiques (petites manies) laissez-le produire l'extension. Maintenez-le à distance du coeur de votre design. Si par chance cela devient plus populaire, incorporez-là et lancez votre premier choix. Vous aviez tort.
- Ne produisez pas de choses extensibles. Les personnes produiront les extensions simplement pour voir comment cela fonctionne, et puis obuliez leur raisonnement original et positionnez-vous de telle manière que l'extension soit valable dans son propre univers.
- Ignorez ce qui se niche sous les couvertures. Vous pouvez disposer d'un hypersystème de nature "cool object-passing architectural bus-messaging", mais s'il ne fait pas que le travail soit fait, débarassez-vous en. Sauvegardez-le quelque part pour jouer avec plus tard.
- Ne vous investissez pas dans une idée que vous ne pouvez pas switcher à un autre.
- Faites des choix. Poignardez vos bébés. Vous pouvez avoir deux bons moyens de faire quelque chose, mais vous n'en avez besoin que d'un. Choisissez-en un et collez-y vous. Jetez l'autre. Ne vous souciez pas de blesser les sensibilités des programmeurs, 'écrivains' ou designers. Ils ont besoin de placer le projet en premier. "eating your babies" – http://weblogs.java.net/pub/wlg/960 "Kill Your Darlings" Wiki:KillYourDarlings
- Faites du test utilisateur. Regardez comment les utilisateurs travaillent avec le système d'une façon par rapport à une autre. Ecoutez-les. Choisissez la meilleure.
- Documentez les choses. Soyez ouvert. Ayez de l'information sur les "clearinghouses". Assurez-vous que quiconque sache ce qui s'est déjà produit, ce qui a été fait, ce qui pourrait être fait. Ne laissez pas 10 personnes différentes réinventer la roue à cause de l'ignorance.
- Faites les choses justement de façon que les personnes ne ressentent pas le besoin de les refaire à nouveau et encore à nouveau.
- Ignorez la valeur des gains marginaux. Si vous avez un système qui s'améliore de 0.5%, ne switchez pas : les coûts de migration sont trop élevés pour justifier le changement. Et ne l'ajoutez pas en parallèle avec le système existant.
- Ignorez les compatibilités arrières. Facilitez pour tout le monde la mise à jour, et donnez-leur les bonne raisons de le faire. Puis coupez les "hold-outs".
- Canalisez l'énergie dans de nouvelles fonctionnalités au lieu de tourner les pouces ou réinventer de vieilles fonctionnalités. Ayez une jarre de travail avec des projets sur lesquels les personnes puissent travailler. Si quelqu'un vient à vous avec une idée sur la manière d'ajouter une nouvelle fonctionnalité qui est servie déjà de six manières différentes, aiguillez-les vers la jarre de travail. Donnez-leur des tâches, "juicy", amusantes et intéressantes qui ont besoin d'être réalisées à la place.
- Rejetez la propriété. DissuaderRéputation. Ne récompensez-pas les Génies Isolés ("J'ai récrit le système en entier de processus sur mon temps libre !") qui lancent des idées de conception sur votre implémentation déjà complètement ou presque achevée. Récompenser les joueurs en équipe qui obtiennent le consensus et font que les tâches soient réalisées.
- Prenez les arguments de design à la fin. Ne faites pas de compromis. ("What if we do it both ways?") interrompt simplement un argument. Utilisez des mesures objectives et documentez pourquoi vous avez conçu quelque chose d'une façon ou d'une autre.
- Revisitez les vieux arguments. Assurez-vous que leurs justifications tiennent encore la route. Si ce n'est pas le cas, recommencez à nouveau.
- Beaucoup de terminaux utilisateurs ont un petit clapet apparemment non fonctionnel qui couvre un bouquet de boutons. Quand on veut faire une tâche normale, typique, il y a seulement peu de gros boutons à regarder à l'extérieur et l'on peut rapidement décider lequel pousser. Quand on veut faire une tâche moins usuelle, rarement-faite, on scanne parfois les boutons à l'extérieur, on décide qu'aucun de ceux-ci ne correspondent exactement à ce qu'on veut faire, puis on ouvre le clapet et on commence à examiner les nombreux boutons minuscules nichés à l'intérieur. Il est alors admis que l'action d'ouvrir le clapet rend toutes les tâches comprises par ces boutons comme plus chronophages que si elles étaient sans clapet, le fait que le clapet m'aide à terminer plus vite des tâches fréquemment produites signifie cela, quand vous réfléchissez au montant total du temps à interagir avec le terminal, le clapet fait gagner du temps.
- <tongue-in-cheek> Utilisez un autre langage que Perl.</tongue-in-cheek> Extrait du manuel Perl, perl(1):
- La devise Perl est "Il existe plus d'une façon de le faire." Divining how many more is left as an exercise to the reader.
- BigOAnalysisOfInformationOrganization? mentionne que passer du "linéaire" au "hiérarchique" réduit dramatiquement le nombre de décisions que doit prendre une personne.
Le Paradoxe du Choix
Le Paradoxe du Choix : Why More is Less livre de Barry Schwartz
"A wider range of slightly inferior options, then, can make it harder to settle on one you’re happy with.""
Discussion
Ouverte et en cours en anglais sur TooManyChoices
Contributeurs
Voir aussi en anglais :
PageTranslation LangueFrançaise TooManyChoices