Pourquoi la zone de glissement est-elle généralement limitée à la "barre de titre"?
Prenez une fenêtre de dialogue simple: 
L'utilisateur s'attendra à ce que la barre de titre puisse être utilisée pour faire glisser la fenêtre à travers l'écran. Mais pourquoi est-il limité à ce bar?
Pourquoi est-il rare que les fenêtres puissent être déplacées en cliquant n'importe où dans la fenêtre qui n'est pas un élément d'entrée et en faisant simplement glisser à partir de là?
Je dirais que cela conduit souvent à une action de glisser-déposer indésirable. Que se passe-t-il si cette fenêtre a par exemple une petite barre de défilement, que vous souhaitez faire défiler vers le bas de la page et que vous manquez accidentellement la barre de défilement? Vous feriez glisser la fenêtre vers le bas et vous devrez peut-être inverser cette action.
Pourquoi est-il rare que les fenêtres puissent être déplacées en cliquant quand même dans la fenêtre qui n'est pas un élément d'entrée et en les faisant simplement glisser?
Il y a souvent des images et d'autres éléments que vous souhaitez faire glisser et déposer dans une autre fenêtre. Ensuite, vous devez être en mesure de copier l'étiquette lorsque vous cliquez à proximité, mais vous souhaitez également faire glisser la fenêtre lorsque vous cliquez suffisamment loin. Vous devez donc définir un endroit où chaque utilisateur peut s'attendre à ce que le glissement de la fenêtre fonctionne. Et c'est actuellement la barre de titre.
La barre de titre n'est pas toujours le seul endroit à utiliser pour faire glisser la fenêtre (de nos jours, certaines fenêtres peuvent être déplacées par des parties de leur arrière-plan, mais c'est rare), mais c'est la convention la plus ancienne et la plus établie et la plus commune. Il est né au début WIMP UIs, les systèmes Smalltalk des années 70 et 80.
Si vous étudiez la façon dont les fenêtres ci-dessus ont été conçues, vous verrez qu'il n'y a vraiment aucune autre possibilité sur une fenêtre pour la faire glisser autre que la barre de titre - il n'y a pas d'arrière-plan de fenêtre inutilisé qui pourrait être saisi (rappelez-vous que l'immobilier sur écran était beaucoup plus cher à l'époque). Bientôt, la barre de titre s'est étendue sur toute la largeur de la fenêtre, rendant la fenêtre de forme rectangulaire, offrant plus d'espace pour saisir et a rendu les mises à jour d'écran plus efficaces sur le plan des calculs . Et le fait de rendre la barre de titre pleine largeur lui permettait de contenir des boutons qui agissent comme des raccourcis de manipulation de fenêtre.
Cela s'est avéré être un système très facile à apprendre et utilisable et a été copié par de nombreuses interfaces utilisateur différentes (Mac, Windows, etc.). Il n'y avait aucune bonne raison de s'éloigner de cette convention. Il n'était pas cassé donc il n'y avait pas besoin de le réparer, et il survit encore aujourd'hui.
Ce n'est en fait pas toujours vrai. Dans certains cas, le comportement par défaut de la plupart des applications serait de permettre de faire glisser les fenêtres par espace vide. Un exemple est KDE. Voir la capture d'écran:
Le style de widget Oxygen par défaut de KDE a une décoration de fenêtre fusionnée visuellement avec le contenu de la fenêtre. Ainsi, pour donner une impression de correspondance, le thème permet également par défaut de faire glisser les fenêtres de toutes les zones vides. Les deux parties de la conception sont quelque peu configurables: l'option de la fenêtre de glissement est mise en surbrillance dans la capture d'écran - elle peut être désactivée ou réduite, et il existe également une option pour décrire le titre de la fenêtre active pour empêcher la fusion des décorations avec le contenu.
Mais cette fonctionnalité est une source de controverse entre certains utilisateurs et développeurs, non seulement à cause du glissement de la fenêtre par erreur au lieu de déplacer une poignée de widget, comme mentionné dans la réponse de Marvin, mais aussi parce qu'il est pratiquement impossible de l'implémenter parfaitement avec les kits d'outils de widget actuels comme Qt et GTK +. Pour GTK + (en oxygène-gtk), il existe de nombreux hacks, y compris la liste noire de certaines applications courantes et des widgets individuels pour déclencher l'opération de glisser. Des hacks similaires, bien que dans une moindre mesure, sont présents dans l'oxygène-qt.
Le système d'exploitation Windows fournit la barre de titre et la boîte de contrôle (en option), ainsi qu'un mécanisme permettant aux utilisateurs du système d'exploitation d'organiser leurs fenêtres d'application (repositionnement, minimisation, maximisation, fermeture).
Du point de vue du système d'exploitation Windows, la barre de titre est l'API de l'utilisateur pour ces opérations. Tout le reste de la fenêtre est un "contenu" qui est sous le contrôle de celui qui a développé cette application spécifique.
Le développeur de l'application spécifique peut fournir à un utilisateur des moyens supplémentaires pour re-positionner, minimiser, maximiser et fermer, en créant des contrôles qui déclenchent l'API par programme (c'est-à-dire que vous pouvez implémenter une application où les fenêtres peuvent être repositionnées en en faisant glisser l'arrière-plan du contenu). Le développeur peut également désactiver complètement l'API de la barre de titre. C'est leur application. Le système d'exploitation ne peut pas imposer de repositionnement en faisant glisser l'intérieur de la zone de contenu, simplement parce qu'il est (par conception) hors de son contrôle.
Le glissement est limité à la barre de titre pour la cohérence et peut-être la convivialité. Si vous pouviez à la fois faire glisser une fenêtre en cliquant dans la zone de contenu, ainsi qu'interagir avec des boutons, du texte, etc. dans la zone de contenu, il y aurait une marge d'erreur beaucoup plus élevée (et une difficulté présumée dans la programmation).
Les clics dans la fenêtre sont réservés pour interagir avec le contenu. Dans votre exemple de fenêtre de dialogue, il y a suffisamment d'espace pour cliquer et faire glisser si cette option existait. Cependant, supposons que vous vouliez copier un message d'erreur à partir d'une fenêtre similaire à celle ci-dessous. La copie du message vous permettra de le coller dans une recherche Google et d'obtenir plus d'informations pour tenter de résoudre le problème. Il peut être très difficile de copier l'erreur si vous pouvez également la faire glisser en cliquant dans la zone de contenu principale.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Il y a probablement aussi une raison historique: définir si le curseur est dans la barre de titre est un problème beaucoup plus simple sur le plan informatique que de définir s'il est dans NOT(text OR button OR input box OR scrollbar OR ...). Je pense que je me souviens de fenêtres glissables dans GEM sur une machine achetée en 1987 avec 512 Ko de RAM, et certainement dans certaines applications DOS (mode texte) quelques années plus tard. Dans ces deux cas, le code devait rester simple. Sans raison impérieuse de changer cette convention, elle est restée. Vous pourriez même suggérer que certaines des autres raisons dans les autres réponses découlent de ce comportement de longue date, car les fenêtres sont devenues plus complexes. Mais cela pourrait aller un peu trop loin.
La question est principalement théorique car, même lorsque le fait de glisser sur un espace vide est une option, personne ne reste assis à choisir un endroit à partir duquel faire glisser. Cela prendrait plus de temps que de déplacer la souris directement à l'endroit où vous savez fonctionnera.
En termes d'acquisition rapide d'une zone déplaçable, je pense qu'elle a une valeur supérieure à zéro. Mais si ce n'est pas cohérent, ce n'est pas utile, et il semble que la seule façon pourrait être cohérente est que les fenêtres aient des bordures épaisses tout autour; et dans ce cas, les bordures seraient de toute façon plus utiles que les poignées de redimensionnement que les poignées de glissement.
Quoi qu'il en soit, je ne suis pas convaincu qu'il existe une pénalité de performance pour l'espace vide déplaçable. Lorsque vous cliquez avec la souris, le système (OS + applications) doit parcourir chaque contrôle à l'écran pour s'assurer qu'il a trouvé la bonne cible pour le clic. Au moment où il a compris que votre clic n'était dans aucun contrôle, il ne coûte rien de plus pour dire "OK alors, commencez à faire glisser la fenêtre".
Mac OS X permet de faire glisser le contenu de la fenêtre. Toutes les fenêtres en "métal brossé" fonctionnaient ainsi. Ainsi, le corps de la fenêtre entière était une zone déplaçable, et seules les zones occupées par des contrôles réels n'étaient pas déplaçables. Le problème avec cette approche (au moins pour moi et certains amis) était qu'il n'était pas très clair pour les utilisateurs où l'on pouvait glisser et où on ne pouvait pas.
Ceci est exacerbé si vous avez des vues qui n'ont pas de bordure évidente. Comme la zone de glissement était généralement spécifiée par vue, la zone non glissable était toujours un rectangle autour d'une vue, même si ses graphiques étaient circulaires ou si certaines parties de la vue étaient plus fines que d'autres.
Il semble Apple l'a remarqué, car l'aspect général du "métal brossé" a été supprimé (bien que les fenêtres créées en tant que telles permettent toujours le glissement, elles n'ont tout simplement pas l'air si différentes). Cependant, des fenêtres telles que les fenêtres du navigateur Safari ou les fenêtres des amis de Messages vous permettent toujours de les faire glisser, par exemple par leurs barres d'état en bas.