Menus gestuels "Fluid Touch" sur applications mobiles
Il y a quelques semaines, j'ai lu n article de blog sur un moyen de réduire les clics/touches lors de la sélection d'éléments dans les menus extensibles:
Le comportement le plus courant consiste à toucher une icône pour ouvrir un menu, puis à nouveau sur l'élément que vous souhaitez sélectionner.
Le billet de blog que j'ai lu était censé offrir une façon "fluide" d'interagir avec le menu: le menu s'ouvrait au début du toucher et la sélection des éléments se produisait lorsque le geste tactile était terminé. En effectuant cette modification simple, il est possible d'ouvrir le menu et de sélectionner un élément avec un seul geste tactile, tout en offrant la méthode de sélection à deux touches commune. Un exemple en ligne de cela peut également être vu ici .
Nous développons une version mobile de notre application Web, donc je suis intéressé s'il y a des inconvénients à l'utiliser? Dans quels cas cela ne devrait-il pas être utilisé?
Ce système de menus existe depuis un certain temps
Les développeurs de jeux mobiles et tablettes comme Gameloft ont utilisé l'interaction pendant des années avant que l'article (ou la démo source qu'il référence) ne soit écrit.
Dans les jeux sur tablette, ils sont utilisés pour des cas comme lancer des sorts dans un jeu d'action. Il est utile d'étudier pourquoi ils sont efficaces dans ces interfaces:
- L'utilisateur frappe le bouton du sort, un ensemble de sorts apparaît immédiatement (pas d'animation) en demi-cercle autour du bouton, et l'utilisateur glisse son doigt sur le sort qu'elle veut lancer, puis relâche pour lancer.
- Cela permet au développeur du jeu de maximiser l'espace d'écran limité pour jouer, tout en fournissant des menus rapides aux joueurs lorsqu'ils en ont besoin.
- Surtout, il permet aux joueurs d'accéder et de sélectionner rapidement des sorts sans quitter l'œil de l'action du jeu au centre de l'écran. Ceci est possible parce que les joueurs utilisent la mémoire musculaire pour se rappeler où se trouve chaque sort, afin qu'ils n'aient pas à chercher à frapper la touche du sort.
- Tout aussi important, la clé du sort est utilisée des centaines de fois dans un jeu afin que la mémoire musculaire s'installe rapidement.
Un menu fluide similaire est utilisé par Samsung dans son interface tactile pour les tablettes à stylet.
- Maintenez le stylet enfoncé (ou survolez-le et cliquez dessus) pour afficher un menu circulaire dans lequel vous pouvez faire glisser le stylet pour sélectionner une option.
- Comparé à l'interface de jeu, c'est beaucoup moins de succès. Le menu n'est pas souvent utilisé, donc lorsqu'il apparaît difficile à numériser, car vous devez tenir le stylet fermement et vos doigts/poignets peuvent vous empêcher de voir le menu.
Ces exemples informent ma propre opinion sur ces contrôles:
Ils sont mignons mais pas très bons pour la plupart des applications.
- Bien que les fenêtres contextuelles traditionnelles nécessitent 2 pressions, elles sont plus faciles à utiliser sur le plan cognitif. Il faut en fait une charge cognitive pour maintenir un bouton enfoncé lors de la numérisation de la fenêtre contextuelle.
- Le fait de glisser du bouton vers la sélection nécessite plus de charge cognitive que de simplement appuyer sur la sélection. Particulièrement lorsque vous glissez sur d'autres choix de menu pour arriver à celui que vous voulez (parce que vous venez de numériser ces éléments, le cerveau ne voit pas la zone comme un "espace ouvert" donc il voudra hésiter/traiter lorsque vous les glisserez dessus) )
- Il existe des problèmes de convivialité avec les utilisateurs handicapés.
Ils peuvent être efficaces pour les applications où (a) le menu sera utilisé fréquemment et où les sélections ne changeront pas; ou (b) il est avantageux de les sélectionner via orientation (par exemple, appuyez sur puis faites glisser vers la gauche, la droite ou vers le haut) .... ces cas, la diapositive fournit en fait une aide cognitive car une fois que l'utilisateur appuie sur le bouton , la sélection se fait positionnellement par glissement par rapport au tap d'origine .
- Exemple de (b): les choix de menu sont Nord, Sud, Est et Ouest, ou haut/bas/gauche/droite.
- Exemple de (a): menus fréquemment utilisés comme le lancement de sorts de jeu, l'utilisateur peut mémoriser l'orientation afin qu'elle devienne une action mémorisée par les muscles qui peut être accomplie incroyablement rapidement.
- Glisser les claviers est un exemple différent mais connexe, comme le note Okavango. Ici, les utilisateurs connaissent l'orientation du clavier qwerty afin de pouvoir taper en glissant vers un placement des touches mémorisé par les muscles.
J'espère que cela pourra aider.
Il me semble que Les gestes fluides sont très similaires à La saisie gestuelle ( dans une certaine mesure): Les deux approches visent à réduire le nombre de touches nécessaires pour effectuer une séquence d'actions.
Saisie gestuelle:
La saisie gestuelle fonctionne en faisant glisser votre doigt sur les lettres du mot que vous souhaitez saisir.
La chose importante que l'exemple ci-dessus est que les utilisateurs peuvent voir les lettres qu'ils peuvent sélectionner pour qu'il y ait un chemin gestuel clair " " à suivre et une rétroaction adéquate; Le clavier suggérera des mots plus susceptibles d'être ciblés par l'utilisateur.
Gestes fluides
J'ai essayé d'utiliser le geste et je n'ai pas pu comprendre exactement ce que j'étais censé faire avant d'avoir lu les instructions! (mauvais départ):
Bien que j'aime vraiment l'idée! il me semble que par rapport à la saisie gestuelle, il n'y a pas de "chemin gestuel" clair à suivre et le feedback est imprévisible. Donc, pour que cela fonctionne, la conception doit être limitée aux actions qui suivent dans des séquences d'actions claires, logiques, courtes et prévisibles (pour éliminer l'incertitude et pour améliorer la boucle de rétroaction:
Par exemple, ce n'est qu'une supposition éclairée:
- Faites glisser => Déposer => enregistrer.
Sélectionnez => jouer => avancer
OR
Sélectionnez => jouer => rembobiner.