Les actions non autorisées dans l’interface utilisateur doivent-elles être masquées, désactivées ou entraîner une erreur?

C’est une question perpétuelle pour moi que je n’ai jamais vraiment résolue, alors j’aimerais avoir votre avis. Si j’ai des actions dont je sais qu’un utilisateur ne pourra pas effectuer en raison de privilèges insuffisants ou d’un état d’object, les éléments d’interface utilisateur de ces actions doivent-ils être masqués, visibles mais désactivés ou visibles et entraîner une erreur s’ils sont tentés? Quelle serait la raison de votre réponse? Si désactivé, communiqueriez-vous la raison pour laquelle et, si oui, comment?

Ceci est une interface Web, donc je sais déjà que je dois vérifier les messages entrants / obtenir des permissions et gérer les erreurs de toute façon. Je parle principalement de la façon de gérer l’interface utilisateur.

Ceci est similaire aux règles concernant la désactivation ou le masquage des éléments de menu , bien que je sois intéressé par tous les types d’éléments d’interface utilisateur, pas seulement les menus.

Exemples:

  1. J’ai une nouvelle page qui permet à un utilisateur de créer un nouvel événement. Les événements peuvent être des événements principaux ou des sous-événements. La création d’un événement maître nécessite le privilège “EditMasterEvent”, alors que la création d’un sous-événement ne requirejs que le privilège “EditEvent”. J’ai un menu déroulant qui permet de choisir un événement existant en tant que parent (événement principal) ou aucun parent (il s’agit d’un événement principal). Si le choix “Créer un événement principal” apparaît dans la liste déroulante ou est omis si l’utilisateur ne dispose que des privilèges “EditEvent”.

  2. La suppression d’événements nécessite que vous soyez un administrateur d’application ou que vous ayez l’autorisation de modification appropriée pour le type d’événement. Dans ce dernier cas, l’événement doit également avoir plus de 5 ans. La suppression d’un événement entraîne d’importantes suppressions en cascade de données associées dans le système et, pour des raisons juridiques, ces données doivent être conservées pendant au moins 5 ans après l’événement. Comme cette opération est rare pour l’utilisateur normal, le cas typique est que l’action n’est pas disponible. Doit-il être montré toujours ou seulement quand c’est possible?

    Comme pour presque toutes les questions sur l’interface utilisateur, la réponse est “ça dépend”.

    Vous devez, entre autres choses, évaluer la capacité de découverte avec la satisfaction des utilisateurs. Par exemple, autoriser une action non valide vous permet d’expliquer pourquoi quelque chose est invalide. Ceci est particulièrement utile si la réponse à “pourquoi est-ce désactivé” n’est pas évidente. Pour une application où la plupart des utilisateurs sont débutants, c’est important.

    D’un autre côté, il peut être extrêmement frustrant de voir un contrôle, cliquez dessus, pour être récompensé par un message “désolé, vous ne pouvez pas le faire maintenant”. Une application dont j’ai hérité il y a quelques années était pleine de ce genre de choses et elle a rendu frustrante l’utilisation de l’interface utilisateur.

    Cacher complètement la fonctionnalité est probablement rarement une bonne idée. Imaginez que vous connaissiez une fonctionnalité “était là il y a une minute” mais maintenant elle est partie. Que ce soit un élément de menu ou un bouton de barre d’outils ou autre chose, le fait de le cacher peut être un exercice de frustration pour l’utilisateur final.

    Essayez de faire un petit test de convivialité, ne serait-ce qu’en demandant à la personne suivante que vous voyez “hey, est-il judicieux de la désactiver ou de vous montrer un dialog informatif”. Juste une autre opinion suffit souvent à vous amener à regarder le problème dans une autre direction.

    Bottom line: faire ce qui sert le mieux l’utilisateur. Tous les scénarios que vous mentionnez sont valables dans certaines circonstances. Comme pour toutes les questions sur l’interface utilisateur, demandez-vous (ou mieux, vos utilisateurs) ce qui répond le mieux à leurs besoins.

    Caché – C’est la meilleure approche pour les actions qui ne sont jamais disponibles pour l’utilisateur actuel. Il ne sert à rien que l’utilisateur gaspille son effort mental pour comprendre pourquoi quelque chose est désactivé si aucune mesure ne peut être prise pour y remédier.

    Désactivé – C’est la meilleure approche pour les actions qui sont parfois disponibles, mais pas pour le moment ou dans le contexte actuel. Une option désactivée devrait transmettre deux choses: premièrement, l’action n’est pas disponible pour l’instant, et deuxièmement, l’utilisateur peut faire quelque chose pour modifier l’action (modifier un paramètre ou une autorisation, sélectionner un élément, saisir des données préalables, etc. ). Si vous pouvez indiquer ce qui doit être fait pour activer l’action dans une info-bulle, tant mieux. L’activation / la désactivation des actions lorsque l’utilisateur saisit des données ou modifie le contexte fournit une excellente rétroaction sur les besoins du programme.

    Échec avec une erreur – C’est le pire choix. Vous ne devez recourir à un rapport d’erreur que pour les opérations susceptibles de fonctionner: vous ne pouvez pas dire que cela échouera, sauf en essayant.

    Je désactive les éléments au lieu de les cacher. De cette façon, l’utilisateur sait que l’option serait normalement disponible et je fournis une info-bulle pour expliquer pourquoi l’élément n’est pas disponible actuellement.

    Ça dépend. Voulez-vous que l’utilisateur sache que l’action est possible, mais pas pour eux? Dans ce cas, montrez-leur le bouton, mais désactivez-le. Par exemple, si un utilisateur ne dispose pas d’une autorisation de suppression, mais que d’autres utilisateurs le font, ils doivent savoir que les entrées peuvent être supprimées et demander à quelqu’un de le faire si elles ont besoin de l’action.

    D’un autre côté, si l’utilisateur n’est pas censé connaître l’action (par exemple, un utilisateur n’ayant pas access en lecture aux journaux d’audit ne devrait probablement pas savoir que ces journaux existent) ne devrait pas pouvoir voir le bouton , alors cachez-le complètement.

    Bonne question!

    Quelques considérations:

    Si vous placez les éléments sur la page mais que vous les désactivez, il y a toujours une chance pour que l’utilisateur puisse gérer le système et les activer avec un JavaScriptletlet.

    Si vous ne les montrez pas du tout, la fonctionnalité globale peut être un peu déroutante pour l’utilisateur général. “Ne devrait-il pas y avoir un bouton d’édition ici?”

    Si vous souhaitez afficher, désactiver ou afficher et vérifier les éléments, je ferais certainement la validation côté serveur. Ne laissez pas la validation entre les mains de JavaScript; Je pense que les raisons en sont évidentes.

    J’ai tendance à gérer différemment les deux types de situations. Est-ce une action qui est régie par des privilèges et par l’état de l’object.

    Si la personne n’a pas assez de privilèges pour faire une action, je cache l’option, elle ne sait pas qu’elle peut effectuer l’action.

    Si l’option n’est pas disponible car l’object n’est pas dans un état pouvant utiliser cette option, je le désactive, permettant à l’utilisateur d’être visible pour cette option, mais aucune action ne peut être effectuée.

    De vos exemples:

    1. Je n’aurais pas l’option “Créer un événement maître” en option. L’utilisateur n’a pas les privilèges suffisants pour l’afficher.

    2. J’aurais le bouton Supprimer visible pour les administrateurs. Ensuite, selon la manière dont vous faites le rest du site (beaucoup de texte visible, des info-bulles, une icône d’aide, etc.), je suivrais cette convention pour informer l’utilisateur de la raison pour laquelle le bouton n’est pas utilisable pour le moment. Et éventuellement mettre une timer au-dessus, près du bouton avec quel âge est le message ou combien de temps il peut être supprimé.

    Selon l’élément, nous les cacherons ou les désactiverons. Si l’utilisateur a access à une grande fonctionnalité, mais pas à une plus petite pièce, nous cacherons la plus petite pièce. Cependant, si l’utilisateur a access à plusieurs fonctionnalités importantes, mais pas à d’autres, nous les laisserons visibles mais désactivées en tant que stratagème marketing pour leur rappeler que les fonctionnalités sont disponibles à l’achat si elles le souhaitent.

    J’ai également vu des programmes qui désactivent l’élément de menu et en modifient le texte en “Se connecter pour faire bla …”

    J’aime ça parce que ça ne me laisse pas “pourquoi ça ne marche pas?” sentiment et me dit immédiatement quoi faire pour le faire fonctionner. Non applicable dans tous les cas, mais c’est une bonne approche si vous pouvez l’implémenter.

    La règle générale est l’utilisation de désactivation si l’utilisateur peut faire quelque chose dans l’interface utilisateur pour obtenir le privilège. Désactivé signifie «vous pouvez faire cette commande, mais pas maintenant, comme c’est le cas». La «manière dont les choses sont» inclut la sélection actuelle, donc utilisez / désactive si l’utilisateur a le privilège EditEvent pour les anciens objects objects. Il devrait y avoir une indication claire des objects pouvant être supprimés afin que les utilisateurs comprennent pourquoi les commandes associées sont désactivées pour certains objects (par exemple, si les utilisateurs savent généralement que les enregistrements doivent être conservés pendant 5 ans, un simple champ Age peut être suffisant avec une différence graphique pour les enregistrements de plus de 5 ans).

    Utilisez des boîtes de message au lieu de désactiver si vous ne parvenez pas à expliquer la raison de la désactivation à l’utilisateur, en supposant qu’il possède une connaissance moyenne du domaine. Les info-bulles pour les contrôles désactivés, BTW, sont une excellente idée, mais peuvent ne pas suffire à eux seuls.

    Se cacher si l’utilisateur n’a jamais le privilège, peu importe ce qu’il fait dans l’interface utilisateur, compte tenu de sa position actuelle dans l’organisation (par exemple, il n’est pas administrateur d’application). Il est encombrant et frustrant d’utiliser des boîtes de message ou de désactivation pour ce cas. En ce qui concerne les utilisateurs, les actions pour lesquelles ils n’ont pas le privilège ne sont pas leur travail (sinon ils auraient le privilège), et les contrôles associés ne devraient donc tout simplement pas exister dans leur interface utilisateur. Les manuels de procédure de documentation ou d’organisation peuvent indiquer aux utilisateurs comment de telles actions sont accomplies (par exemple, «Votre superviseur crée de nouveaux événements pour vous»).

    J’ai plus de détails sur http://www.zuschlogin.com/?p=40 .

    Je dirais désactiver avec un vol stationnaire contenant la raison.

    Cela évite à l’utilisateur de se demander ce qui se passe, tout en lui faisant savoir que certaines actions sont possibles dans les bonnes conditions.

    J’ai une haine particulière des applications qui désactivent les boutons. Si vous êtes un utilisateur final, vous voulez savoir pourquoi vous ne pouvez pas utiliser ce bouton. Le faire griser ne vous dit rien. Comment obtenez-vous l’état pour l’activer? Les infobulles sont une solution, mais elles ne sont pas les meilleures, de nombreux utilisateurs auront des difficultés avec les info-bulles (sauf si vous travaillez avec des utilisateurs expérimentés).

    Mon sentiment personnel est que les éléments doivent toujours être présents. Si l’utilisateur ne dispose pas des permissions suffisantes pour les exécuter, il doit générer une erreur lorsque l’utilisateur clique dessus.

    Je sais que les traducteurs n’apprécient pas vraiment la création d’un million de messages d’erreur différents, ce qui n’est souvent pas le cas dans les applications localisées qui ont tendance à masquer les éléments.

    En pratique, de nombreuses personnes ont tendance à cacher les options, même dans les applications non localisées.

    D’autres personnes ont fourni de bonnes réponses avec des suggestions valables pour éviter de cacher des éléments, mais plutôt les désactiver et fournir des conseils pour les raisons.

    Donc, j’aimerais voir les choses sous un angle différent – mais comment masquer certains éléments de l’interface dans les cas où l’utilisateur n’a pas besoin de les voir, peu importe s’il possède ou n’a pas d’permissions pour des actions spécifiques liées aux éléments?

    Par exemple, disons, les utilisateurs de certains rôles ont access aux enregistrements des vendeurs dans le système.

    Mais alors, l’analyste commercial dit: “Regardez, il ya une liste déroulante avec la liste des vendeurs sous cette forme et nous ne devrions pas autoriser certains rôles spécifiques à la voir”.

    Le développeur demande: “Alors, nous supprimons simplement la permission” Lire les vendeurs “de ce rôle, non?” Mais l’analyste répond: “Non! Ce rôle devrait toujours être capable de voir les vendeurs sur la page Vendeurs. C’est juste ce formulaire unique où nous devrions cacher la liste pour certains rôles et la montrer à d’autres rôles.”

    Ainsi, le développeur ajoute la permission appelée “Afficher la liste déroulante des vendeurs sur le formulaire X”.

    Oups, maintenant nous avons un problème. L’access aux mêmes données est contrôlé par deux permissions distinctes. Maintenant, nous devons trouver comment combiner les deux. Et s’il y a plus d’une forme où la liste du vendeur devrait être cachée pour certains rôles? Comment pouvons-nous le combiner avec “Lire la liste du vendeur”? Pour nous, développeurs, il est assez clair que l’autorisation “Lire” devrait avoir une priorité supérieure à “Afficher”, donc même si un utilisateur peut “Voir” une liste, il ne devrait toujours pas le voir (ou voir vide ou désactivé avec une aide utile). indice) s’il ne dispose pas de l’autorisation “Lire”. Nous, développeurs et analystes du système, le soaps. Mais comment l’administrateur du système devrait-il le savoir? Devrions-nous lui apprendre cela? Comment pouvons-nous garantir que l’administrateur ne confondra pas tous ces “Affichage” et “Lecture” pour la liste de données unique?

    Comme vous le voyez, tout devient désordonné pour une raison: nous combinons des permissions de traitement de données avec des fonctionnalités d’interface utilisateur dans la liste des permissions de rôle.

    J’ai vu beaucoup de projets où il y a du désordre parce que les permissions du côté serveur sont trop couplées à l’interface utilisateur, ce qui demande des problèmes et des trous de sécurité possibles (car vous disposez de plusieurs éléments pour les mêmes actions sur les mêmes données) .

    Les permissions concernent l’access et les opérations sur certaines données spécifiques. L’interface utilisateur ne peut réagir aux permissions que de manière cohérente dans tout le système (désactivation avec des astuces, masquage, etc.). Nous ne devrions jamais inventer de nouvelles entrées d’autorisation uniquement à des fins d’interface utilisateur.

    Maintenant, la question demeure – mais comment pouvons-nous réellement masquer des éléments d’interface utilisateur pour certains utilisateurs du système afin d’éviter de les submerger par une quantité considérable d’éléments toujours désactivés? Une solution pourrait être des espaces de travail de rôle. Si nous soaps clairement que les utilisateurs d’un certain rôle n’auront jamais besoin d’accéder à certaines données spécifiques, nous créons un ensemble d’entrées de contrôle d’interface utilisateur, similaire aux permissions, mais cette fois, nous ne les appelons pas. Et nous pouvons vraiment avoir envie ici, même en permettant aux utilisateurs de personnaliser librement leur espace de travail et de choisir ce qu’ils peuvent ou ne peuvent pas voir. Bien entendu, les permissions prendront toujours la priorité la plus élevée, mais elles n’affecteront que les données et l’état des éléments de l’interface utilisateur et non la visibilité.

    C’est mes deux cents. Malheureusement, je n’ai moi-même pas travaillé sur un tel système où les options d’espace de travail sur les permissions et l’interface utilisateur sont clairement séparées, car je suis toujours arrivé trop tard à un projet lorsque les “dégâts ont été causés”. Mais j’espère qu’un jour j’aurai une chance. J’espère juste trouver un bon exemple pour bien faire les choses, mais d’une manière ou d’une autre, les recherches sur Internet ne me donnent rien d’utile. Est-ce que cela signifie vraiment que personne d’autre n’est parvenu aux mêmes conclusions que moi? Je ne le crois pas, quelqu’un dans le monde des modèles de conception d’entreprise aurait dû remarquer cette incompatibilité entre les droits d’access UI <-> depuis longtemps.