Par contre, par exemple, la case à cocher « Aperçu » que l'on peut avoir dans Gimp, est pour moi un mauvais exemple d'utilisation, et devrait être un ToggleButton
Moi ce qui m'énerve, c'est l'utilisation d'une case pour Muet, lorsque je veux cliquer rapidement, je clique souvent à côté et je préférerais un bouton.
Je suis donc d'accord avec toi pour dire que la case à cocher ne devrait pas être utilisée comme bouton. Par contre la forme du bouton ne devrait pas être une histoire de thème.
J'ai regardé un peu les appareils qui m'entourent, et en fait globalement, il y a une différence entre un bouton qu'on enfonce (et qui reste enfoncé) et un bouton que l'on fait glisser. Le bouton qu'on enfonce sert généralement à activer/désactiver quelque chose (marche/arrêt, filtre actif/inactif, mute...). Alors que le bouton que l'on fait glisser (ou le bouton rotatif) sert à faire varier un comportement actif (AM/FM, souris gaucher/droitier, synchro sur la voie 1/ voie 2, émission sur canal A/canal B...). On peut donc très bien avoir une interface avec des boutons d'apparences différentes. D'ailleurs l'exemple du tableau de bord d'avion avait été évoqué, et c'est un exemple extrême de mélange de formes de boutons. La forme du bouton dépend plus de l'usage que de l'esthétique.
Donc pour résumer :
- la case à cocher pour remplir les formulaires (cas un peu particulier dans la vrai vie) ;
- le boutons qui s'enfonce pour activer/désactiver quelque chose ;
- le bouton à glissière pour modifier une action.
Se sont dans la vie des concepts plus ou moins différents qui ne doivent donc pas être unifiées graphiquement, mais qui informatiquement se ramènent à un choix binaire. Ces fonctions sont tellement proches (d'ailleurs comme tu le dis, ils sont dans gtk hiérarchiquement liés) qu'on peut dans certains cas utiliser indifféremment l'une de ces possibilités. Le problème n'est donc pas qu'on puisse retrouver ces différentes possibilités dans une IHM, mais plutôt que certains développeurs en perdent le sens premier et les utilisent n'importe comment.
[^] # Re: Interrupteur
Posté par ElectronLibre63 . En réponse à la dépêche Sortie officielle de GTK+ 3.0 !. Évalué à 3.
Moi ce qui m'énerve, c'est l'utilisation d'une case pour Muet, lorsque je veux cliquer rapidement, je clique souvent à côté et je préférerais un bouton.
Je suis donc d'accord avec toi pour dire que la case à cocher ne devrait pas être utilisée comme bouton. Par contre la forme du bouton ne devrait pas être une histoire de thème.
J'ai regardé un peu les appareils qui m'entourent, et en fait globalement, il y a une différence entre un bouton qu'on enfonce (et qui reste enfoncé) et un bouton que l'on fait glisser. Le bouton qu'on enfonce sert généralement à activer/désactiver quelque chose (marche/arrêt, filtre actif/inactif, mute...). Alors que le bouton que l'on fait glisser (ou le bouton rotatif) sert à faire varier un comportement actif (AM/FM, souris gaucher/droitier, synchro sur la voie 1/ voie 2, émission sur canal A/canal B...). On peut donc très bien avoir une interface avec des boutons d'apparences différentes. D'ailleurs l'exemple du tableau de bord d'avion avait été évoqué, et c'est un exemple extrême de mélange de formes de boutons. La forme du bouton dépend plus de l'usage que de l'esthétique.
Donc pour résumer :
- la case à cocher pour remplir les formulaires (cas un peu particulier dans la vrai vie) ;
- le boutons qui s'enfonce pour activer/désactiver quelque chose ;
- le bouton à glissière pour modifier une action.
Se sont dans la vie des concepts plus ou moins différents qui ne doivent donc pas être unifiées graphiquement, mais qui informatiquement se ramènent à un choix binaire. Ces fonctions sont tellement proches (d'ailleurs comme tu le dis, ils sont dans gtk hiérarchiquement liés) qu'on peut dans certains cas utiliser indifféremment l'une de ces possibilités. Le problème n'est donc pas qu'on puisse retrouver ces différentes possibilités dans une IHM, mais plutôt que certains développeurs en perdent le sens premier et les utilisent n'importe comment.