"Tous" contre "Tous" pour un choix qui indique un manque de filtrage
J'ai un tableau des éléments qui peuvent être filtrés par de nombreux aspects, dont l'un, par exemple, est le statut. Le filtre est représenté par une liste déroulante, où l'option par défaut est de pas filtrer par n'importe quel état.
Est-il plus correct de nommer cette option "Tous les statuts", indiquant que lorsqu'elle est sélectionnée, tous les statuts possibles seront représentés dans le tableau, ou "Tout statut", avec une signification plus proche de "Montrez-moi les éléments avec n'importe quel statut".
Merci!
EDIT - Plus d'informations:
Le contexte général est la gestion du workflow. L'utilisateur est un gestionnaire qui examine les éléments et peut-être les affecte à d'autres utilisateurs.
Les autres options de la liste déroulante sont "Ouvert", "Fermé", "Attribué" et peut-être quelques options spécifiques à l'industrie comme "Référé" ou "En cours d'enquête".
C'est une webapp, et les différentes listes déroulantes sont présentées dans un <fieldset> étiqueté "Filtres". La liste déroulante d'état elle-même est intitulée "État:". Un dessin brut ASCII:
+=== Filters =============...
|
| Office: [Any Office|^]
| Status: [Any Status|^]
Intéressant de lire les autres réponses qui semblent toutes tendre à utiliser "Tous". De nombreuses interfaces de filtrage que j'ai vues ont tendance à utiliser Any. Et j'ai tendance à être d'accord avec cela. Tout cela en combinaison avec un filtre semble tout simplement étrange.
Avec "any", vous exprimez que vous ne vous souciez pas vraiment de ce domaine. Un enregistrement peut avoir n'importe quelle valeur dans ce champ et être toujours inclus dans le résultat de recherche filtré.
Avec "tous", vous diriez qu'un enregistrement ne peut être inclus dans les résultats de recherche filtrés que si ces champs correspondent à toutes les valeurs possibles pour ce champ ... À moins que vous n'ayez affaire à un champ qui autorise plusieurs sélections (un champ de balise par exemple ), ce n'est tout simplement pas possible.
Exemple
Jira (le système de suivi des bogues d'Atlassian) utilise Tout pour les projets (pour rechercher dans tous les projets définis), tandis qu'il utilise Tout pour les autres champs. Les projets sont bien sûr configurables, mais les versions et les types de problèmes aussi. Bien que les types de problèmes soient limités en nombre, les versions d'un projet peuvent augmenter de manière assez significative. Probablement plus que le nombre de projets ... (en fonction bien sûr du type de magasin de logiciels utilisant Jira). Tous les champs de filtre permettent une sélection multiple en cliquant sur la touche Maj.
Mise à jour
DA01 m'a fait réfléchir à nouveau sur la raison pour laquelle il existe une incohérence apparente entre le champ du projet et les autres critères de filtre. Je pense que cela peut avoir plus à voir avec la façon dont le "projet" est perçu. Je soupçonne que la plupart des utilisateurs/développeurs ne perçoivent pas le projet comme un attribut (champ) d'un problème (bien que techniquement, bien sûr), alors que tous les autres champs sont et sont perçus comme des attributs de problèmes.
Il serait utile de voir un exemple de liste d'options. Entre les deux choix que vous avez donnés, je pencherais pour "tous les statuts" car c'est spécifique, où "n'importe quel statut" pourrait être mal interprété. "Tout" n'est pas la même chose que "tous" et d'après votre description, il semble que vous faites référence à "tous".
J'envisagerais également d'incorporer une étiquette et peut-être envisager d'autres termes:
View:
> All
> status 1
> status 2
> etc
Ça dépend. Votre filtre est-il étiqueté comme filtre, comme statut ou comme autre chose?
Filtre: (options)
et
Statut: (options)
ont différents "prédicats". Dans le premier, je nommerais l'option "Afficher tout" comme "aucun" ou "-", ce qui signifie qu'aucun filtre n'est en place. Dans le second, où nous parlons d'un statut et non d'un filtre, je dirais "tous"; les gens sont habitués à "tout" ou "tout ce qui précède" à partir d'autres contextes.
Que font les autres applications (ou tables) que vos utilisateurs utiliseront?
EDIT basé sur éditer la question: comme vous le décrivez, je recommanderais de ne pas utiliser de texte du tout; utilisez une valeur vide ou "-", tous deux bien compris dans les applications Web comme signifiant "aucune valeur sélectionnée". Votre interface indique déjà que vous parlez de filtres.
(J'appliquerais ce raisonnement à tous vos paramètres de filtre facultatifs, pas seulement à celui-ci.)
Pensée spéculative:
"Tous" est-il plus approprié lorsqu'il y a peu de catégories et que l'utilisateur les comprend (ou peut les comprendre)? Alors que "Any" est peut-être plus approprié lorsque la liste est longue et que l'utilisateur ne peut pas tous les tenir dans sa tête?
C'est très délicat, car les termes signifient des choses différentes et différentes selon les personnes. Il se peut que vous deviez essayer l'un ou l'autre et voir ce que les utilisateurs pensent.
S'il ressort clairement du contexte qu'il s'agit de filtrer les données - c'est-à-dire à partir de la liste de toutes les entrées, les filtres réduiront cette liste. Dans ce cas, Tout semblerait refléter ce mieux.
Si le contexte est que vous ajoutez des sélections, Any semble être meilleur, car cela implique que le statut ne sera pas inclus - Tous suggèrent que la plage sera étendue pour inclure chaque entrée avec un statut.
Donc, si vous restreignez une liste complète, tout va mieux. Si vous construisez à partir de rien, tout semms pour être meilleur. OMI.
Mais essayez-en et voyez.
Je penche également vers tous, mais j'ai l'impression que cela a besoin d'un verbe comme Afficher tous les statuts pour être complètement clair.
Si cela ne fonctionne pas, je qualifierais définitivement la liste non filtrée de tous les statuts. Tout implique un choix à partir d'un nombre donné ou une sélection aléatoire.
Si la sélection du filtre garantit que tous les différents états seront visibles à l'écran en même temps, utilisez "tous".
S'il existe un grand nombre d'entrées ou de nombreux statuts différents, la première page peut ne pas contenir une entrée avec tous les statuts disponibles. Dans ce cas, utilisez "any".