Il existe une tendance à utiliser des badges ou des images d'état pour afficher des informations, mais très souvent, ces badges ressemblent à d'autres éléments avec lesquels vous interagissez, tels que des boutons.
Il y a beaucoup d'informations sur l'accessibilité et comment l'indiquer, mais qu'en est-il comment montrer la non-accessibilité?
Contexte: Je travaille sur une application mobile où nous devons montrer le statut d'un élément (pensez à la liste des applications dans l'AppStore) comme étant inactif. La façon la plus élégante de le faire semble être d'utiliser une icône d'état dessus, mais certaines personnes essaient d'interagir avec l'icône. Je cherche donc des moyens de montrer clairement que ce n'est pas quelque chose avec lequel interagir. Cependant, la question serait plus utile à d'autres personnes si les réponses restent générales.
Il existe deux façons de voir ce problème. On suggère de créer des objets sans permettre d'interaction. L'autre suggère que vous impliquiez activement à l'utilisateur qu'un objet n'est pas interactif.
Pour satisfaire la première, la méthode est simplement énoncée: évitez les techniques qui sont généralement utilisées pour permettre l'interaction avec un élément . Ce que vous faites ici, ce n'est pas d'ajouter les divers repères de conception comme l'ombrage, les états onHover, les couleurs contrastées, etc.
Le seul élément sur lequel presque tout le monde peut s'entendre est généralement non interactif: le texte brut non coloré. Le style simple (ou le manque de) sur des éléments comme celui-ci signifie qu'ils ne se distinguent pas. Les utilisateurs ont également un modèle mental d'Internet (construit à partir des pratiques générales du Web) qui suggère que le texte brut ne fait généralement rien. Si vous avez des messages d'état, par exemple, vous pouvez les afficher en texte brut et ne pas leur donner de style ou d'animation majeurs. En les présentant de cette manière, vous ne vous offrez aucune action avec eux.
Divers autres attributs des possibilités peuvent être évités - couleurs funky, ombres, animations, effets onHover, bordures qui ressemblent à des boutons, changements de curseur de souris. Garder un élément clair signifie que les utilisateurs auront moins de raisons de croire qu'il offre une action.
Une autre technique consiste à présenter quelque chose qui est plus évidemment un composant interactif. Si vous affichez un message d'état, vous pouvez peut-être ajouter un contrôle qui masque le message ou effectue une autre action - car la possibilité sera beaucoup plus évidente, il est plus probable que l'utilisateur agisse de préférence. C'est le même principe qui suggère de donner plus de poids visuel à l'action que vous souhaitez qu'un utilisateur effectue lorsqu'il se voit proposer plusieurs choix.
Satisfaire la seconde est plus difficile, mais il existe des exemples. Un certain nombre d'indices suggèrent activement qu'un composant est inactif . En faisant cela, vous comptez sur les souvenirs de l'utilisateur d'avoir rencontré des éléments similaires dans un état inactif.
Les éléments inactifs sembleront s'éloigner de la conception ou s'y fondre. Un exemple courant est les icônes ou le texte grisés (ou plus généralement, les éléments avec un contraste plus faible que les éléments actifs). Ils n'auront pas non plus les divers autres avantages dont disposent les articles actifs.
En particulier, les icônes ou les badges peuvent se fondre dans le contenu environnant de telle sorte qu'il ne ressemble pas à un objet autonome. Les boutons sont faciles à appuyer et permettent leur pression en grande partie parce qu'ils sont contenus - évitez le confinement et les utilisateurs auront beaucoup moins de possibilités d'interagir avec l'icône. Par exemple, essayez ceci:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Il existe quelques autres méthodes, mais celles-ci sont généralement les plus courantes pour indiquer directement que quelque chose est inactif.
Et enfin, bien sûr, il vaut la peine d'étudier d'autres solutions au problème plus profond . Comme d'autres l'ont suggéré, utiliser l'opportunité à votre avantage et ajouter des fonctionnalités peut être une solution, tout comme la suppression des icônes elles-mêmes si leur présence cause plus de problèmes qu'elle n'en résout.
Je pense que vous auriez besoin de regarder votre site et de voir comment les possibilités sont actuellement affichées - vos boutons sont-ils affichés comme surélevés, avez-vous des états de survol, etc.? Je serais également intéressé de savoir comment vous savez que vos utilisateurs tentent d'interagir avec l'icône - si par l'observation, pouvez-vous leur demander pourquoi? Existe-t-il un moyen de mettre cela à votre avantage - pouvez-vous améliorer l'expérience utilisateur en faisant de l'icône un élément interactif?
Je pense que vous avez mis le doigt sur la tête avec cette déclaration:
Il s'agit d'une application mobile, alors regardez l'exemple général sous Android, où une simple icône plate est utilisée comme "bouton".
Le problème n'est peut-être pas le manque de moyens avec cet article. Il se pourrait que les articles qui devraient être abordables ne le soient pas. Vous devriez examiner non seulement la suppression de la disponibilité de cet élément, mais également l'ajout de la possibilité aux éléments exploitables dans l'interface.
L'abordabilité des clics peut être affectée en modifiant des choses comme celles-ci.
Je n'utilise pas d'Android, mais "grisonnant" (= faible contraste comme l'a dit le répondeur précédent)?
Je voulais aussi dire à propos de jouer avec moins de relief en relief, des ombres plus courtes, peu importe, mais chaque fois que je dis cela, je dois regarder le widget de case à cocher non cochée dans Android, pour lequel je dois toujours me rappeler en tant qu'utilisateur "non, ceci n'est pas désactivé: il s'agit d'une case à cocher non cochée "...
Dans les anciens temps de mac os en noir et blanc, nous avions cette notion en pointillés, supprimant chaque deuxième pixel du premier plan.
J'ai essayé maintenant, je suppose que cela montre toujours assez bien le handicap.
Cependant, cela dépend du PPI et de la propre vue de l'utilisateur ... pour moi, cela fonctionne, mais je n'ai pas un grand nombre d'appareils différents Android ici) ...
J'ai également essayé le flou, mais cela ne fonctionnerait pas très bien sur de petits écrans, je suppose.
(et voici un lien pour l'image d'origine, juste pour être correct, j'espère qu'elle est éligible à une utilisation équitable - je veux dire, hé, c'est une capture d'écran des préférences d'Android ...)