Du fait de la loi de Fitts, il semble que le positionnement des commandes à proximité immédiate du curseur permet d'y accéder relativement rapidement: probablement pas aussi vite que éléments dans les coins de l'écran, mais toujours beaucoup plus rapide que les boutons qui sont positionnés arbitrairement.
Microsoft Office, par exemple, l'a utilisé pour afficher un menu standard avec des commandes telles que des boutons gras ou italique ou un sélecteur de couleur de texte très proche du curseur, le menu étant affiché lorsque l'application estime que l'utilisateur peut être intéressé par ces commandes. Étant donné que le menu est apparu lorsque l'utilisateur n'en a pas besoin et est resté caché lorsque l'utilisateur en a eu besoin, et étant donné que de petits contrôles étaient coincés ensemble dans une zone de forme rectangulaire, cet élément n'était probablement pas le meilleur exemple d'interaction réussie de l'utilisateur, mais toujours une illustration partielle de la loi de Fitts.
Dans le même temps, la communauté UX s'intéresse aux menus radiaux , comme indiqué lors de la recherche dans Google Images pour "roue de sélection ux" ou "ux menu radial. " Mais les exemples de menus que j'ai vus sont plus sur la conception visuelle et beaucoup moins sur l'expérience utilisateur: ils sont juste un joli moyen de regrouper les éléments, mais ne semblent pas améliorer la productivité des utilisateurs finaux.
Qu'en est-il de combiner ces deux idées , c'est-à-dire utiliser des menus radiaux et positionner ces menus autour du curseur lui-même? En fait, les deux utilisations que je connais où les molettes de boutons ont été combinées avec l'idée de proximité immédiate du curseur sont toutes deux très spécifiques au domaine:
Vidéos Microsoft Productivity Future Vision:
Il montre un cas très spécifique d'interface tactile, et bien que la loi de Fitts s'applique et qu'il y ait une contrainte de mouvement (c'est-à-dire, déplacer le bras dans une telle position est une tâche difficile et lente par rapport au déplacement uniquement des doigts), c'est toujours différent de un curseur (surtout parce que les doigts, dans cette configuration, sont beaucoup plus précis qu'un curseur qui peut s'éloigner trop de sa position d'origine).
Jeu vidéo Splinter Cell:
Ce deuxième exemple concerne un jeu de tir à la première personne, où un curseur a un rôle très spécifique de déplacement plutôt que de pointage sur un élément. Un aspect de cela est que la direction est beaucoup plus importante que la distance: je n'ai pas vu la mise en œuvre réelle, mais je suis sûr que si la personne regarde vers la gauche, l'arme jaune sera sélectionnée et restera sélectionnée non importe combien de temps la personne continue de tourner à gauche.
L'aspect "si vous vous éloignez trop de la position d'origine, vous êtes foutu" des molettes des boutons à curseur est-il la seule raison qui empêche cet élément d'interaction utilisateur d'être utilisé beaucoup plus qu'aujourd'hui?
Quelles pourraient être les autres mises en garde qui empêcheraient l'adoption mondiale de cet élément dans les applications de bureau où l'interaction principale se fait via une souris?
Il semble que cette question soit sur un sujet différent de Les interfaces de menu/bouton circulaires sont-elles intuitives? La question liée concerne les menus radiaux comme une forme d'organisation des boutons en général (y compris sur les appareils tactiles ). Le mien concerne les menus radiaux positionnés spécifiquement autour du curseur, dans une situation spécifique d'un produit où la plupart des interactions avec celui-ci se font avec une souris. J'ai déjà abordé les aspects discutés dans la réponse liée au troisième paragraphe de ma question.
La proximité n'est que la moitié de la loi de Fitts. La taille est l'autre moitié.
Bien que l'affichage d'un menu radial autour d'un curseur semble résoudre le problème de proximité, le fait est qu'il ne rend pas les choses beaucoup plus proches.
Les boutons de menu standard Windows Start ou Mac Apple Apple sont généralement beaucoup plus éloignés du curseur, mais ils sont beaucoup plus faciles et plus rapides à toucher que n'importe quel menu radial. En effet, les bords de l'écran servent pour augmenter la taille des boutons en les rendant effectivement infiniment grands dans certaines dimensions.
Les menus radiaux qui fonctionnent comme des anneaux ou des beignets autour du curseur ne résolvent pas correctement le problème de taille. Oui, les commandes sont plus proches, mais elles ne sont généralement pas beaucoup plus grandes que les boutons standard, donc le gain est minime.
Ils n'apparaissent pas non plus au même endroit à chaque fois. Il peut y avoir le même positionnement relatif en fonction du curseur, mais le positionnement absolu change en fonction du moment où l'utilisateur appelle le menu. Même si le bouton droit est le bon choix, il peut apparaître à la gauche de l'attention des utilisateurs et l'utilisateur doit recentrer son attention sur le point d'interaction.
Les menus radiaux dans les jeux résolvent à la fois la proximité et la taille.
Les jeux avec des menus radiaux n'ont généralement pas de curseur. Vous pouvez dire quel coin du menu radial est sélectionné, mais c'est une sélection directe plutôt que d'utiliser une flèche à l'écran pour sélectionner indirectement un coin. Cela permet à chaque coin d'avoir une taille effectivement infinie dans la direction radiale. Comme vous l'avez observé, cela facilite la sélection car seule la direction de l'entrée est importante, pas la distance.
Les menus du jeu ont également tendance à remplir tout l'écran et à apparaître au même endroit à chaque fois. Au lieu de devoir recentrer votre attention sur un nouvel endroit, vous pouvez rester concentré sur ce que vous faisiez. Ils sont également généralement modaux, de sorte que vous n'avez pas à vous soucier de la modification de l'entrée de menu en entrée de jeu. Dans votre exemple Splinter Cell, la sélection du coin gauche ne déplacera pas la vue du joueur vers la gauche (sauf si le joueur continue de maintenir la touche enfoncée après avoir effectué la sélection).
Un autre avantage des jeux est un périphérique d'entrée spécialisé qui fonctionne particulièrement bien avec ce type de menu. Les menus radiaux sont devenus plus courants dans les jeux à mesure que les joueurs s'habituaient aux joysticks analogiques trouvés sur la plupart des contrôleurs de console. Au lieu d'une souris qui utilise un positionnement absolu à l'écran, ces joysticks n'autorisent que la saisie relative et se recentrent toujours lorsqu'ils ne sont pas utilisés.
Cela signifie qu'une fois qu'un joueur est à l'aise avec le système de menu radial, il peut entrer dans le mode, faire tourner le joystick dans la direction dont il a besoin et faire une sélection extrêmement rapidement. Une fois qu'ils ont acquis une mémoire positionnelle de l'endroit où se trouvent les options importantes, ce comportement peut devenir presque automatique en cas de besoin.
Un menu en anneau traditionnel autour d'un curseur n'atteindra probablement jamais ce niveau d'intuitivité, mais vous pouvez vous en approcher. En faisant une entrée modale et bloquante pour le reste du programme, vous pourrez faire en sorte que les boutons s'étendent à l'infini depuis le centre de la roue. Vous aurez également besoin d'une action facile à exécuter qui invoque le menu radial. Cela permettra à l'utilisateur de voir le menu, d'utiliser la mémoire musculaire et positionnelle et de faire un geste approximatif pour sélectionner le bon coin en peu de temps.
Je ne connais pas le cas spécifique de l'application que vous souhaitez concevoir. Mais cette idée semble fonctionner pour un groupe de quelques options (environ 4 ou 5). Je pense que cela fonctionnerait mieux si vous avez une zone d'écran où un clic déclenche un cercle pour apparaître sur les environs. Cependant, l'utilisateur devrait tenir la souris pour que le puits reste. Ensuite, le léger mouvement dans n'importe quelle direction déclenchera l'angle qui pointerait vers certaines des options.
Si c'est votre idée, je pense que ce serait un excellent moyen de "cacher" une poignée de boutons pour les sauvegarder dans des situations où l'utilisateur n'en a pas besoin. Cela fonctionnerait probablement mieux pour les applications qui utiliseraient plus la souris que le clavier (ce serait peut-être bien sur les écrans tactiles).