Dans la plupart des systèmes d'exploitation, il existe une distinction majeure entre:
les interactions qui ne sont disponibles que lorsque l'élément est mis au point (par exemple, taper pour écrire un texte dans un champ de texte) et:
interactions disponibles à tout moment (par exemple en cliquant sur un bouton).
Pouvoir cliquer n'importe où, y compris sur une fenêtre non active, est parfois dérangeant. En fait, les fenêtres en arrière-plan ne sont généralement pas entièrement visibles, et cliquer dessus risquerait d'interagir avec la fenêtre elle-même, au lieu de la mettre en avant.
Par exemple, si la fenêtre de discussion de Windows Live Messenger est couverte par le navigateur afin que seul le bas soit visible, l'activation de la fenêtre en cliquant rapidement dessus devient un processus aléatoire, car il est possible, par erreur, de cliquer sur un bouton avec un effet irréversible , comme Appel vocal (voir capture d'écran), étant donné que le bouton est:
non reconnaissable comme bouton d'appel vocal, car vous ne voyez ni l'icône, ni le texte.
non reconnaissable en tant que bouton, car la bordure n'est pas affichée tant que le curseur n'est pas dessus.
L'alternative au comportement par défaut de pouvoir interagir directement avec les fenêtres inactives serait de désactiver les éléments sur les fenêtres inactives.
L'avantage serait qu'au lieu de pointer précisément sur une zone non interactive d'une fenêtre (ici, la petite zone entre le bas de la fenêtre et les boutons de Windows Live Messenger), l'utilisateur pourra cliquer n'importe où sur un inactif pour l'activer.
Un autre avantage est qu'il n'y a pas de confusion dans l'action de clic. Actuellement, selon l'état de la fenêtre, un clic sur un bouton peut soit démarrer l'événement de clic de bouton (si la fenêtre est déjà active), soit activer la fenêtre et démarrer l'événement de clic (si la fenêtre n'était pas active).
Le problème est qu'il nécessite deux clics pour interagir avec une fenêtre dans les cas où le but est d'interagir avec un élément bien visible d'une fenêtre. C'est souvent le cas lorsque vous travaillez avec deux applications ou documents côte à côte.
Un autre problème est que la réponse visuelle (bouton désactivé) ne serait pas claire: est-elle désactivée parce que vous ne pouvez pas interagir avec elle, ou parce que sa fenêtre est inactive?
Des questions:
Quelles peuvent être les implications en termes d'efficacité utilisateur, si un élément d'une fenêtre était désactivé lorsque la fenêtre est inactive?
Existe-t-il des applications qui désactivent réellement leurs commandes lorsqu'elles deviennent inactives? Leur approche a-t-elle été jugée inefficace sur le plan de l'expérience utilisateur?
Votre question comporte deux parties différentes.
La première est de savoir si c'est plus efficace pour désactiver les contrôles dans les fenêtres inactives. Je dirais que ce n'est pas le cas, car désactivation un contrôle signifie qu'il n'a pas de contenu digne de l'attention des utilisateurs - désactivez! = En lecture seule. Dans la plupart des cas, une fenêtre d'arrière-plan contient du contenu auquel l'utilisateur peut faire référence, masquant que les informations rendraient les choses beaucoup plus difficiles à utiliser.
La seconde est que ce soit une bonne idée "d'avaler" le premier clic sur une fenêtre, pour que les utilisateurs n'activent pas par inadvertance des choses dont ils ne veulent pas. Je pense que c'est une excellente idée - tout comme Microsoft (enfin, l'équipe Office, de toute façon), comme Microsoft Office le fait tout au long.
Essayez de chevaucher une fenêtre Word ou Excel avec d'autres fenêtres et voyez ce que fait un clic sur la fenêtre Office - peu importe où vous cliquez, cela active simplement la fenêtre. Plus d'applications devraient imiter cette approche, à mon humble avis.
Grande question (en particulier la partie concernant un clic accidentel sur un bouton d'action lors de la sélection de la fenêtre inactive).
Je pense qu'il est logique de désactiver/griser les fenêtres inactives (celles qui ne reçoivent pas actuellement les entrées de l'utilisateur (souris, clavier et surtout, attention) NIQUEMENT si elles se chevauchent même si ce n'est que de quelques millimètres. L'utilisateur sait donc simplement en regardant la vue partielle de la fenêtre derrière la fenêtre active actuelle, qu'il est désactivé car il aura l'air désactivé avec des icônes et des boutons grisés et du texte, etc.
Donc, cliquer sur la fenêtre inactive (n'importe où sur la fenêtre devrait fonctionner car les boutons et le contenu sont tous désactivés) ne servira qu'à un seul but - lui donner vie et ensuite ce sera la fenêtre active.
Je dois reconnaître que ce serait un défi de programmation intéressant de détecter si les fenêtres se chevauchent à l'écran, mais c'est certainement faisable.
De cette façon, si l'utilisateur essaie de travailler avec deux applications/fenêtres côte à côte, il n'aura pas à cliquer deux fois pour activer l'une ou l'autre.
J'espère que cela pourra aider.