UI: Hover / focus pour révéler les contrôles?
Nous avons des profils pour notre application Web contenant une bonne quantité de données qui prennent beaucoup d'espace à l'écran. Chaque segment a des boutons d'édition/suppression associés qui encombrent l'écran et distraient du contenu s'ils sont tous visibles en même temps.
Nous jouons avec l'idée de révéler des contrôles lors du survol ou de la concentration sur un segment de données. Ce comportement peut être observé sur des applications comme Facebook, lorsque vous survolez des éléments du fil d'actualités (un bouton déroulant ou "Supprimer" apparaît.) Twitter l'implémente également sur des tweets individuels. Il existe de nombreux autres exemples dans la nature (fonctionnalités de commentaire, forums, etc.)
Ma préoccupation est qu'il n'y a pas la possibilité d'inciter l'utilisateur à survoler/se concentrer sur un segment vide de données, et que créer une telle accessibilité compliquera l'esthétique visuelle. Je ne veux pas créer d'obstacle à l'apprentissage de l'utilisation de l'interface, mais je ne sais vraiment pas dans quelle mesure cela créera une barrière, et mon hypothèse (dangereuse) est que ce n'est pas grave. Malheureusement, je ne suis pas nos utilisateurs.
Quelqu'un sait-il à quel point une courbe d'apprentissage est introduite lorsque les contrôles sont cachés à l'utilisateur jusqu'à ce qu'ils commencent à interagir? Y a-t-il de meilleures options? Des listes déroulantes ont été envisagées, mais la réduction pure et simple des éléments "cliquables" visibles n'est pas optimale.
Je ne pense pas que l’argument ait été fait pour utiliser des contrôles de révélation en survol. Le souci est apparemment que l'encombrement des contrôles empêche de voir les données. C'est une possibilité certaine, mais il me semble qu'une conception graphique correctement équilibrée, avec des données à contraste élevé et des commandes relativement en sourdine, est une meilleure façon de gérer cela.
Reveal-on-hover a quelques problèmes:
Le premier est que les utilisateurs ne parviennent pas à découvrir les contrôles, comme vous l'avez dit. Les utilisateurs explorent en consultant les pages Web. Ils ne les "sentent" pas en passant la souris dessus.
Le deuxième problème, et plus probable, est qu'il rend plus difficile pour les utilisateurs d'activer les contrôles, apparemment parce qu'ils n'ont pas de cible claire à viser, à moins qu'ils ne survolent l'objet de données prévu. L'UIE a constaté que les utilisateurs décident d'abord de l'action puis déplacent la souris , le résultat étant que l'utilisateur a utilisé les liens avec plus de succès lorsqu'ils étaient visibles en permanence (par rapport au survol), même si cela rend la page plus encombrée. J'attends la même chose pour l'édition des contrôles. L'avantage de répéter les mêmes contrôles pour plusieurs objets de données est de donner à l'utilisateur un accès rapide en un clic à la commande. Masquer les commandes annule cet avantage. Si l'encombrement est une telle préoccupation (par exemple, vous avez plus de quelques commandes), il est préférable de suivre un modèle d'interaction sélection-objet-action et de placer les contrôles sur une barre d'outils centralisée.
Un troisième problème induit des effets d'animation involontaires lorsque l'utilisateur fait glisser la souris sur les objets de données, ce qui peut être très gênant - beaucoup plus gênant que de laisser les contrôles visibles à plein temps.
J'aimerais voir des recherches sur la révélation en survol pour les commandes de commande. Mais jusque-là, je ne l'utiliserais pas dans une application à moins qu'un test d'utilisabilité ne démontre qu'il aide à encombrer les problèmes sans introduire de problèmes plus graves.
Lorsque vos commandes de vol stationnaire sont cohérentes et omniprésentes, vous n'avez pas besoin d'avoir une accessibilité visible. Pour tous les exemples que vous mentionnez, chaque élément à l'écran a presque les mêmes commandes de survol. De même, si chaque élément de votre formulaire a les mêmes contrôles de survol, l'utilisateur les découvrira rapidement et automatiquement en utilisant simplement le formulaire.
Il convient de noter que pour que cela fonctionne, la zone doit déjà avoir une tâche que l'utilisateur peut y effectuer. Par exemple, cela ne fonctionnera pas pour une simple étiquette. Il doit y avoir un contrôle actif sur lequel l'utilisateur peut déjà cliquer. Les contrôles de survol doivent être extra actions qu'ils peuvent entreprendre au-delà de la base. De cette manière, l'utilisateur ira effectuer l'interaction de base et verra les actions supplémentaires disponibles au survol. Si une section de l'écran n'a rien à voir du tout à part la lire, alors l'utilisateur n'a rien à faire et peut manquer les commandes de survol même lorsqu'elles sont sur chaque commande.
Par exemple, dans les salles de discussion StackExchange, vous pouvez déjà discuter sans aucun contrôle de survol. Les commandes de survol sont une capacité facultative présente sur chaque ligne de discussion. En quelques minutes, un utilisateur typique aura découvert que chaque ligne de discussion est également une entité cliquable avec ses propres contrôles. Mais les contrôles de survol ne sont pas nécessaires pour utiliser la page, donc un utilisateur ne manquera pas de trouver quoi faire s'il ne découvre pas immédiatement les outils de survol.