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

Caché - C'est la meilleure approche pour les actions qui ne sont jamais disponibles pour l'utilisateur actuel. Cela ne sert à rien de gaspiller l'effort mental de l'utilisateur à comprendre pourquoi quelque chose est désactivé s'il n'y a aucune action qu'ils peuvent prendre pour changer cela.

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 devrait transmettre deux choses: d'abord, l'action n'est pas disponible maintenant, et deuxièmement, il y a quelque chose que l'utilisateur pourrait faire pour rendre l'action disponible (modifier un paramètre ou une permission, sélectionner un élément, entrer des données préalables, etc.).). Si vous pouvez indiquer ce qui doit être fait pour activer l'action dans un tooltip - d'autant mieux. Actions habilitantes / désactivantes au fur et à mesure que l'utilisateur entre les données ou change le contexte fournit une excellente rétroaction sur ce que le programme exige.

Échouer avec une Erreur - C'est le pire des choix. Vous ne devez recourir à un rapport d'erreur pour les opérations qui pourraient fonctionner: vous ne pouvez pas dire qu'il échouera sauf en essayant.

j'ai désactivé 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 infobulle pour expliquer pourquoi l'élément n'est pas disponible actuellement.

ça 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 n'a pas le pouvoir de supprimer, mais d'autres utilisateurs le font, ils devraient savoir que les entrées peuvent être supprimées, afin qu'ils puissent demander à quelqu'un de le faire pour eux s'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 lire l'accès aux journaux d'audit ne devrait probablement pas savoir que ces journaux existent) ne devrait pas pouvoir voir le bouton, donc le cacher complètement.

grande question!

quelques considérations:

si vous placez les éléments sur la page mais les désactivez, il y a encore une chance que l'utilisateur puisse modifier le système et les activer en utilisant un javascriptlet.

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 allez à soit display et désactiver soit display et vérifier les éléments, Je certainement faire 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 les deux types de situations différemment. S'agit-il d'une action régie par le privilège et par l'état de l'objet?

Si la personne n'a pas suffisamment de privilèges pour faire une action, je me cache de l'option, ils ne savent pas qu'ils peuvent effectuer l'action.

Si l'option n'est pas disponible parce que l'objet n'est pas dans un état qui peut utiliser cette option, je le désactiver, laissant la possibilité d'être visible pour l'utilisateur, mais aucune action ne peut être fait.

de vos exemples:

1. Je n'aurais pas "Create Master Event" comme option. L'utilisateur n'a pas les privilèges suffisants pour le visualiser.

2. j'aurais le bouton Supprimer visible aux administrateurs. Ensuite, en fonction de la façon dont vous faites le reste du site (beaucoup de texte visible, infobulles, icône d'aide, etc) je suivrais cette convention sur l'information l'utilisateur pourquoi le bouton n'est pas utilisable en ce moment. Et peut-être mettre une minuterie, ci-dessus, près du bouton avec soit l'âge du post est ou combien de temps jusqu'à ce qu'il puisse être supprimé.

selon l'objet, nous les cacherons ou les désactiverons. Si l'utilisateur a accès à une grande fonctionnalité, mais pas à un morceau plus petit à l'intérieur, alors nous cacher la plus petite pièce. Toutefois, si l'utilisateur a accès à plusieurs grandes entités, mais pas pour les autres, nous allons les laisser visibles mais désactivé comme un stratagème de marketing pour leur rappeler que les fonctionnalités sont disponibles à l'achat s'ils décident qu'ils veulent.

j'ai également vu certains programmes qui désactivent l'élément de menu et de changer le texte de celui-ci à" se connecter pour faire bla..."

j'aime ça parce que ça ne me laisse pas avec le "pourquoi ça ne marche pas?"le sentiment et me dit immédiatement que faire pour qu'il fonctionne. Pas applicable dans tous les cas, mais c'est une bonne approche si vous pouvez la mettre en œuvre.

La règle générale est d'utiliser la désactivation si l'utilisateur peut faire quelque chose dans l'INTERFACE utilisateur pour obtenir le privilège. Disabled signifie " Vous pouvez faire cette commande, mais pas maintenant comme les choses sont."Les "choses" comprend la sélection en cours, afin d'utiliser l'activation/la désactivation si l'utilisateur a le EditEvent privilège pour les vieux objets, mais pas pour les nouveaux objets. Il doit y avoir une indication claire des objets pouvant être supprimés pour que les utilisateurs comprennent pourquoi les commandes associées sont désactivées pour certains objets. (par exemple, si les utilisateurs savent généralement que les documents doivent être conservés pendant cinq ans, un simple champ D'âge peut être suffisant, peut-être renforcé par une différence graphique pour les documents de plus de cinq ans).

utilisez des boîtes de messages au lieu de désactiver s'il n'y a aucun moyen de rendre la raison de la désactivation claire pour l'utilisateur en supposant qu'ils ont une connaissance moyenne du domaine. Les info-bulles pour les personnes handicapées de contrôles, d'ailleurs, sont une excellente idée, mais peut-être pas suffisamment par eux-mêmes.

utilisez se cacher si l'utilisateur n'a jamais le privilège peu importe ce qu'il fait dans L'UI étant donné sa position actuelle dans l'organisation (par exemple, ils ne sont pas un 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 donc les contrôles associés ne devraient tout simplement pas exister dans leur UI. De la Documentation ou de les manuels de procédures de l'organisation peuvent indiquer aux utilisateurs comment ces mesures sont prises (p. ex., "votre superviseur crée de nouveaux événements pour vous.").

j'ai plus de détails à http://www.zuschlogin.com/?p=40 .

je dirais désactivé avec un vol stationnaire contenant la raison.

il empêche l'utilisateur de se demander ce qui se passe, tout en leur 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. Avoir grisé n'est pas de vous dire quoi que ce soit. Comment obtenez-vous de l'état pour l'activer? Tooltips sont une solution, mais ils ne sont pas les meilleurs, beaucoup d'utilisateurs auront du mal avec tooltips (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 n'a pas assez de permissions pour les faire, il devrait générer une erreur en cliquant sur.

je sais que les traducteurs n'aiment pas vraiment créer un zillion de messages d'erreur" permission denied " différents, donc cela n'est souvent pas fait dans les applications localisées, qui ont tendance à cacher les éléments à la place.

dans la pratique beaucoup de gens ont tendance à cacher les options au lieu de cela même dans les applications localisées.

D'autres personnes ont fourni de bonnes réponses avec des suggestions valables pour éviter de cacher des éléments et au lieu de les désactiver et de fournir quelques conseils pour les raisons.

donc, je voudrais le regarder d'un point de vue différent - mais comment cacher certains éléments de L'interface utilisateur dans les cas où l'utilisateur n'a pas besoin de les voir, peu importe s'il a ou n'a pas de permissions pour des actions particulières liées aux éléments?

Par exemple, disons, les utilisateurs d'un rôle sont accès aux dossiers des vendeurs dans le système.

mais alors l'analyste d'affaires dit:"Regardez, il y a un dropdown avec la liste des vendeurs dans cette forme et nous ne devrions pas permettre à certains rôles spécifiques pour le voir".

demande le développeur: "donc, nous venons de supprimer la permission de "lire vendeurs" de ce rôle, non?"Mais l'analyste répond: "Non! Ce rôle devrait toujours être en mesure de voir les vendeurs sur la page des vendeurs. C'est juste cette seule forme où nous devrions cacher la liste pour certains rôles et de montrer à certains autres rôles."

ainsi, le développeur ajoute la permission appelée"show sellers dropdown sur le formulaire X".

Oups, on a un problème. L'accès aux mêmes données est contrôlé par deux des autorisations distinctes. Maintenant, nous devons comprendre comment les 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 combiner avec "Lecture du vendeur, la liste"? Pour nous, développeurs, il est assez clair que la permission de "lire" devrait avoir une priorité plus élevée au-dessus de "voir", donc même si un utilisateur peut "voir" une liste, il ne devrait pas la voir (ou voir vide ou désactivé avec un indice utile) s'il n'a pas la permission de "lire". Nous, développeurs et analystes du système le savons. Mais comment l'administrateur du système devrait-il le savoir? Devrions-nous lui enseigner cela? Comment Pouvons-nous garantir que l'administrateur ne confondra pas tous ces "View" et "Read" pour la liste de données unique?

comme vous le voyez, tout est compliqué pour une raison - nous mélangeons les permissions de traitement de données avec les commodités de L'interface utilisateur dans la liste des permissions de rôle.

j'ai vu beaucoup de projets où cela devient confus parce que les permissions côté serveur sont trop couplées à L'UI, qui demande des problèmes et des trous de sécurité possibles (parce que vous avez plusieurs éléments dans votre éditeur de permission de rôle pour les mêmes actions sur les mêmes données).

les Autorisations sont sur l'accès et les opérations sur certaines données spécifiques. L'UI ne peut réagir aux permissions que de manière cohérente dans tout le système (désactivation avec des indices, dissimulation, etc.). Nous ne devrions jamais inventer de nouvelles entrées de permission juste pour les besoins de L'interface utilisateur.

maintenant, la question demeure-mais comment pouvons-nous réellement Cacher les éléments de L'UI pour certains utilisateurs du système pour éviter de les accabler avec une énorme quantité d'articles toujours handicapés? Une solution pourrait être les espaces de travail. Si nous savons clairement que les utilisateurs de certains rôle n'aura jamais besoin d'accéder à certaines données spécifiques, nous créons un ensemble d'entrées de contrôle de L'interface utilisateur, similaire aux permissions, mais cette fois nous ne les appelons pas permissions. Et nous pouvons devenir vraiment fantaisistes ici, même en permettant aux utilisateurs eux-mêmes de personnaliser librement leur espace de travail et de choisir ce qu'ils peuvent ou ne peuvent pas voir. Bien sûr, les permissions prendront toujours la plus haute priorité, mais cela affectera seulement les données et l'état des éléments D'UI et non la visibilité.

c'est mes deux cents. Malheureusement, je n'ai pas moi-même travaillé sur un tel système où les permissions et les options D'espace de travail de L'UI sont soigneusement séparées parce que je viens toujours trop tard à un projet, quand le "dommage a été fait". Mais j'espère qu'un jour j'aurai une chance. J'espère juste trouver un bon exemple pour faire ça bien, mais les recherches sur internet ne me donnent rien d'utile. Est-il vraiment de dire que personne d'autre n'est venu à la même conclusion que moi? Je ne crois pas, quelqu'un dans l'entreprise de conception de pattern world aurait dû remarquer cette inadéquation de l'impédance de permission Il y a longtemps.