Ne pas masquer ou désactiver les éléments de menu?
En 2008, Joel Spolsky a écrit :
Il y a longtemps, il est devenu à la mode, voire recommandé, de désactiver les éléments de menu lorsqu'ils ne pouvaient pas être utilisés.
Ne fais pas ça. Les utilisateurs voient l'élément de menu désactivé sur lequel ils veulent cliquer, et se retrouvent sans aucune idée de ce qu'ils sont censés faire pour que l'élément de menu fonctionne.
Au lieu de cela, laissez l'élément de menu activé. S'il y a une raison pour laquelle vous ne pouvez pas terminer l'action, l'élément de menu peut afficher un message expliquant à l'utilisateur pourquoi.
C'est une idée intéressante, mais j'aurais aimé qu'il explique ce qu'il entendait par "afficher un message expliquant pourquoi à l'utilisateur".
Quelqu'un a-t-il réellement suivi ce conseil? Y a-t-il des exemples de menus qui affichent un message au lieu de désactiver un élément de menu - peut-être quelque chose que vous avez conçu vous-même, ou quelque chose de Fog Creek?
Je suis curieux de savoir quel mécanisme afficherait le message et si quelqu'un a de l'expérience (bonne ou mauvaise) pour afficher un message au lieu de désactiver un élément de menu.
Il fait plusieurs points de validité variable dans ce poste:
Expliquez pourquoi un élément est désactivé: Excellent conseil que presque personne ne suit! Google recherche "menu grisé" et vous trouverez des tas de gens se demandant pourquoi leurs éléments de menu sont désactivés, car l'application ne le fait pas dites-leur. Leur donner des informations lorsqu'ils survolent un élément désactivé ou essaient de cliquer dessus est un excellent moyen de réduire la confusion et de soutenir les appels. Google Docs le fait bien, ce petit gars apparaît si vous essayez de cliquer sur le bouton "Enregistrer" car ce n'est pas un bouton; il enregistre automatiquement!
Masquage des éléments : En général, c'est une mauvaise idée, en particulier dans les applications de bureau. En masquant des éléments simplement parce qu'un utilisateur ne peut pas les utiliser maintenant, il les aide souvent à apprendre l'élément n'existe pas et s'ils le voient, ils ne le savent peut-être pas pourquoi il n'existe pas la moitié du temps. Imaginez si la moitié de l'interface de MS Word a disparu chaque fois que vous passez d'un tableau à une puce à un pied de page!
Cependant, il existe deux situations connexes où le masquage d'éléments peut être utile: lorsqu'il s'agit d'une page/application Web ou lorsque l'élément est désactivé pour des raisons de sécurité. Dans un contexte de sécurité, un utilisateur de niveau inférieur peut ne jamais - avoir accéder à ces fonctions, et dans certains cas, même les afficher n'est pas souhaitable lorsque vous ne voulez pas que les utilisateurs sachent que certaines choses sont possibles (comme le changement mon nom ect).
Si l'utilisateur ne pourra jamais utiliser l'élément il suffit de le cacher et de le garder propre et simple. Des éléments comme celui-ci sont courants sur les pages Web et sont presque toujours masqués jusqu'à ce qu'un utilisateur soit authentifié.
Android I Guidelines recommande de réduire les éléments de menu qui ne peuvent pas être utilisés et de les masquer uniquement lorsqu'ils font partie d'un menu contextuel . Les menus contextuels changent tout le temps, après tout.
Désactivation des éléments : Pour les raisons mentionnées ci-dessus, la désactivation des éléments de menu sans les masquer permet aux utilisateurs de voir toutes les options. Comme l'indiquent les directives d'Android, "griser" ou plus souvent griser un élément indique clairement qu'un élément n'est pas utilisable, donc je peux voir en un coup d'œil que je ne peux utiliser aucune des options suivantes (dans GIMP):
C'est 14 options que je peux voir en un coup d'œil sont désactivées. Sa suggestion est de faire apparaître que je peux utiliser des options impossibles? Pas question. Le fait de griser des éléments me permet de voir en un coup d'œil si je peux ou non faire des choses. Je n'ai pas à cliquer sur chaque élément pour savoir s'il fonctionne ou non. C'est pourquoi nous les grisons.
Pas tout à fait - mais j'ai fait un pas de plus dans la bonne direction en ayant précédemment implémenté un mécanisme dans plusieurs applications de bureau, par lequel en plus à tout bouton ou élément de menu désactivé, un info-bulle montre la raison pour laquelle il est désactivé.
Ainsi, nous obtenons quelque chose comme ce qui suit (Désactivé devrait être nouveau)
Le suivi supplémentaire avec l'aide F1 hautement sensible au contexte est un bonus supplémentaire.
Notez qu'il est important que des info-bulles soient fournies partout pour une découverte et une cohérence plus faciles.
Je peux bien être biaisé ici, mais je pense c'est mieux que de garder le bouton activé parce que l'utilisateur n'est pas dupe de penser que la fonctionnalité est disponible, mais peut toujours découvrir pourquoi la fonction n'est pas disponible et quoi doit être fait pour le rendre accessible. Il aide l'utilisateur à se renseigner sur le système et ses exigences, et rend le système plus intelligent.
Pour ceux qui ont un intérêt technique, lisez la suite:
Ce mécanisme reposait sur un cadre interne appelé gestionnaire d'état :
Le gestionnaire d'état est un mécanisme centralisé par lequel tous les contrôles de l'application sont automatiquement activés ou désactivés en définissant et en désactivant un interne état du système .
Les contrôles affectés par les états du système sont enregistrés auprès du gestionnaire d'état, ainsi que les états du système qui affectent ce contrôle.
Les états du système peuvent être désactivateurs ou prérequis . Tout désactivateur associé peut forcer la désactivation d'un contrôle. De plus, tous les états de prérequis associés doivent être satisfaits pour qu'un contrôle reste activé.
Tous les états du système sont décrits par un message appelé raison - c'est-à-dire la raison pour laquelle l'état est défini ou la raison pour laquelle l'état n'est pas défini.
Lorsqu'un état du système change, le gestionnaire d'état met automatiquement à jour l'état activé du contrôle et insère ou supprime la raison dans l'info-bulle (un élément de base générateur d'infobulles logique requise ici).
Si nécessaire, plusieurs raisons de l'état désactivé peuvent être combinées dans l'info-bulle.
Le bouton "piste suivante" devrait donc être activé même si la liste de lecture est vide et que rien ne joue? Et le bouton d'enregistrement devrait être activé même si le document n'est pas sale afin que les utilisateurs ne sachent jamais vraiment s'ils ont du travail non enregistré?
Cela ressemble à une directive trop générale. Parfois, ce pourrait être une bonne idée d'échouer gracieusement et de montrer un message éducatif à l'utilisateur, mais je pense que les gens sont très habitués aux contrôles désactivés pour indiquer l'état de l'application et ne jamais les utiliser est tout simplement déraisonnable.
" Prévention des erreurs
Encore mieux que de bons messages d'erreur est une conception soignée qui empêche un problème de se produire en premier lieu. Soit éliminer les conditions sujettes aux erreurs, soit les vérifier et présenter aux utilisateurs une option de confirmation avant de s'engager dans l'action. "- Jakob Nielsen
http://www.useit.com/papers/heuristic/heuristic_list.html
Je pense que cela dépend de la situation si c'est une bonne idée de cacher l'élément ou de le désactiver.
S'il s'agit d'un lien vers une interface d'administration et que l'utilisateur n'est pas un administrateur, il n'est pas nécessaire de l'afficher. Mais s'il s'agit d'un lien désactivé pour enregistrer un document et que l'utilisateur peut enregistrer le document la dernière fois qu'il y a travaillé, une explication de la raison pour laquelle il n'est pas possible d'enregistrer serait souhaitable.
Microsoft OneNote ne possède pas de bouton Enregistrer car il enregistre automatiquement le fichier, ce qui est logique dans un sens, mais peut être un peu déroutant car toutes les autres applications MS Office le conservent. Qu'elle soit logique ou non, la cohérence est certainement un facteur important. Si vous le désactivez à certains endroits et le cachez à d'autres, l'utilisateur aura du mal à comprendre les choses par lui-même.
Je pense que si le contexte est facile à comprendre, désactiver sans donner de raison, c'est bien.
Vous vous souvenez de l'aide de Balloon dans MacOS? Apple nous a encouragés à rédiger des bulles d'aide pour les éléments désactivés depuis 1991 et au-delà. Microsoft ne l'a pas fait.
Pour les scénarios plus complexes, expliquer pourquoi un élément est désactivé et ce que l'utilisateur peut faire pour l'activer est très utile pour comprendre le fonctionnement d'une application.
Les info-bulles, les alertes et les icônes d'information [i] peuvent faire à peu près la même chose: expliquer au bon endroit en quoi consiste l'élément. Je prêcherais: ne manquez pas cette occasion de donner à l'utilisateur plus de renseignements et votre système d'être plus transparent. Faut-il un travail supplémentaire? Oui. Ça vaut le coup? tu décides.