Les barres de défilement imbriquées (une zone de défilement dans une autre zone de défilement) présentent quelques difficultés malheureuses, principalement lors du défilement à travers elles avec la molette de la souris.
La question de savoir si de telles barres de défilement sont une bonne idée ou doivent être évitées a déjà été discutée:
Pour cette question, je voudrais demander ce qui peut être fait si l'on est coincé avec une telle constellation:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Disons que la disposition des fenêtres ci-dessus est déjà principalement en pierre. L'application a une zone externe trop haute pour un seul écran et plusieurs zones internes hautes. Que peut-on faire pour faciliter l'interaction de l'utilisateur avec une molette de la souris?
Le paradigme Windows par défaut semble être:
Est-ce un défaut raisonnable? D'après mon expérience, cela peut entraîner des interactions discordantes lorsqu'un utilisateur essaie de faire défiler la grande zone, et pendant ce processus, une plus petite zone est déplacée sous le curseur, de sorte que la cible de défilement change.
Que peut-on faire pour améliorer l'expérience utilisateur ici?
J'ai été dans cette situation plusieurs fois. Ce que j'ai toujours fait, c'est programmer l'application pour faire défiler l'élément le plus enfant sur lequel se trouve le curseur et uniquement cet élément:
Pour clarifier, quand je dis seulement cet élément, je veux dire que si vous faites défiler un élément dans une direction et que vous atteignez la fin de cette barre de défilement, Je le programme de telle sorte qu'il ne procède pas en faisant défiler son élément parent dans cette direction.
Certains diront que s'il procédait en faisant défiler son élément parent dans cette direction, cela vous éviterait d'avoir à déplacer le curseur pour "échapper" à l'élément enfant. Bien que cela soit vrai, c'est précisément la situation que j'essaie d'éviter, car cela provoquerait également une interaction instable et ascendante indésirable entre les différents éléments qui seraient déroulés.
Donc, en résumé, je programme l'application de sorte que lorsque vous faites défiler un élément dans une direction et que vous atteignez la fin de cette barre de défilement, rien ne se passe jusqu'à ce que vous fassiez 1 des 2 choses: 1) vous faites défiler dans l'autre sens ou 2) déplacez votre curseur sur un autre élément que vous souhaitez faire défiler.
Voici une représentation visuelle:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Une mauvaise situation, mais cela arrive parfois lors de la maintenance d'anciennes applications.
Il y a quelques choses que vous pourriez faire pour rendre les choses un peu moins confuses:
Faites absolument pas changer le comportement par défaut à cet égard. Pourquoi? Parce que c'est l'une de ces rares choses où le comportement du système d'exploitation est défini de manière trop stricte et cohérente pour le casser. Pour l'instant, je n'ai pas vu une seule application briser ce comportement (sans compter les anciennes applications à moitié émulées folles qui n'étaient jamais destinées à être exécutées sur Windows ou qui sont officiellement multiplates-formes, mais pas de manière réaliste) et vous auriez besoin d'avoir une très bonne raison de faites-le. La question suivante devient: avez-vous une très bonne raison de le faire? Eh bien, je ne l'ai pas encore entendu lire les autres réponses. Certes, surtout lorsque vous laissez peu d'espace entre les sous-zones et la barre de défilement latérale, il est loin d'être agréable de faire défiler rapidement, il serait donc bon de créer un espace horizontal si cela est raisonnablement possible (facile sur le Web, difficile dans une application de bureau) ), mais ce n'est pas une raison suffisante pour rompre avec un comportement standard cohérent. La réponse de Franchesca à cet égard est tout à fait sensée car elle essaie d'étendre le comportement standard plutôt que de le changer complètement, mais je ne sais pas dans quelle mesure les solutions sont pratiques .
Cela ne veut pas dire que vous n'avez pas raison de souligner qu'il y a un problème ici. Le vrai problème ici n'est cependant pas de savoir comment faire interagir la molette de la souris - c'est la partie qui devrait être en grande partie gravée dans la pierre -, mais pourquoi une mauvaise interface utilisateur est définie dans la pierre. La suggestion de User50881 d'utiliser des onglets au lieu de les aligner les uns au-dessous des autres est par exemple valide et dans la plupart des cas, sonne très bien. Ou selon le contenu, il existe d'innombrables autres interfaces qui pourraient être envisagées et pourraient être meilleures. Le fait est que si vous avez le temps de coder des comportements de défilement personnalisés (ce qui est loin d'être facile), j'ai du mal à croire que l'interface utilisateur elle-même ne peut pas être modifiée avec la bonne proposition.
Est-ce un défaut raisonnable? Oui, si vous souhaitez faire défiler les petites zones.
Que peut-on faire pour améliorer l'expérience utilisateur ici? Débarrassez-vous de l'imbrication, utilisez 3 onglets par exemple, zone de contenu 1, zone de contenu 2, reste de la page. Ou remplacez les zones par des boutons pour ouvrir une fenêtre contextuelle.
Avec plus de détails sur le contenu des boîtes, les gens peuvent vous donner de meilleurs conseils spécialisés.