Est-il préférable d'empêcher une action interdite ou d'afficher un message d'erreur / d'explication?
Il existe plusieurs exemples, je vais donc en choisir un spécifique pour concentrer la question.
Disons qu'un utilisateur peut avoir des caractéristiques (ou autorisations) spécifiques:
Administrateur, virtuel, externe, financier, etc.
Pour compliquer les choses, les utilisateurs ont également des licences différentes - Premium, Regular, Limited, etc.
Vous pouvez probablement voir où cela va:
Disons qu'un utilisateur avec une licence limitée ne peut pas être administrateur ou avoir des autorisations financières.
Possibilités:
- L'administrateur accède au profil de, disons Zack et voit qu'il ne peut pas lui permettre d'avoir des autorisations financières.
. "aucune autorisation financière pour les utilisateurs limités") - L'administrateur voit toutes les autorisations (supposons implémentées via des cases à cocher) activées et uniquement lorsque vous cliquez sur, un message d'erreur vous informe pourquoi l'opération a été refusée.
Maintenant, la raison est claire, mais l'administrateur a dû "gaspiller" un clic pour le découvrir.
Existe-t-il un moyen à la fois d'empêcher l'action et d'expliquer pourquoi? Un contrôle désactivé avec une info-bulle fonctionnerait-il? De meilleures idées?
Pour mentionner brièvement d'autres exemples - disons que vous avez un graphique interactif et que vous pouvez déplacer la plupart des points sur le graphique, mais certains doivent être fixes. Vous pouvez les dessiner différemment pour indiquer qu'ils ne peuvent pas être déplacés (sans expliquer pourquoi), ou vous pouvez laisser l'utilisateur essayer de les faire glisser, puis afficher un message d'erreur.
Selon l'application, je n'affiche souvent pas les parties de la page auxquelles un utilisateur n'a pas accès. Il semble que vos utilisateurs changent les droits d'autres utilisateurs, donc cette méthode peut ne pas fonctionner. Je recommanderais d'afficher un message d'erreur chaque fois que vous affichez un élément d'entrée désactivé. Les utilisateurs peuvent être frustrés lorsqu'ils ne sont pas en mesure d'effectuer une action qu'ils s'attendent à pouvoir effectuer. S'il est juste désactivé, ils ne comprendront probablement pas pourquoi et le retireront simplement du programme. De même, vous voulez vous assurer que le message est aussi simple que possible et au point. Les longs messages d'erreur sont souvent ignorés.
Avant de masquer complètement une partie de l'interface utilisateur pour une fonctionnalité à laquelle l'utilisateur n'a pas accès, pensez à:
- L'utilisateur sera-t-il informé de cette fonctionnalité?
- Vont-ils passer beaucoup de temps à le chercher?
- Seriez-vous mieux de le garder dans une sorte d'état "désactivé" avec une info-bulle ou un autre indicateur afin qu'ils puissent savoir pourquoi il n'est pas disponible?
Voici un exemple simple. Supposons que votre application inclue l'option d'impression. Lorsqu'aucune imprimante n'est disponible, devez-vous masquer complètement la commande du menu d'impression? Cela causera-t-il de la confusion et une perte de temps lorsque l'utilisateur parcourt tous les menus et contacte finalement votre équipe de support technique pour essayer de trouver la commande "imprimer"? Votre équipe de support technique comprendra-t-elle même que cet utilisateur ne voit pas la commande "print"? Y aura-t-il des effets secondaires involontaires si, par exemple, l'imprimante est connectée mais s'est éteinte pour économiser de l'énergie?
En règle générale, je pense que dans de nombreux cas, en particulier dans les cas où une option est parfois disponible, les utilisateurs sont mieux servis par une option désactivée ou même une option activée qui affiche un message d'erreur expliquant POURQUOI l'option n'est pas actuellement disponible.
Je vois deux approches différentes.
Si les actions sont désactivées à cause de sécurité j'essaierais en fait de les supprimer si possible. Facile avec les éléments de menu ou la plupart des boutons de la barre d'outils.
Si les actions sont désactivées parce que vous avez une version moins chère du logiciel, je les garderais présentes mais désactivées. Cela permet à l'utilisateur de savoir "vous pourriez avoir cela si vous payez plus" alors que s'il était supprimé, il ne saurait pas ce qu'il manquait. Je considère que la fenêtre contextuelle "vous ne pouvez pas faire cela à cause de la licence" est une mauvaise interface utilisateur car l'utilisateur ne peut pas dire s'il peut effectuer une action sans réellement essayer de le faire.
Une autre approche consiste à ne pas montrer l'action du tout.
Stack Exchange en est un bon exemple. Si je n'ai pas le droit de "modifier" les publications d'autres personnes, je ne vois pas de lien "modifier" pas du tout. Cela signifie que je n'essaie pas de cliquer dessus et je me demande pourquoi cela ne fonctionne pas.
Cela peut ne pas fonctionner dans toutes les circonstances, mais dans votre exemple, les options/liens "admin" et "financier" n'apparaissent tout simplement pas pour les utilisateurs limités - même dans les écrans d'administration pour ces utilisateurs. Si l'utilisateur était changé pour un utilisateur "régulier" ou "Premium", ces options/liens apparaîtraient.
Vous pourriez alors envisager d'afficher le type d'utilisateur dans un endroit semi-visible afin que l'administrateur puisse se rappeler pourquoi certaines options/liens ne sont pas visibles!
Comme d'autres réponses l'ont indiqué, si l'utilisateur n'est pas autorisé à effectuer une action dans le système (comme dans, aucun privilège de modification/administrateur), l'action ne doit pas du tout être affichée.
Dans les cas où les actions sont désactivées en raison de l'état de l'application (ne peut pas modifier un fichier en lecture seule, ne peut pas copier/coller si aucun texte n'est sélectionné, l'utilisateur a une version d'essai du logiciel qui manque de quelques fonctionnalités, etc.) Personnellement, je pense que l'action doit être affichée, avec une indication visuelle que l'action ne peut pas actuellement être effectuée. Notez que je ne dis pas "désactivé", car si l'utilisateur essaie cette action, il devrait être en mesure de découvrir pourquoi elle n'est pas réalisable. De cette façon, un utilisateur peut voir que l'action est désactivée, mais il peut également obtenir un message expliquant pourquoi.
Je serais prudent avec le cas où un utilisateur a une version d'essai/sous-licence d'une application qui manque de fonctionnalités. Par exemple, si vous aviez une application de lecture/écriture ISO qui ne ripperait pas les CD à moins que vous ne l'ayez payée, alors vous pourriez montrer l'option "ripper les CD" mais ne pas laisser l'utilisateur l'exécuter. Mais si votre application possède des suites entières de fonctionnalités dans leurs versions haut de gamme (Visual Studio par exemple), afficher toutes ces choses sans les autoriser pourrait devenir frustrant pour l'utilisateur. Je ne veux pas ouvrir mes IDE et voir la base de données, la mise en réseau, l'UML intégré, les tests, le profilage, etc. quand je sais que tout ce que je suis autorisé à faire dedans est d'écrire et de construire des projets .
Ma règle d'or est la suivante: si une action n'est pas disponible pour un utilisateur en raison des autorisations, elle n'est pas visible. Si une action n'est pas disponible en raison d'un contexte temporaire (ce bouton 'Enregistrer' n'a aucune signification tant que l'utilisateur n'a pas entré quelque chose à enregistrer), alors il est désactivé.
"Autorisations" couvre à la fois "utilisateur admin vs utilisateur régulier" et "licence premium vs licence cheapo". Les éléments d'interface utilisateur inutilisables sont encombrants - pas le moyen de publier vos fonctionnalités supplémentaires.
Beaucoup de réponses semblent avoir raison, je voulais juste résumer le tout avec l'une des heuristiques de Nielsen, qui pointe exactement là-dessus. Il est dit:
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. Éliminez les conditions sujettes aux erreurs ou vérifiez-les et présentez aux utilisateurs une option de confirmation avant de s'engager dans l'action.
Source: http://www.useit.com/papers/heuristic/heuristic_list.html
J'aime vraiment shemnon's réponse. Je voudrais étendre son deuxième cas et appliquer le commandement Nielsen référencé par ign; si l'utilisateur a une licence moins chère, je désactiverais l'option et remplacerais l'objet de sélection par une icône qui rendrait plus clair l'état désactivé de l'option.
Quelque chose comme
- O Option 1
- O Option 2
![alt text]()
Option 3- O Option 4
Option 3Comme ce produit supposé est encore en développement, j'inclurais également au moins une déclaration du niveau de licence de l'utilisateur sur la même page. De cette façon, l'administrateur voit que le niveau de licence de l'utilisateur en même temps que l'administrateur examine les variables système directement affectées par cette licence.
Une beauté du logiciel est que tout ce que vous avez à faire est d'appeler l'information.
Modifier: En outre, je pourrais utiliser un schéma d'autorisation centré sur les rôles, dans lequel des autorisations peuvent être attribuées à des rôles et non à des utilisateurs individuels. Cela évite souvent une tonne de frais généraux d'avoir à microgérer les autorisations des utilisateurs individuels.
- L'administrateur ouvre l'écran de modification des rôles.
- L'administrateur sélectionne peut-être un bouton radio pour la licence la plus basse à laquelle le rôle sera appliqué.
- Les autorisations qui ne sont pas disponibles pour le rôle sélectionné sont désactivées et "x" ed.
- L'administrateur sélectionne les autorisations parmi les options actives restantes.
- Plus tard, dans l'écran de gestion des utilisateurs ou dans le profil utilisateur, l'administrateur voit la liste des rôles que l'utilisateur peut avoir en fonction de la licence, et l'administrateur en sélectionne un ou plusieurs.
En règle générale, ma règle empirique est la suivante (et j'ai besoin d'une bonne raison pour la casser): si le raisonnement derrière le composant désactivé découle du contexte ou que la compréhension devrait être facile pour l'utilisateur pour une autre raison, alors le blocage est la solution préférée. Sinon, l'utilisateur pourrait être frustré d'essayer de comprendre pourquoi c'est comme ça, et pire, ne se souviendra probablement pas de la raison (cas où il l'a compris) la prochaine fois qu'il le rencontrera.
Pour répondre à votre question spécifique, vous souhaitez afficher suffisamment d'informations pour que les utilisateurs puissent comprendre les limitations avant de cliquer. Dans votre exemple, vous devez répertorier chaque utilisateur avec sa licence en tant que champ en lecture seule connecté visuellement (par exemple, par proximité) avec les commandes pour définir leur autorisations. Vous pouvez également combiner dynamiquement le champ de licence avec le libellé des autorisations (par exemple, "Autorisations (avec licence limitée):").
Les autorisations non applicables devraient probablement être désactivées, non activées et non masquées. Si cela en vaut la peine, incluez du texte en ligne, du texte au survol/des info-bulles ou un lien pour expliquer pourquoi les autorisations ne sont pas autorisées par la licence (le texte en ligne peut remplacer les contrôles désactivés s'il répertorie les autorisations; par exemple, "Admin , Financial non autorisé pour les utilisateurs limités ").
La règle générale est de désactiver si l'utilisateur peut faire quelque chose dans l'interface utilisateur pour activer la commande. Désactivé signifie "vous pouvez exécuter cette commande, mais tout simplement pas pour le moment." La "façon dont les choses sont" comprend la sélection actuelle. Chaque fois que vous utilisez la désactivation, il doit y avoir une indication claire pour que les utilisateurs comprennent pourquoi les commandes associées sont désactivées pour certains objets.
Utilisez des boîtes de message au lieu de désactiver s'il n'y a aucun moyen de faire comprendre au préalable la raison de la désactivation à l'utilisateur en supposant qu'il a une connaissance moyenne du domaine. Les info-bulles pour les contrôles désactivés sont une excellente idée, mais peuvent ne pas être suffisantes en elles-mêmes dans tous les cas.
Utilisez le masquage si l'utilisateur n'a jamais accès à la commande, quoi qu'il fasse dans l'interface utilisateur, compte tenu de sa position actuelle dans l'organisation. Par exemple, les actions non autorisées par l'utilisateur compte tenu de ses autorisations n'apparaissent tout simplement pas. Il est encombrant et frustrant d'utiliser des boîtes de désactivation ou des messages pour ce cas. En ce qui concerne les utilisateurs, les actions pour lesquelles ils n'ont pas les droits ne sont pas leur travail (sinon ils auraient accès), et donc les contrôles associés ne devraient tout simplement pas exister dans leur interface utilisateur. La documentation ou les manuels de procédures d'organisation peuvent indiquer aux utilisateurs comment ces actions sont accomplies (par exemple, "Votre superviseur crée de nouveaux comptes clients pour vous" ou "Vous avez besoin d'autorisations financières pour modifier les comptes; consultez votre administrateur pour la procédure d'obtention de l'approbation de mise à niveau de vos autorisations. ”).
J'ai des détails sanglants sur Contrôle de vos contrôles .
Certains des points ci-dessus sont excellents, et je ne veux pas réitérer, mais ...
Dans ce cas, toutes les options disponibles seraient visibles. Les options qui n'étaient pas applicables dans vos règles doivent être désactivées (grisées). Il est de notoriété publique qu'un utilisateur de n'importe quelle interface reconnaît que si quelque chose est grisé, cela signifie généralement qu'il n'est pas applicable à une sorte d'ensemble de règles en cours.
Une info-bulle coïncide parfaitement avec un bouton désactivé. Dans certains cas spéciaux plus avancés tels que le vôtre ci-dessus avec des licences, si l'utilisateur sans la licence appropriée visualisait une zone qui nécessitait une licence supérieure, changer complètement l'art du bouton en quelque chose comme "Mettre à niveau maintenant!" au lieu de le grisonner serait une meilleure publicité pour le produit et faire passer le message.
Si l'utilisateur administrateur la consultait, il verrait évidemment que l'option financière est grisée, avec une info-bulle expliquant pourquoi.
Je ne connais pas parfaitement le contexte de votre problème, il se peut même qu'il n'y ait pas de produit impliqué. Mais d'après ce que j'ai compris, c'est ma réaction.
Windows UXGuide possède un certain nombre de ressources qui peuvent vous aider à décider d'afficher des erreurs ou d'empêcher une entrée non valide. Plus précisément, il y a ne section qui fait la déclaration ci-dessous à propos de l'interface utilisateur.
Ne donnez pas de messages d'erreur lorsque les utilisateurs ne sont pas susceptibles d'effectuer une action ou de modifier leur comportement à la suite du message. S'il n'y a aucune action que les utilisateurs peuvent entreprendre, ou si le problème n'est pas significatif, supprimez le message d'erreur.
De plus, cette discussion me rappelle un peu ce que Karl Shifflett dans son article de blog intitulé "Fort Knox Business Objects (oui/non)" où il évalue les avantages et les inconvénients de la possibilité d'autoriser ou non les objets métier à entrer un état invalide ou non et comment cette décision affecte l'interaction de l'utilisateur.
Personnellement, j'ai tendance à empêcher un utilisateur de faire des entrées non valides ou de désactiver les contrôles qui effectuent la plupart du temps des actions telles que des boutons, mais pour certains contrôles qui impliquent une entrée de texte complexe, j'ai tendance à afficher des avertissements en ligne qui sont moins envahissants que les boîtes de message, mais qui restent le point à travers.
Faites les deux: Backend et UI
Cela ne devrait vraiment pas être une situation non plus. Les autres réponses répertorient les bonnes raisons répertoriées pour afficher les options non disponibles et les bonnes raisons de ne pas les afficher. Mais la chose est, de toute façon, vous devez le gérer correctement sur le backend. Vous devez toujours vérifier correctement les entrées et les autorisations des utilisateurs, même si vous pensez que la seule entrée qu'ils peuvent donner est correcte.
Cela est d'autant plus vrai avec toute application Web, où l'utilisateur pourrait activer artificiellement un contrôle/une option/une entrée désactivée. Ne laissez pas l'utilisation de Firebug l'emporter sur la capacité de votre application à contrôler ce que je peux faire. Et dans le cas où ils essaient d'utiliser une option qui ne devrait pas être disponible, assurez-vous de consigner l'événement.