Dois-je avoir un bouton désactivé ou aucun bouton du tout, si l'utilisateur n'a pas les privilèges suffisants pour l'action?
Je voudrais savoir si un bouton désactivé est préférable à aucun bouton pour une certaine interface utilisateur.
Fondamentalement, les utilisateurs réguliers (expérimentés) peuvent soit commenter un problème, soit le fermer; les utilisateurs à accès restreint (comme les développeurs inexpérimentés) ne peuvent que commenter le problème.
Dans ce cas, il n'y a aucun moyen de modifier la restriction d'accès directement dans l'application, car elle récupère les informations d'un service distinct. Et il est très peu probable que l'utilisateur restreint se verra accorder l'accès à l'action en le demandant simplement.
Vaut-il la peine d'afficher un bouton désactivé même si l'utilisateur ne peut pas appuyer dessus ou faire quoi que ce soit pour l'activer, ou est-il plus gentil de sa part de ne pas afficher du tout le bouton "Fermer"?
PS Il y a aussi une chance qu'ils utilisent l'application avec une autre équipe où ils ont un accès à l'action "Fermer". Dans ce cas, je crains que le fait de cacher complètement le bouton quand ils n'ont pas de droits pourrait les embrouiller lorsqu'ils naviguent d'une équipe à l'autre.
Je suggère d'afficher le bouton dans son état désactivé et d'ajouter une info-bulle expliquant pourquoi il est désactivé et comment les utilisateurs peuvent obtenir les autorisations pour utiliser cette action.
N'affiche pas le bouton:
Les utilisateurs rechercheront cette option et penseront peut-être qu'ils ne la voient pas et peuvent donc passer du temps à la rechercher, éventuellement à actualiser la page, à redémarrer le navigateur, etc.
Affichage du bouton dans son état désactivé et expliquant pourquoi il est désactivé:
"Oh, je n'ai pas d'autorisations, mais maintenant je sais comment les obtenir ou à qui parler."
D'après votre description, je pense que la réponse est assez claire. Je reçois vos préoccupations concernant les attentes de certains utilisateurs, mais ce bouton ne doit pas être affiché pour plusieurs raisons.
n bouton désactivé ne générera qu'une charge cognitive négative pour tout le monde.
Les utilisateurs regarderont le bouton et réfléchiront à ce qu'il fait, comment il est désactivé et comment l'activer. Vous dites que les utilisateurs ne peuvent pas l'activer, ce sera donc une question à laquelle ils ne pourront pas répondre ou sera négative.
Ce n'est pas un bouton désactivé car il ne peut pas être activé.
Un bouton désactivé indique aux utilisateurs qu'il existe une action qu'ils peuvent entreprendre pour l'activer. D'après votre description, ce bouton ne peut pas être activé. Ne montrez pas aux utilisateurs un bouton qui ne peut pas être utilisé ou activé pour être utilisé.
C'est une mauvaise façon de communiquer
Les choses que vous souhaitez essayer de communiquer via ce bouton désactivé doivent simplement être communiquées en texte brut ou via l'interface utilisateur. S'il existe différents niveaux de contrôle, montrez-le aux utilisateurs et indiquez-leur à quel niveau ils se trouvent.
L'utilisateur est-il susceptible d'être au courant des fonctionnalités? Un utilisateur inexpérimenté peut-il acquérir de l'expérience et obtenir ensuite le privilège de proximité?
Si oui, cachez le bouton.
Un bouton est un élément extrêmement interactif d'une page. Considérez ces exemples-
Dans Facebook, si vous ouvrez une publication dans laquelle vous ne pouvez que partager, l'option J'aime et les commentaires ne s'affichent pas du tout. Même si l'on peut envoyer une demande d'ami et ensuite aimer le message (une fois la demande acceptée).
Dans StackOverflow, si je n'ai pas encore le privilège de commentaire, aucune option de commentaire n'est présente.
Un bouton désactivé fonctionne bien pour les entrées vides, c'est-à-dire que jusqu'à ce que vous n'ayez pas écrit suffisamment de contenu, le bouton est désactivé. Ou le bouton de connexion est désactivé jusqu'à ce que le captcha soit rempli. Ou même pour les réunions, un bouton pour rejoindre doit être affiché, mais désactivé jusqu'à avant 15 minutes. Ici, l'utilisateur peut venir à l'heure indiquée pour rejoindre la réunion.
Autrement dit, afficher un bouton désactivé signifie qu'il devrait y avoir un moyen de l'activer. C'est ainsi que moi, ou quiconque, les attend. n bouton désactivé en raison de privilèges ne doit pas être affiché, car l'utilisateur ne peut rien faire pour l'activer.
Dans tous les exemples, l'utilisateur s'attend à ce que le bouton soit activé après bien défini heure ou action spécifiée. Dans votre cas, l'utilisateur ne semble pas avoir d'action bien définie pour activer le bouton.
Vous pouvez afficher le texte sous la forme "Vous n'avez pas encore de privilège de fermeture". Cela satisfait la curiosité de l'utilisateur, sans le motiver à essayer quelque chose sur lequel il n'a aucun contrôle, c'est-à-dire obtenir des privilèges.
Une raison massive pour désactiver (avec explication) le bouton plutôt que de le cacher qui n'a pas été mentionné explicitement est qu'un utilisateur expérimenté finira par utiliser un compte d'utilisateur inexpérimenté à ses côtés.
J'ai généralement un problème similaire avec un produit que nous utilisons en interne qui cache un bouton d'administration lorsqu'il est utilisé par des personnes avec des privilèges inférieurs. Lorsque je forme le nouvel utilisateur ou que je l'aide à accomplir ses tâches, je suis assis avec lui à son bureau à l'aide de son compte et je ne trouve pas le bouton pour faire ce dont j'ai besoin. Le fait d'avoir le bouton là-bas mais désactivé me rappellerait que j'utilise le compte de quelqu'un d'autre qui n'a pas accès à l'action que je veux terminer, je dois donc me connecter en tant que mon propre utilisateur pour résoudre leur problème.
Vous pourriez dire que c'est un cas plutôt Edge mais comme les gens sont intégrés et ont besoin de formation et de résolution de problèmes par des utilisateurs plus expérimentés, les problèmes vont s'intensifier. Il peut sembler que l'utilisateur expérimenté devrait savoir que les autorisations sont le problème, mais c'est une très bonne idée de le lui rappeler!
Le principal moteur devrait être l'attente des utilisateurs.
Si le bouton concerne une fonctionnalité qu'un utilisateur peut s'attendre à avoir, il doit y être et l'état désactivé indique clairement qu'il n'est pas disponible (une info-bulle de survol peut expliquer pourquoi).
Si, cependant, c'est une fonctionnalité que l'utilisateur avec les droits d'accès réduits ne s'attendrait pas à avoir ou à voir (ou peut-être même ne réalise pas qu'il existe), elle devrait être cachée.
Dans les deux cas, vous faites un compromis.
L'affichage du bouton désactivé indique clairement que la fonctionnalité existe, mais est désactivée, mais pourrait confondre l'utilisateur qui se demande pourquoi vous lui montrez quelque chose qu'il ne peut pas faire - et dans le cas des autorisations, il est peu probable qu'il puisse jamais à faire, contrairement à quelque chose qui n'est indisponible que pour des raisons temporaires, comme, par exemple, un bouton "suivant" qui devient activé une fois que la page actuelle de l'assistant a été remplie. Un autre avantage du masquage est que la mise en page de la page est la même pour tout le monde, aidant la mémoire musculaire pour les personnes qui pourraient basculer entre différents comptes ou autorisations, s'il existe une telle chose dans votre application. Il permet également aux pages de documentation ou d'aide de faire référence aux boutons par leur position, car la position est invariante.
Masquer le bouton maintient l'interface propre et utile, ne montrant que ce qui est réellement disponible. Cela empêche "pourquoi ils le montrent?" et "que ferait-il?" demander par l'utilisateur. Cependant, s'il s'agit d'une fonctionnalité qu'un utilisateur peut exclure, il la remplace par un autre type de "où est-ce?" me demande.
StackExchange affiche des boutons même lorsque l'utilisateur ne peut pas effectuer cette action et affiche un conseil si l'utilisateur n'a pas le privilège de l'utiliser. Dans ce cas, le bouton n'est ni désactivé ni masqué. Il y a cependant une motivation pour les utilisateurs de SE à gagner en réputation et à activer les boutons, il est donc logique de suspendre un prix "c'est ce que vous pourriez gagner" devant eux, puis de leur dire ce qu'ils doivent faire pour l'obtenir. Je suppose que vous devez décider si un tel comportement vous convient.
En outre, ce bouton peut peut-être être utilisé différemment selon les autorisations, de sorte qu'il est toujours utilisable. Les utilisateurs restreints peuvent uniquement [Fermer]. Les utilisateurs avancés peuvent [Enregistrer et fermer] ..
Généralement, il est bon d'afficher un bouton désactivé pour permettre à l'utilisateur de s'habituer à l'interface, de savoir qu'il peut effectuer cette action, etc.
L'exception à cela serait si l'utilisateur ne pourra jamais utiliser ce bouton, si c'est le cas, il suffit de le cacher complètement.
Cela dépend de ce que vous entendez exactement par "demander simplement". "Enquêter" pourrait signifier demander un privilège pour exécuter unilatéralement une classe d'action donnée, ou cela pourrait signifier demander à un utilisateur senior d'effectuer une seule action au nom de l'utilisateur. Si demander une action est logique pour votre application, un bouton pour demander une action pourrait remplacer le bouton pour l'exécuter.
Stack Exchange a plusieurs flux de demande et d'examen. Il s'agit notamment de signaler, de voter pour fermer les questions et de voter pour supprimer les réponses. Pour un exemple concret rapide, regardez les modifications suggérées. Seuls les utilisateurs avec 2000 ou plus de réputation peuvent modifier les questions ou réponses des autres utilisateurs =. Mais sur les sites principaux et Meta Stack Exchange (pas les métas enfants), les utilisateurs peuvent proposer des révisions qui sont examinées par d'autres utilisateurs expérimentés. Le formulaire de suggestion de modification ressemble au formulaire de modification ordinaire, avec la remarque suivante en haut:
Votre modification sera placée dans une file d'attente jusqu'à ce qu'elle soit évaluée par des pairs.
Nous nous félicitons de toutes les modifications constructives, mais veuillez les rendre substantielles. Évitez les modifications triviales, sauf si cela est absolument nécessaire.
Une fois qu'un utilisateur a soumis une suggestion, l'avis suivant apparaît à côté de la suggestion:
Merci pour votre modification!
Cette modification ne sera visible que par vous jusqu'à ce qu'elle soit revue par les pairs .
Le propriétaire de la publication peut alors accepter ou rejeter la modification, ou d'autres utilisateurs disposant du privilège de modification peuvent voter pour accepter ou rejeter la modification.