La case à cocher indéterminée est-elle uniquement un modèle d'interface utilisateur Microsoft?
Un rapide coup d'œil dans les résultats de recherche en ligne montre que l'état de case à cocher indéterminé ne semble pas être une interaction d'interface utilisateur très courante, mais Microsoft a persisté et est probablement le meilleur exemple d'applications logicielles utilisant le modèle de conception. Il existe de nombreuses alternatives à l'utilisation d'une case à cocher à trois états qui ont été examinées dans d'autres discussions, donc ma question est de savoir si Microsoft a continué à l'utiliser parce qu'elle est conforme à leurs directives de conception UX ou est-ce parce qu'il existe des cas très spécifiques où elle est en fait préférable d'utiliser des cases à cocher avec un état indéterminé? Dans l'affirmative, pourquoi cela s'applique-t-il principalement aux produits Microsoft et non à d'autres types de logiciels?
Les cases à cocher indéterminées ont été une sorte de tradition dans les produits Microsoft, principalement pour les cases à cocher imbriquées (signifiant symboliquement partiellement cochées, ou comme indicateurs qu'un utilisateur a agi sur un contrôle) et principalement dans les installateurs. Et comme vous le mentionnez, les cases à cocher à trois états font également actuellement partie des directives de l'application Windows Store , mais elles sont également tilisées sur OSX .
Je pense que c'est plus un modèle de formulaire qu'un modèle d'application.
Je me risquerais à dire que cela a à voir avec la tradition d'un côté, les développeurs étant habitués à travailler de manière déterminée, ainsi que les cadres avec des éléments qui n'ont pas n'a pas changé depuis longtemps (il suffit de regarder WPF et XAML, à l'exception de certains nouveaux composants d'apparence Metro, il n'y a pas eu beaucoup de concepts révolutionnaires); et avec des fonctionnalités de l'autre.
Si vous accédez à n'importe quel attribut de fichier Windows, vous verrez les mêmes cases à cocher indéterminées pour Lecture seule et Masqué. Donc ce ne sont pas seulement les développeurs qui y sont habitués, ce sont aussi les utilisateurs (avancés) .
Je dirais que: a) Ils servent un but (marquer un élément imbriqué comme partiellement vérifié, dans des vues arborescentes où chaque nœud a une case à côté) et b) Le prix de changer quelque chose de si ancré dans l'esprit des gens est assez élevé , et c'est la deuxième raison pour laquelle les cases à cocher à trois états sont toujours utilisées.
Je viens de trouver un bon exemple: Dropbox. Accédez aux préférences, à l'onglet Avancé et cliquez sur Synchronisation sélective. Vous verrez l'ancien arbre des cases à cocher. Dropbox est multiplateforme.
Ces exemples et le fait qu'il fait partie de la spécification HTML, et implémenté par les navigateurs modernes sur toutes les plateformes, suggèrent que non, ce n'est pas strictement un modèle uniquement Microsoft .
D'autres types de logiciels que j'ai utilisés récemment où j'ai remarqué une case à cocher try-state ont été Omnigraffle.
Par exemple, si un trait est activé sur certains éléments mais pas sur d'autres et sont regroupés; l'inspecteur affiche la case à cocher de trait dans un état intermédiaire.
Ici, la case à cocher try-state est un moyen crucial pour m'aider à comprendre rapidement les différents styles de plusieurs éléments.