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

Question

C'est une plante vivace de question pour moi que je n'ai jamais vraiment résolu donc je voudrais votre avis. Si j'ai des actions que je connais un utilisateur ne sera pas en mesure d'effectuer en raison de l'insuffisance des privilèges ou de l'état de l'objet, si les éléments de l'INTERFACE utilisateur pour les actions être cachée à l'utilisateur, visible mais désactivé, ou visible et provoque une erreur si la tentative? Quelle serait la justification de votre réponse? Si elle est désactivée, voulez-vous communiquer la raison et, si oui, comment?

C'est une interface web, donc je sais déjà que j'ai besoin de vérifier les entrants post/get pour les autorisations et la gestion des erreurs de toute façon. Je fais d'abord parler de la façon de gérer l'INTERFACE utilisateur.

Ceci est similaire à http://stackoverflow.com/questions/79033/rules-about-disabling-or-hiding-menu-items, si je suis intéressé par tous les types d'éléments de l'INTERFACE utilisateur et pas seulement les menus.

Exemples:

1. J'ai une Nouvelle page qui permet à un utilisateur pour créer un nouvel Événement. Les événements peuvent être le maître des événements ou des événements. La création d'un master de l'événement exige "EditMasterEvent" privilège, tout en créant un subevent exige seulement "EditEvent" privilège. J'ai une liste déroulante qui permet de choisir un événement existant en tant que parent (master) ou aucun parent (c'est un maître de l'événement). Si le "Master Événement" les choix être indiqué sur la liste déroulante ou omis si l'utilisateur n'a "EditEvent" privilèges.

2. Suppression d'événements exige que vous soyez un administrateur de l'application ou disposer de l'autorisation de modification pour le type d'événement. Dans ce dernier cas, l'événement doit également être de plus de 5 ans. Suppression d'un événement causes d'importantes suppressions en cascade de donné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. Depuis cette opération est rare pour l'utilisateur normal, le cas typique, c'est que l'action n'est pas disponible. Devrait-il être montré toujours ou uniquement lorsqu'il réellement possible?

Answer 1

Caché - C'est la meilleure approche pour les actions qui ne sont jamais disponibles pour l'utilisateur actuel. Il n'y a aucun point en ayant à l'utilisateur des déchets de l'effort mental à comprendre pourquoi quelque chose est désactivé si aucune action n'est qu'ils peuvent faire pour changer cette situation.

Disabled (désactivé) - C'est la meilleure approche pour des actions qui sont parfois disponibles, mais pas à ce moment ou dans le contexte actuel. Une option désactivée doivent faire part de deux choses: tout d'abord, l'action n'est pas disponible en ce moment, et deuxièmement, il y a quelque chose que l'utilisateur pourrait faire pour rendre l'action plus disponible (changement de certains paramètres ou de l'autorisation, sélectionnez un élément, saisissez préalable des données, etc.). Si vous pouvez indiquer ce qui doit être fait pour permettre à l'action dans une info-bulle - tout le meilleur. Activation/désactivation des actions que l'utilisateur entre des données ou des changements de contexte fournit d'excellents commentaires au sujet de ce que le programme nécessite.

Échouer avec une Erreur - C'est le pire des choix. Vous ne devez recourir à un rapport d'erreurs pour les opérations qui pourraient travailler: vous ne pouvez pas dire que ce sera un échec, sauf en essayant.

Answer 2

Comme avec presque tous les UI des questions, la réponse est "ça dépend".

Vous avez besoin de peser l'identification de la satisfaction de l'utilisateur, entre autres choses. Par exemple, en permettant une action invalide vous donne l'occasion d'expliquer pourquoi quelque chose n'est pas valide. Ceci est particulièrement utile si la réponse à "pourquoi est-ce handicapés" n'est pas évidente. Pour une application où la plupart des utilisateurs sont des débutants, c'est important.

D'autre part, il peut être puissamment frustrant de voir un contrôle, cliquez sur, seulement pour être récompensé par un "désolé, vous ne pouvez pas le faire maintenant" message. Une application que j'ai hérité d'un couple d'années en arrière, était en proie à ce genre de choses et il fait de l'aide de l'INTERFACE utilisateur d'un exercice de frustration.

Masquant complètement la fonctionnalité est probablement rarement une bonne idée. Imaginez savoir certaines fonctionnalités "était là il y a une minute", mais maintenant il est parti. Si c'est un élément de menu ou un bouton de barre d'outils ou tout autre chose, le rendant cachés peuvent être un exercice de frustration pour l'utilisateur final.

Essayez de faire un peu de tests d'utilisabilité, si seulement en demandant à la personne à côté de vous voir "hey, est-il judicieux de désactiver cette ou de vous montrer un dialogue informatif". Juste une autre opinion est souvent suffisante pour vous permettre de regarder le problème d'une autre direction.

Bottom line: faire ce qui sert au mieux l'utilisateur. Tous les scénarios que vous mentionnez sont valables dans certaines circonstances. Comme avec tous les UI des questions, posez-vous (ou mieux, vos utilisateurs) ce qui sert le mieux leurs besoins.

Answer 3

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 pour le moment.

Answer 4

Il dépend. Voulez-vous que l'utilisateur soit conscient que l'action est possible, tout simplement pas pour eux? Dans ce cas, montrez-leur le bouton, mais le désactiver. Un exemple pourrait être: si un utilisateur ne dispose pas de supprimer l'autorité, mais les autres utilisateurs à faire, ils doivent savoir que les entrées PEUVENT être supprimées, de sorte qu'ils peuvent demander à quelqu'un de le faire pour eux si ils ont besoin de l'action.

D'autre part, si l'utilisateur n'est pas censé bien connaître l'action (par exemple, un utilisateur qui ne dispose pas d'un accès en lecture à des journaux d'audit ne devrait probablement pas savoir que ces journaux existent) ne devrait pas être en mesure de voir le bouton, afin de masquer complètement.

Answer 5

Excellente question!

Quelques considérations:

Si vous placez les éléments sur la page, mais les désactiver, il y a encore peu de chance que l'utilisateur pourrait médecin le système et de les activer à l'aide d'un javascriptlet.

Si vous ne vous présentez pas à eux, à tous, la fonctionnalité de l'ensemble peut être un peu déroutant pour l'utilisateur général. "Ne devrait-il pas être un bouton éditer ici?"

Si vous allez de l'affichage et de désactiver ou d'afficher et de vérifier les éléments, j'ai serait certainement faire une validation côté serveur. Ne laissez pas la validation dans les mains de JavaScript; je pense que les raisons sont évidentes.