web-dev-qa-db-fra.com

Les actions spécifiques à l'élément de liste doivent-elles être masquées par défaut et révélées en survol ou toujours être divulguées?

Chaque fois que je crée des listes (ce qui est une belle chose en soi), je me demande comment traiter les actions spécifiques aux éléments de liste qui ne sont pas des actions en masse telles que la suppression.

Permettez-moi de vous donner un exemple, j'ai une liste de rapports et chaque rapport de la liste peut être édité ou exécuté si nécessaire. Pour trois rapports consécutifs dans une liste, cela ressemblerait à ceci, si les actions sont toujours affichées: http://cl.ly/image/091k290d0E2i - c'est une option qui fonctionne, d'autre part il y a aussi la possibilité de masquer les actions mais une fois que l'utilisateur survole l'élément de liste, l'élément de liste deviendra actif et les boutons d'action seront révélés, comme ceci: http://cl.ly/image/001S3K28431Y .

J'ai vu les deux sur diverses applications Web que j'aime vraiment utiliser et conçues par des designers que je respecte vraiment - cependant, je me demande s'il y a des résultats basés sur la recherche sur laquelle de ces approches fait mieux? J'apprécierais également votre opinion honnête personnelle.

Ce que j'aime personnellement dans l'approche toujours affichée, c'est qu'elle est infaillible et invite l'utilisateur à agir. D'un autre côté, il ne semble pas très agréable sur le plan esthétique de répéter les mêmes boutons encore et encore et de montrer beaucoup de choses dont l'utilisateur n'a pas besoin.

Ce que j'aime dans l'approche révélée en survol, c'est qu'elle ajoute un contexte plus interactif à l'élément de liste lui-même et n'apparaît qu'en cas de besoin (en supposant que l'utilisateur l'obtienne). Il cache vraiment ce qui n'est pas nécessaire. Il semble également plus agréable et réduit le poids des listes. D'un autre côté, cela peut être irritant et pas aussi utilisable que l'approche toujours affichée.

Curieux de vos pensées et des résultats testés sur celui-ci.

Merci!

4
Thierry M.

J'aime l'idée de l'effet de survol, car répéter les boutons encore et encore le rendra encombré. Cependant, l'effet de survol ne fonctionnerait pas sur les appareils tactiles.

Il existe d'autres solutions:

Petites icônes

enter image description here

Ils sont plus petits que les boutons et le rendront moins encombré. Pour l'édition, vous pouvez utiliser l'icône de crayon classique. Pour "exécuter le rapport", vous pouvez utiliser un avion (comme j'ai essayé de le visualiser avec l'icône en haut à droite de l'image) ou autre chose.


Icône d'option

enter image description here

Dans cette option, vous ajoutez la flèche classique et ajoutez les options dans une sorte de liste déroulante. Cela gardera le look encombré au minimum aussi.

3
Paul van den Dool

Je dirais qu'il y a une question principale à considérer lors du choix de l'approche; L'élément est-il répétitif pour chaque élément de la liste, et si oui, l'élément a-t-il des changements d'état qui fournissent des informations contextuelles?

Permet d'utiliser une boîte de réception e-mail comme sujet.

Une boîte de réception comporte généralement une liste d'éléments avec des commandes favorites pour marquer les éléments comme favoris. Ici, la présence de l'élément est répétitive et elle est affichée dans deux états différents, qu'elle soit signalée ou non. Dans un tel scénario, les éléments doivent être persistants, car ils présentent clairement à l'utilisateur la valeur de chaque élément.

La boîte de réception comporte généralement également des contrôles non répétitifs, tels qu'un élément indicateur de pièce jointe. Cet élément ne sera pas présent pour tous les éléments de la liste de boîte de réception et il est donc motivé de l'avoir affiché de manière persistante pour tous les éléments de la liste afin que l'utilisateur n'ait pas à rechercher manuellement, par manipulation directe, quels e-mails contiennent une pièce jointe.

Le dernier exemple qui, à mon avis, ne nécessite pas d'éléments visuels persistants serait le contrôle de suppression. L'utilisateur sait qu'il peut supprimer des messages individuels, il peut supprimer tout message qu'il souhaite et il n'a pas besoin de la liste pour encombrer la vue en laissant chaque message dire à l'utilisateur qu'il peut le supprimer. Il suffit que le contrôle soit affiché en survol, ce qui fournit également une excellente correspondance entre l'élément et l'action (que vous avez également mentionné dans l'OP).

Donc, dans le scénario que vous décrivez ci-dessus, je pense que cela ressemble le plus au troisième exemple. Vous disposez d'un ensemble d'actions qui seront disponibles pour tous les éléments de la liste et, par conséquent, cela pourrait poser pour une mauvaise UX de les afficher de manière persistante pour tous les éléments de la liste.

1
AndroidHustle

D'après l'expérience des utilisateurs, je suis sûr que la plupart connaissent les options d'icônes ligne par ligne, c'est donc une fonctionnalité sûre. Avec des appareils tactiles au design réfléchi, vous pouvez les rendre IMHO très esthétiques. Alternatives

Jetez un œil aux guides UX pour les implémentations de liste

  1. Android
  2. Microsoft
  3. Apple

À la fin de la journée, vous voudrez peut-être mettre un outil de journalisation pour voir ce que les gens utilisent réellement pour chaque ligne et laisser les plus populaires.

0
Jamie Clayton

Il m'est venu à l'esprit, beaucoup de listes que je vois, qui ont la même action pour plusieurs éléments, ont leurs actions répertoriées en haut de la liste. Vous pouvez ensuite sélectionner le ou les éléments (ou dans ce cas les rapports) que vous souhaitez exécuter et cliquez sur le bouton "exécuter le rapport". Cela pourrait-il fonctionner pour vous?

enter image description here

0
Paul van den Dool

Il semble que vous souhaitiez que vos utilisateurs sachent qu'ils peuvent agir sans les déranger avec un tas de boutons.

S'il y a beaucoup d'articles, je pense qu'il vaut probablement mieux ne pas afficher les boutons car cela ajoute des formes et des informations inutiles. Sinon, si vous avez une courte liste, vous pouvez afficher les boutons pour chacun d'eux.

Il existe une autre solution que Scoop.it utilise. Dans chacun de leur contenu, il y a un carré vert avec une icône en haut à droite qui se développe pour afficher les mots "Scoop.it!" au survol (regardez la capture d'écran ci-dessous). Si vous ne voulez pas que vos utilisateurs ignorent le fait qu'ils peuvent interagir avec les éléments, vous pouvez essayer d'ajouter quelque chose comme ça.

Scoop.it button on hover

0
Gabin