Boutons de la barre d'outils - être ou ne pas être?
Je dois créer une barre d'outils pour mon application, et supposons qu'en raison de contraintes externes, il doit s'agir d'une barre d'outils standard, pas d'un ruban. L'application elle-même a un nombre important de fonctions, et maintenant la question devient: comment choisissez-vous les fonctions à mettre sur la barre d'outils?
Les différentes directives de l'interface utilisateur indiquent que la barre d'outils doit héberger "la fonctionnalité la plus courante". Cependant, on ne sait vraiment pas ce que cela signifie. À quelle fréquence une fonction doit-elle être utilisée pour mériter d'être incluse dans une barre d'outils? Comment effectuez-vous des tests d'utilisabilité pour comprendre quels boutons doivent se trouver dans la barre d'outils et comment détecter si un bouton déjà présent doit être supprimé?
D'après ma propre expérience, les applications obtiennent rarement leur fonctionnalité de barre d'outils correctement. Par exemple, la barre d'outils de Total Commander ressemble à ceci: 
Je n'utilise jamais aucun des boutons sauf ceux que j'y ai mis moi-même.
La barre d'outils Notepad ++ est probablement meilleure (au moins je comprends ce que font la majorité des boutons), 
mais même dans ce cas, j'ai du mal à imaginer un utilisateur qui utiliserait "Couper", "Copier", "Coller", "Annuler" et "Rétablir" dans la barre d'outils au lieu d'utiliser un raccourci clavier. De plus, à quelle fréquence devez-vous créer une "boîte de dialogue définie par l'utilisateur" ou "enregistrer une macro"?
Est-ce une bonne approche de jeter des boutons simplement parce qu'il y a de la place pour eux? Ou l'approche de Google Chrome pour le maintenir au strict minimum est-elle meilleure?
Je comprends qu'il y a généralement un avantage à avoir un bouton de barre d'outils dans la mesure où les utilisateurs peuvent cliquer dessus plus rapidement que de sélectionner la même commande dans le menu. Mais il y a aussi un coût associé à chaque bouton de la barre d'outils en ce qu'il encombre l'interface et rend les autres boutons de la barre d'outils plus difficiles à trouver. Alors, comment puis-je évaluer le rapport coût/bénéfice dans ce cas?
EDIT: Si cela aide, l'application que j'écris est un IDE, les utilisateurs cibles sont des programmeurs. Il s'agit d'une application de bureau, initialement développée pour Windows uniquement.
Je suppose que nous parlons ici d'une application de bureau. De plus, je ne connais pas vraiment le type d'application que vous créez, mais je peux vous aider à étudier les besoins de l'utilisateur sans vous enliser avec la question "combien de clics faut-il pour arriver à une bonne UX" . La plupart de vos exemples semblent concerner des éditeurs de texte; donc, nous irons avec ça.
Ma recommandation est quelque peu étrange par rapport à la construction en premier et voyez comment les utilisateurs l'utilisent - "elle" étant la barre d'outils elle-même.
Numéro d'itération 0,1 - supprimer complètement la barre d'outils et les raccourcis clavier - menus uniquement. Laissez quelques personnes internes (vous y compris) l'utiliser un peu (si c'est juste vous, passez un jour ou deux à jouer avec l'application comme vous le feriez vous - vous allez utiliser votre propre application, non?), et effectuer de l'archéologie avec ces utilisateurs (concept emprunté à IDEO). Quels éléments du menu vont-ils répéter encore et encore? Demande-t-on/suppose-t-il réellement qu'il y a un raccourci clavier avant d'aller au menu (indication d'en faire éventuellement un)? Tout ce que vous avez à faire est de compter le nombre de clics sur un élément de menu particulier.
L'avantage de l'aborder de cette façon est que vous devrez de toute façon créer le menu - l'un des éléments les plus négligés d'une application publiée par des fournisseurs individuels (au moins pour le Mac) - cette méthode vous oblige à en créer un .
Donc, vous connaissez les boutons chauds - ceux avec le plus de clics. Maintenant, pour la ronde 0.2 - créez des raccourcis clavier pour les éléments de menu sur lesquels les utilisateurs ont le plus cliqué. Encore une fois, mesurez ces choses. À quelle fréquence, après avoir vu les raccourcis clavier, vos utilisateurs commencent-ils à les utiliser à la place du menu? Ce sont probablement d'excellents candidats pour être dans une barre d'outils quelque part.
N'assumez pas grand-chose sans tester votre hypothèse (j'ai vu beaucoup d'applications ou entendu beaucoup de PDG, où ils ont dit: "Je connais des utilisateurs, ils voudront ..." - essayez d'éviter autant que possible.)
Vous êtes maintenant prêt à créer une barre d'outils. Vous connaissez les fonctions que les gens utilisent le plus. Vous connaissez les fonctions que les utilisateurs essaient le plus rapidement pour apprendre le raccourci clavier. Vous connaissez également les fonctions que les gens supposent avoir déjà des raccourcis clavier et ce qu'ils devraient être. Les fonctions où les gens allaient beaucoup au menu, supposaient déjà un raccourci clavier de 0,1, et ont commencé à utiliser le raccourci au lieu du menu en 0,2 - il n'est peut-être pas nécessaire d'aller dans la barre d'outils - car s'ils ont déjà supposé qu'il y avait un raccourci pour cela en 0.1 et/ou mémorisé le raccourci pour cela en 0.2 - signifie qu'ils seront très probablement par défaut à que méthodologie d'interaction (couper, copier et coller, par exemple ).
Ceux où les gens cliquaient beaucoup sur les éléments du menu, ne supposaient pas qu'il y avait un raccourci en 0,1, mais ont appris le raccourci peu de temps après l'avoir vu pour la première fois en 0,2 - assez bon candidat pour être dans la barre d'outils (gras, italique, par exemple). Tout ce qui implique une liste déroulante - un très bon candidat également (police et police par exemple).
Maintenant, nous arrivons à la fonctionnalité la plus obscure et au bit d'archéologie. Impliquant généralement tous ces éléments, les gens ne cliquaient pas vraiment sur beaucoup 0,1 ou 0,2 (et vous n'avez probablement pas ajouté de raccourci pour eux non plus). Mais, lorsque vous avez regardé l'utilisateur essayer de le trouver dans le menu - il était frustré et semblait vouloir le trouver rapidement, mais il ne pouvait pas. Ces éléments sont des choses que vous voudrez peut-être envisager de rendre faciles d'accès d'une manière ou d'une autre, mais pas toujours "au visage de l'utilisateur". Par exemple, comparons le menu "styles" de MS Word au tiroir des styles de Apple Pages:
Dans l'exemple du ruban de MS, les styles sont toujours là - occupant de l'espace dans la barre d'outils - malgré que de nombreux utilisateurs ne les utilisent pas vraiment autant et/ou n'écrivent pas de documents qui doivent changer le style d'en-tête presque aussi souvent que, disons, passer à une liste à puces, ce que vous pouvez aussi faire à partir du volet des styles. Dans l'exemple Pages d'Apple, le tiroir de style s'affiche lorsque vous appuyez sur le symbole de paragraphe bleu - se masque lorsque vous le touchez à nouveau - éventuellement visible tout le temps ou non en fonction des préférences de l'utilisateur, mais la bascule est dans la barre d'outils.
Testez-le à nouveau comme 0,3. Après quoi, vous découvrirez ces fonctions tertiaires que les gens n'utilisent pas souvent. Ne sont pas terriblement bouleversés, ils ne peuvent pas trouver et n'ont pas de raccourcis. Créez ensuite un moyen pour eux d'y accéder. Dans le cas de Pages, cela est géré par l'inspecteur - qui est juste une boîte de dialogue qui apparaît avec une navigation par onglets:
Maintenant, vous avez un menu fonctionnel entièrement (relativement parlant), avec des touches de raccourci basées sur l'utilisation réelle sans deviner. Vous avez une assez bonne idée de ce qui devrait être disponible tout le temps dans la barre d'outils. Et, vous avez les articles dont vous voudrez peut-être être disponibles rapidement, mais en option. En regardant les éléments où les clics des utilisateurs se situaient quelque part au milieu - utilisez votre meilleur jugement (dans Pages, par exemple, je n'utilise jamais ce bouton de colonne, mais, si jamais j'en ai besoin - il est là; notez qu'il s'agit également d'une liste déroulante , qui est généralement le premier territoire de la barre d'outils).
En réponse à cela étant un IDE. Les chances sont que ce sont des geeks informatiques - et utiliseront très probablement des raccourcis le plus souvent. Ce qui est bien en utilisant le premier concept "construire un menu".
J'espère que cela aide, car il n'y a vraiment pas de règle "s'ils cliquent sur X nombre de fois" à ma connaissance.
Tout d'abord, vous voudrez utiliser le tri des cartes pour déterminer quelles fonctionnalités vont dans le même groupe. Après cela, vous souhaitez garder les fonctions les plus utilisées directement visibles dans la barre d'outils elle-même et le reste peut être masqué dans les menus déroulants.
Comment décider quelle fonctionnalité est la plus utilisée? Eh bien, pour cela, vous devrez évaluer les fonctionnalités de base de l'application que vous construisez. S'il s'agit d'un éditeur de texte, les raccourcis habituels d'édition de texte, couper, coller, modifier, etc. sont généralement une bonne option à conserver dans la barre d'outils. Quel type d'application faites-vous? Je peux être plus précis si vous pouvez le dire.
Maintenant, la notion de tout supprimer de l'interface jusqu'à ce qu'il ne reste que l'essentiel est l'essence même d'un bon design. Dans le navigateur, il est logique de tout supprimer, mais les contrôles de page et la fonctionnalité de recherche sont visibles (Firefox, Chrome, Safari, etc.) Malheureusement, dans le cas d'une application (qui a beaucoup plus de fonctions que la simple visualisation de pages Web, c'est plus difficile). tâche.
Enfin, le test utilisateur est un bon outil de test pour voir quelles fonctions sont nécessaires dans la barre d'outils.
modifier 1 D'après mon expérience personnelle, je peux vous dire les 2 extrêmes des IDE de l'éditeur de texte: Notepad ++ avec sa barre d'outils pleine échelle et Sublime Text avec son interface dépouillée avec rien d'autre qu'un aperçu du code lui-même.
Comparons ces 2 éditeurs (au niveau de l'interface utilisateur):
Texte sublime: La principale caractéristique est l'aperçu du texte que vous obtenez ici. En dehors de cela, pas de boutons, pas de barres d'outils pour vous intimider et une barre de menus standard pour l'éditeur de texte.
Notepad ++: Vous êtes confronté à une barre d'outils monstrueuse avec des fonctions variées telles que la modification de texte, les macros, etc. et puis il y a le menu standard au-dessus avec quelques menus supplémentaires IDE IDE $ ===.
Je connais de nombreux programmeurs/développeurs qui ont utilisé du texte sublime comme leur principal IDE. La raison principale est la simplicité et la beauté de l'interface. La raison principale est que, si l'utilisateur est un utilisateur expérimenté, il connaît bien toutes les fonctionnalités qu'un éditeur de texte IDE devrait offrir. Ils peuvent aller à l'intérieur des menus et personnaliser les paramètres de leur environnement et c'est tout. L'environnement n'est pas quelque chose que les programmeurs changent de temps en temps (à la volée). Par conséquent, pas besoin d'une barre d'outils permanente. Un texte sublime a frappé ce point idéal et a ajouté la fonctionnalité de vue d'ensemble impressionnante pour le clouer.
Leçon: La beauté et la simplicité ont séduit les fonctionnalités volumineuses.
Ne supposez pas que les boutons de la barre d'outils ne sont là que pour être cliqués. N'évaluez pas l'utilité d'un bouton uniquement par ses clics.
J'y ai pensé en regardant votre photo d'écran de Notepad ++. Dans Notepad ++, je clique très rarement sur les boutons Annuler/Rétablir, mais je les utilise beaucoup. En les regardant simplement. Ces boutons, gris ou verts, me disent s'il y a quelque chose à annuler ou à refaire. Et cela m'est très utile. Ces boutons me manquent dans Eclipse.
Qu'en est-il d'une barre d'outils personnalisable où les gens pourraient ajouter/supprimer des boutons, comme sur Microsoft Outlook?
Chaque personne a des préférences différentes en ce qui concerne l'UX, en particulier les utilisateurs avancés (et selon votre article, les utilisateurs seront des programmeurs, donc très probablement des utilisateurs avancés). Alors pourquoi ne pas les laisser choisir ce qu'ils veulent voir dans cette barre d'outils?
En guise de remarque (et cela peut être un peu hors de la portée initiale de la question, mais en ce qui concerne l'UX, nous devrions élargir notre vue), la barre d'outils n'est pas le seul moyen d'accéder à vos fonctions, il existe plusieurs autres façons peut explorer (si elles peuvent être appliquées dans votre cas d'utilisation particulier):
- raccourcis clavier
- menu clic droit
- ligne de commande (certaines applications offrent une console où vous pouvez exécuter des commandes)
- gestes de la souris/du pavé tactile