La logique derrière avoir un bouton OK et un bouton Appliquer
Revenant au bureau après avoir bu avec des interfaces mobiles, les boîtes de dialogue de bureau ont presque toujours ces trois boutons:
- D'accord
- Appliquer
- Annuler
- Un bouton de fermeture.
Ce modèle semble se produire sur les interfaces utilisateur Windows et Linux. Jamais essayé d'autres OS. Peut avoir existé sur Mac, mais je ne me souviens peut-être pas.
Il ne m'est jamais venu à l'esprit qu'ils étaient redondants jusqu'à maintenant. Le bouton Annuler est le même que le bouton de fermeture. Pourquoi a-t-il été placé là en premier lieu si les deux choses font la même chose? Ils ferment tous les deux la boîte de dialogue.
S'applique également aux boutons OK et Appliquer. J'ai tendance à cliquer non plus. Les deux font la même chose. Bien sûr, Appliquer appliquera les modifications sans fermer la boîte de dialogue. Mais la plupart du temps, vous avez déjà défini toutes les préférences dont vous aviez besoin et il vous suffit de confirmer par OK.
- Quelle était la logique d'une telle conception?
- Pourquoi une fermeture en cas d'annulation?
- Qu'est-ce qui différencie Appliquer de OK?
Ils sont distincts:
OK: applique les modifications et ferme la boîte de dialogue (ou revient à l'emplacement précédent/un niveau plus haut)Apply: applique les modifications afin que l'utilisateur puisse voir/travailler avec les résultats, mais garde la boîte de dialogue ouverte, prête pour d'autres modificationsCancel: ferme la boîte de dialogue sans appliquer de modifications.
Le "bouton Fermer" dans le titre de la fenêtre agit généralement comme une annulation, mais peut être considéré comme une "bonne redondance".Close: ferme la boîte de dialogue, mais indique également qu'il n'y a aucun changement à appliquer. La fermeture ne devrait pas être disponible si des modifications sont en attente
Commencez avec deux modèles d'utilisateurs distincts:
Le "modèle de bureau traditionnel" consistant à confirmer les changements avant de les rendre permanents est bien conforme à l'utilisation initiale des ordinateurs pour la science, l'ingénierie et les affaires: il y a un État officiel, quelqu'un en est responsable.
Pour l'environnement décontracté et axé sur le divertissement du mobile, un mode plus décontracté, "faites ce que vous voulez, vous pouvez le défaire à tout moment (dans des limites raisonnables)" convient beaucoup mieux.
(Notez que la distinction n'est pas entre ordinateur de bureau et mobile, c'est principalement entre entreprise et occasionnel.)
Maintenant, pourquoi ces boutons?
Le "Appliquer" est une extension du modèle OK/Annuler, vous pouvez le voir comme un hack pour obtenir un "aperçu manuel" dans les limites de l'API OK/Annuler.
Envisagez une conception alternative:
- La modification d'un paramètre de la boîte de dialogue rend immédiatement les modifications visibles "comme si elles étaient appliquées"
- OK rend les modifications permanentes et ferme la boîte de dialogue
- Annuler annule les modifications et ferme la boîte de dialogue.
Cela nécessite que toutes les modifications soient réversibles - même en cas d'erreurs, de connexions défaillantes, etc. Vous avez besoin de transactions réelles - ou quelque chose de proche, un simple Get/SetProperty L'API n'est pas suffisante pour cela. Cela crée également un couplage beaucoup plus serré entre l'objet et la boîte de dialogue, les mises à jour doivent être suffisamment rapides pour être considérées comme instantanées. De plus, les changements simultanés deviennent plus difficiles à gérer.
Le modèle "OK/Appliquer" fournit une solution de contournement qui peut être ajoutée à l'API existante avec un faible coût supplémentaire et des avantages souvent tangibles.
Alors qu'est-ce qui est "bien"?
Gardez à l'esprit qu'il y a deux aspects dépendants mais distincts ici: l'un est l'exigence (commerciale) de "prendre la responsabilité des changements", l'autre est une meilleure découvrabilité et un meilleur confort de "défaire".
Le modèle traditionnel OK/Cancel les met en désaccord. Le modèle "casual" prédominant dans le mobile privilégie le confort, retombant sur la "confirmation requise" uniquement pour des actions irréversibles importantes.
Ce modèle est également préférable dans les environnements commerciaux, mais nécessite souvent l'ajout du suivi des changements (quand qui quoi), de la gestion des rôles et de la comparaison/différenciation.
Tout d'abord, vous devriez n'utilisez jamais OK quand vous pourriez utiliser un verbe à la place. La signification de OK est trop facile à mal interpréter, il est préférable d'utiliser un bouton descriptif nom afin que les utilisateurs comprennent quelle action ils entreprennent. La seule fois où je pense qu'un bouton OK est acceptable est dans une boîte de dialogue purement informative.
Pourquoi une fermeture en cas d'annulation?
La redondance d'un bouton Cancel et du widget Close est une bonne chose. Bien qu'ils aient tous deux le même résultat la plupart du temps, ils signifient deux tâches distinctes. Le widget Close signifie "se débarrasser de cette fenêtre et ne rien faire" et le bouton Cancel signifie "J'ai changé d'avis et je ne veux pas faire cette tâche".
OS X contourne soigneusement ce problème en utilisant des "feuilles" (boîtes de dialogue modales de document). La boîte de dialogue est attachée au titre de la fenêtre supérieure. Le document lui-même conserve toujours son widget de fermeture, mais il est désactivé si une feuille est active. L'utilisateur sait donc qu'il a encore une décision à prendre.
Qu'est-ce qui différencie Appliquer de OK?
Apply est particulièrement utile dans une boîte de dialogue non modale. Vous pouvez par exemple appliquer des modifications à un document, puis voir comment les modifications affectent le document tout en gardant la boîte de dialogue ouverte, puis apporter d'autres modifications jusqu'à ce que le résultat souhaité soit atteint.
Dans une boîte de dialogue modale, Apply est identique à OK et, dans certains contextes, remplacerait simplement un bouton OK. (Voir ci-dessus, utilisez des verbes d'action au lieu de OK autant que possible.)
Je crois que la politique OK-Apply vient d'une époque où les formulaires avec plusieurs onglets (ou similaires) ne pouvaient pas conserver les modifications entre les commutateurs d'onglets. Ainsi, l'application avait l'avantage de permettre à l'utilisateur de appliquer un sous-ensemble des modifications qu'il avait l'intention d'effectuer.
Je ne supporte certainement pas l'approche OK-Apply, mais je dois admettre que la candidature m'a aidé à sauver prudemment mon chemin à travers un long formulaire sans craindre de sauvegarder tout ou rien!
Annuler sémantiquement peut signifier quelque chose de différent de Fermer, ce qui pourrait expliquer son existence initiale. Bien qu'au fil des ans, comme vous l'avez mentionné, aucune différence n'ait été observée entre eux.
Voir "Quand inclure un bouton Appliquer?" L'un des points à retenir des réponses est que le bouton Appliquer est hérité de ces moments où vous effectuez des modifications en temps réel/à la demande (comme le fait souvent Mac) serait coûteux, en termes de temps et/ou de puissance de traitement.
Si vous y jetez un coup d'œil, les boîtes de dialogue dans les téléphones et les systèmes d'exploitation mobiles n'ont généralement pas le combo de fermeture/annulation, mais elles n'ont qu'un bouton d'annulation lorsqu'une boîte de dialogue apparaît. Je suppose que la redondance d'annulation/fermeture provient d'un cadre d'interface utilisateur, où la boîte de dialogue aurait le bouton de fermeture par défaut, devenant un standard (pensez à la fonction alert () en JavaScript par exemple ).
Dans de nombreuses boîtes de dialogue Windows, il existe plusieurs onglets. Le point du bouton Appliquer, à mon avis, est d'apporter des modifications dans un onglet et de les appliquer avant de passer à l'onglet suivant.
Supposons que l'utilisateur soit sûr d'avoir effectué les modifications dans l'onglet actuel. Ils seraient Appliquer ces modifications, puis passer à l'onglet suivant pour apporter des modifications.
Les boîtes de dialogue sont parfois très gourmandes en paramètres, donc je suppose que c'est de là que vient le bouton Appliquer.
D'après ce que j'ai observé, de nombreux utilisateurs ont l'impression qu'ils doivent cliquer sur Appliquer pour appliquer les modifications et OK pour quitter. Ainsi, pour de très petites modifications comme "Verrouiller la barre des tâches", ils cliqueraient sur Appliquer et OK, au lieu de simplement OK. Je pense que le modèle Appliquer est un peu trompeur pour de nombreux utilisateurs. Il est également redondant dans la plupart des cas. La plupart des utilisateurs n'apportent pas beaucoup de changements. En fait, il serait préférable d'atténuer la plupart des paramètres et de diviser les interfaces utilisateur complexes en interfaces plus simples.
La redondance dans les interfaces n'est pas toujours une mauvaise chose.
Différents utilisateurs peuvent trouver l'un ou l'autre. Certains sont plus à l'aise de frapper la case Fermer. D'autres aiment voir le bouton et savoir ce qu'il fait. Certains utilisateurs frapperont Escape, une autre opération redondante. Tout cela est bon, tant qu'il n'encombre pas trop l'interface.
Vous pouvez supprimer l'un d'eux, mais dans ce cas, cela n'améliorera pas vraiment la convivialité de la boîte de dialogue.