Passez la souris sur un élément désactivé pour savoir pourquoi il est désactivé. Qu'est-ce que tu penses?
Combien de fois avez-vous utilisé une application de bureau ou une page en ligne et vous êtes tombé sur un ou plusieurs éléments de menu qui sont désactivés et vous ne savez pas pourquoi elle est désactivée. L'utilisation de l'aide ou de la documentation est inutile. Cela devient frustrant car cela vous empêche d'avancer.
Je n'ai JAMAIS vu cette pratique d'utilisation utilisée. Passez la souris sur l'élément désactivé et une info-bulle vous répertorie les raisons et vous dites "Oh .. ok. Maintenant je sais". Votre autre option est que vous devez contacter le support ou publier dans un forum, expliquer ce que vous faisiez. Attendez ce qui pourrait être des jours pour vous dire que vous obtenez une réponse, le cas échéant. C'est la différence entre le noir et le blanc. Obtenir de l'aide instantanée par un simple survol ou être frustré et attendre des heures.
Si vous êtes celui qui développe l'application, vous savez exactement pourquoi un élément est désactivé car vous l'avez désactivé dans votre code. Il n'est donc pas difficile de montrer les raisons à l'utilisateur. C'est ça?
Cette petite astuce aurait pu économiser des milliers d'appels de support technique. Il existe des millions de publications sur le Web expliquant pourquoi quelque chose est désactivé ou grisé.
C'est une bonne idée. Pour rendre l'infobulle plus facile à trouver, vous pouvez ajouter une petite icône d'aide aux contrôles désactivés. Depuis l'ajout d'une icône supplémentaire à côté le contrôle peut perturber la mise en page, vous pouvez ajouter l'icône au contrôle lui-même:
J'ai généralement constaté que les utilisateurs ne lisent rien. Surtout des info-bulles. Cela aiderait l'utilisateur averti, mais je ne pense vraiment pas que "des milliers d'appels de support technique" seraient enregistrés.
Cela dit ... ça ne fait pas mal. Pourquoi pas? Pour les quelques clients qui l'apprécient et le lisent, cela aurait un impact très sympathique.
Je me répète peut-être ici, mais la seule façon de savoir avec certitude si ce serait une amélioration est de le tester. Je peux donc être d'accord ou pas, mais cela n'a pas vraiment d'importance parce que je ne suis qu'un expert. Les vrais utilisateurs vont botter tous nos culs.
Les objets désactivés sont quelque chose de bizarre. Dans la vraie vie, si un bouton ne fonctionne pas, quelque chose est cassé.
Maintenant, si quelque chose doit être désactivé, ce devrait être un cas exceptionnel. Et des cas exceptionnels devraient être annoncés lorsque cela se produit (pour attirer l'attention de l'utilisateur) avec une déclaration claire et simple (et de préférence pas dans une boîte de dialogue "ok", car ils sont cliqués et non lus).
La vraie solution à mon humble avis est donc de ne pas désactiver les éléments dans l'interface utilisateur.
SI vous vous en tenez aux éléments désactivés, que dites-vous à votre utilisateur? Cela se résume probablement à "Désolé, c'est désactivé, parce que certaines choses internes rigides ne sont pas comme ça, mais vous ne pouvez rien y faire" ou "Hé, utilisateur, évidemment notre interface n'est pas assez intuitive, mais nous je vous dirais plutôt: faites ceci en premier "......
Brillant, simple et vraiment très utile.
Mais d'un autre côté, je cacherais tous les éléments inutilisables tous ensemble à moins que les utilisateurs s'attendent à les voir, comme soumettre des boutons ou une liste de contacts, je ne veux pas que l'utilisateur panique de ne pas voir ses contacts maintenant, n'est-ce pas?
Je l'aime, et je l'aime simple, pas d'icône, pas d'infobulle flashy, car pas beaucoup o les utilisateurs planeraient de toute façon, des info-bulles très courtes et des info-bulles de navigateur par défaut, sinon ce serait trop de code pour trop peu de valeur, et je suis presque sûr que le prochain architecte technique va supprimer cette fonctionnalité si elle est moins simple ...
Mais j'aime ça :)
Si quelque chose est désactivé, il n'a pas besoin d'être là, À MOINS qu'il ne nécessite pas d'explication.
Sinon, ce n'est que du bruit pour l'utilisateur.
Un exemple parfait de bonne "désactivation" est le bouton "envoyer" de l'application native de l'iPhone SMS. Il est désactivé jusqu'à ce que vous saisissiez du texte. Aucune explication n'est nécessaire, mais il doit y être.
Encore une fois, si un élément d'interface utilisateur doit être désactivé, alors vous devriez vous demander, est-ce qu'il doit vraiment être là du tout ... OU, puis-je changer l'interface utilisateur afin qu'elle ne nécessite pas d'explication?
J'ai catégorisé ce 2 cas:
1) Si son désactivé et son utilisateur ne peuvent rien faire, il vaut mieux ne pas l'afficher du tout, ou si vous ne lui montrez pas besoin d'infobulle.
2) Si son désactivé parce que vous avez besoin de votre utilisateur pour sélectionner une option qui est très proche (par exemple au-dessus du bouton), alors vous devez lui dire avec une info-bulle, veuillez sélectionner votre option puis cliquez sur moi.
C'est une bonne idée, nous l'avons en fait implémentée de manière assez cohérente dans notre http://www.taskconnect.com complément Outlook, car nous savons à quel point c'est frustrant quand vous ne pouvez pas faire ce que vous voulez et que vous ne le faites pas '' Je ne sais même pas ce qui ne va pas.
Cela ressemble à ceci: (dans une image, il y a une liste de magasins d'éléments de travail (TFS) connectés et déconnectés, ceux connectés ouvrent pour afficher leurs projets et ceux déconnectés sont grisés, avec une info-bulle contenant le message d'erreur du serveur )
Nous l'avons également fait pour les boutons d'une barre d'outils (lorsque vous ne pouvez pas modifier la tâche, l'info-bulle vous explique pourquoi).
Une autre pratique intéressante est que nous avons fait apparaître les info-bulles instantanément, afin que cette fonctionnalité soit facilement détectable, cela fonctionne également bien avec les icônes de la barre d'outils, car l'utilisateur se souvient presque inconsciemment de sa fonction à chaque fois qu'il les utilise.
En pratique, les utilisateurs qui savent ce que fait chaque bouton ne sont pas ennuyés, car la barre d'outils apparaît pendant des millisecondes, mais une fois qu'ils s'efforcent un peu, ils ont un rappel à portée de main. Qu'est-ce que tu penses?
Une autre alternative consiste à laisser l'élément activé, puis, si l'utilisateur clique dessus, à fournir des commentaires sur ce qui est requis avant que l'élément puisse être utilisé. Je ne pense pas que ce soit une solution appropriée pour toutes les situations, mais pourrait être utile à un novice, et pour un élément qui obtient occasionnellement par quelques-uns utilisation.
Soit dit en passant, je pense qu'un élément désactivé peut être meilleur qu'un élément masqué, car une fois que vous l'avez trouvé, vous pouvez arrêter de chercher et résoudre le problème d'enxt: POURQUOI n'est-il pas disponible? ;)
Vous pouvez également avoir une petite icône de point d'interrogation à côté de l'élément désactivé qui afficherait une info-bulle lors du survol. De cette façon, si l'utilisateur se demandait pourquoi un élément était désactivé, l'icône serait un indicateur évident qu'il pourrait y avoir des informations sur la raison pour laquelle cet élément est désactivé. Cela pourrait économiser certains appels de support.
Mais je dois convenir avec d'autres que la désactivation des contrôles n'est pas une bonne option. Soit le cacher sous condition ou mieux concevoir l'interface utilisateur afin qu'il ne soit pas nécessaire.
Edit: Après réflexion, il y a des endroits où la désactivation fonctionne à mon avis, mais l'élément désactivé devrait être activé par un paramètre à proximité, et le fait qu'il existe un paramètre qui active l'élément devrait être très clair (et pourquoi c'est le cas idéalement aussi).
Réfléchissez à la raison pour laquelle cette option est désactivée, pour quelle application et à quel moment de l'expérience. Appelez ensuite en conséquence.
Certaines considérations peuvent être: - L'utilisateur peut-il prendre des mesures pour l'activer? - S'agit-il d'un bouchon d'exposition pour l'utilisateur? Y a-t-il une valeur justifiable à résoudre cette situation? - Existe-t-il des alternatives faciles à cette option désactivée? (Devrait probablement cacher l'option désactivée dans ce cas)
L'idée a une certaine perspective, car l'aide des info-bulles (par opposition à l'aide séparée du contexte) est "juste à temps et en place".
Cependant, il y a certains cas à considérer, par exemple:
- Interaction tactile: sur les interfaces tactiles, vous n'avez pas d'état de survol en soi.
- Applications/paramètres complexes dans les applications où la désactivation d'un contrôle est due à une série de causes (qui ne peuvent pas être expliquées brièvement dans une info-bulle).