Bouton déroulant et options disjointes
En haut de l'application, nous avons une barre de fonctions qui contient (presque) toutes les fonctions qui peuvent être effectuées sur les entrées d'un tableau ci-dessous, assez similaire à l'interface utilisateur Office Fluent. Nous essayons de minimiser le nombre de fonctions mais nous avons plusieurs écrans dans l'application qui dépasseront l'espace qui se trouve dans la barre. Nous voulons maintenant inclure un bouton déroulant/bouton partagé/bouton menu/....
Cependant, nous avons un groupe de fonctions où les options sont disjointes et ne sont jamais actives en même temps, il serait toutefois judicieux de les regrouper. Nous ne cachons jamais les boutons dans l'application mais les grisons.
Comment procéderiez-vous si la fonction supérieure est désactivée (mais est la fonction la plus utilisée) et que la deuxième fonction est active.
La deuxième fonction doit-elle "sauter" vers le haut?
Devrait-il y rester? S'il doit y rester, comment puis-je indiquer que le bouton est inactif mais que la liste déroulante est active.
Ne devrais-je pas du tout utiliser un bouton de menu?
Les boutons de partage sont parfaits lorsqu'il existe une commande que les utilisateurs utilisent la plupart du temps, puis plusieurs autres qu'ils utilisent parfois. Les utilisateurs ont un accès rapide en un seul clic à ce dont ils ont besoin la plupart du temps, tandis que les commandes moins courantes sont toujours disponibles mais à l'écart. C'est ainsi qu'il contribue à une interface utilisateur "fluide" (rapide et stupide): en favorisant la vitesse pour les commandes courantes tout en masquant l'encombrement des commandes rares.
Voici les options que je vous vois face à votre situation:
Désactivation du bouton. Lorsque vous utilisez un bouton divisé, si vous conservez la commande pour le bouton la même et désactivez-la si nécessaire, les utilisateurs peuvent penser que l'ensemble du menu est désactivé (s'ils ne remarquent pas que la petite flèche est activée). Cela compromet également la "fluidité" du bouton partagé, car la plupart des utilisateurs ne peuvent pas toujours accéder à la commande à laquelle ils ont le plus probablement besoin d'accéder.
Swap Button Command. La deuxième pire option consiste à permuter les commandes du bouton. Ici, le problème est que les utilisateurs ne seront pas en mesure de développer des habitudes utiles pour chaque commande, car parfois une commande est sur le bouton et d'autres fois, elle est sur la division. Ils devront s’arrêter, lire le bouton et réfléchir avant d’agir ("ok, la commande que je veux n’est pas là, donc elle doit être sur le split cette fois"). Encore une fois, pas trop bon pour la fluidité. Les directives Windows UX permettent de faire du bouton la dernière commande utilisée, dans l'hypothèse qu'il est susceptible d'être réutilisé. Si cela correspond à votre cas, alors c'est une bonne solution. Cependant, je ferais attention à ne pas permuter une commande différente à partir de la dernière utilisée (par exemple, parce que la dernière commande est maintenant désactivée), sauf si la nouvelle commande est hautement prévisible et "logique" pour vos utilisateurs. Je n'essaierais pas cela sans une bonne quantité de recherche d'utilisateurs en premier.
Bouton de menu. Il semble que vous ayez un cas où l'utilisation des commandes est répartie de manière plus égale entre les commandes - chaque commande n'est pas disponible pour une bonne partie de le temps. Vous avez peut-être besoin d'un bouton de menu, qui est différent d'un bouton divisé en ce sens qu'un bouton de menu toujours ouvre une liste déroulante de commandes, essentiellement identique à un menu déroulant. Étiquetez le bouton de menu avec la catégorie de commandes. Cliquez dessus pour afficher une liste stable de commandes, certaines étant désactivées si nécessaire. Cela signifie que vos commandes nécessitent toujours deux clics pour être sélectionnées, ce qui coûte à l'utilisateur une certaine efficacité, mais au moins les utilisateurs n'auront pas à s'arrêter et à réfléchir avant de l'utiliser.
Bouton de basculement. Par hasard, les deux commandes les plus couramment utilisées s'excluent-elles mutuellement de telle sorte que l'une est toujours activée et lorsque l'autre est désactivée et vice versa? Par exemple, une commande agrandit la vue et une la réduit la vue? Si c'est le cas, vous pouvez peut-être combiner les deux en un _ attribut _ à bascule. Ici, vous avez un bouton à bascule (ou même une case à cocher) étiqueté comme celui des états de l'attribut (par exemple, "Développer") que l'utilisateur peut définir (cocher) ou désactiver. Vous avez toujours une flèche déroulante pour d'autres commandes pour affiner l'état actuel. De cette façon, vous avez toujours la "même" fonction (telle que vos utilisateurs la perçoivent) activée comme bouton.
Banque de menus. S'il y a beaucoup de commandes du côté divisé, la dernière option à laquelle je peux penser est de construire un " banque de menus , "essentiellement un bouton divisé avec plusieurs boutons. Sélectionnez deux à quatre des commandes les plus couramment utilisées, où au moins l'une d'entre elles est toujours activée. Donnez à chacune de ces commandes leur propre bouton de commande qui est toujours visible, regroupez-les et ajoutez une flèche déroulante pour les commandes restantes. L'inconvénient est que cela prend plus d'espace qu'un seul bouton, et que vous aurez toujours des boutons désactivés qui occuperont un espace précieux, mais au moins cela garantit que la commande la plus couramment utilisée est toujours à un clic.
Si je vous comprends bien, c'est comme ça, vous avez un menu permet de dire
Save | Edit | Undo
L'annulation en tant que point principal a une option de liste déroulante pour rétablir, mais il se peut que l'on ne puisse rien annuler mais seulement refaire.
Dans ce cas, je le ferais sauter en haut pour être vu, même si normalement il vaut mieux avoir un menu cohérent. Les gens sont habitués à cela cependant, car c'est un peu comme cacher des boutons qui ne peuvent pas être utilisés et montrer des boutons qui peuvent être utilisés.