Lignes directrices pour le chevauchement des pages du navigateur?
Lorsque vous appuyez sur Page suivante dans un navigateur, il y a généralement un petit nombre de lignes à partir du bas de la fenêtre actuelle affichée en haut de la fenêtre suivante. La quantité de ce chevauchement est différente selon le navigateur utilisé (compte tenu d'une taille de police particulière, bien sûr). Dans la commande * nix "less", la quantité de chevauchement par défaut est zéro, mais cela peut être modifié par l'utilisateur. Bien sûr, zéro est ce que vous obtenez avec un livre imprimé ou un journal.
Existe-t-il des lignes directrices publiées sur le niveau de chevauchement ou des études sur le sujet?
Mise à jour: Merci à tous pour leurs contributions.
Le problème qui a provoqué ma requête est lié à WebKit. J'ai publié des informations sur les navigateurs KDE basés sur WebKit ici: https://forum.kde.org/viewtopic.php?f=15&t=108930&sid=c585b1db933e0c0be00ccd27a67e3638 et environ Chrome ici : https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/ZQjrFKfMOrY .
WebKit a changé il y a environ trois ans, j'ai trouvé. Dans le rapport de bogue WebKit qui a documenté l'augmentation du chevauchement, quelqu'un a commenté que certaines personnes Chromium envisageaient des effets graphiques subtils en dehors du chevauchement qui induiraient l'utilisateur, comme un léger éclaircissement ou assombrissement de la région de la page défilée qui disparaîtrait ensuite. : https://bugs.webkit.org/show_bug.cgi?id=32595#c16
Je pense que ce serait cool pour que la pagination fonctionne, donc il n'y avait jamais de lignes partielles au bas de la fenêtre avec juste la partie supérieure des lettres affichées. Les lecteurs de livres électroniques ont bien compris, mais ils ont généralement affaire à un contenu plus simple.
Cela dépend beaucoup du contenu. La quantité optimale d'affichage est juste suffisante mais pas plus que nécessaire.
Mais ce qui définit "juste assez" et juste assez pour quoi.
Juste assez pour pouvoir relier le contenu de la page suivante à celui de la page précédente.
Juste assez pour être en mesure de localiser le prochain point d'intérêt suivant le point d'intérêt précédent.
Juste assez pour confirmer visuellement que si vous étiez au milieu du paragraphe, il y a un peu de ce que vous venez de voir qui était le même contenu et que vous êtes en effet à un point qui est lié à la fin de la vue précédente.
Juste assez pour être en mesure de voir l'ensemble de quelque chose sans avoir à faire défiler la page ou à revenir en arrière pour voir le reste.
Il s'agit donc d'une manière liée à la segmentation des informations sur une page - et au flux d'informations sur une page.
Si vous lisez du texte, il ne devrait pas y avoir tellement de chevauchement que vous devez chercher loin dans le texte sur la page pour trouver le point de continuation. Ainsi, par exemple, quelques lignes devraient suffire pour que le contexte et les lignes "juste lues" puissent être facilement omis. Moins que cela et vous ne pouvez pas déterminer que vous êtes vraiment là où vous vous êtes arrêté.
Il est important d'avoir ce contenu de transition là pour lier les deux pages ensemble. Vous le voyez sur des cartes (en particulier de vraies cartes papier) où il y a juste assez de chevauchement pour que si vous suiviez une route ou un terrain en sortant du bord d'une page, vous pouvez en reconnaître une petite section sur le bord pertinent d'une autre page.
Le cerveau est très bon pour construire et reconnaître des modèles, et lorsque vous passez d'une page à une autre, vous ne relisez généralement pas le texte que vous venez de lire, mais vous recherchez ce modèle de mots que vous venez de numériser pour pouvoir limiter le flux de lecture. Trop d'informations et le flux est interrompu car vous ne reconnaissez pas le modèle. Puisque nous lisons le texte une ligne à la fois sans avoir à suivre avec votre doigt de la fin d'une ligne au début de la suivante, nous sommes très habitués à découper les lignes. Et cela signifie que nous devons au moins se chevaucher d'une ligne de texte complète.
Si nous regardons des images, il pourrait clairement être utile de les détecter et de les feuilleter vers le bas de manière à voir l'image ou le bloc entier suivant plutôt que de le couper en haut.
Cependant - ce n'est pas toute l'histoire, car nous ne lisons pas nécessairement le texte jusqu'au bas d'une page avant de paginer vers le bas. En fait, nous regardons beaucoup plus loin sur la page que nous ne le pensons au début. nous aimons voir un paragraphe entier sur la page afin que nous puissions traiter ce qui est clairement un morceau entier sans interruption. Nous détectons également des lignes brisées où nous ne pouvons voir que la moitié supérieure d'une ligne de texte en bas, ce qui est également gênant, nous pouvons donc bien faire défiler ou feuilleter vers le bas afin de l'éloigner de notre point d'intérêt actuel. Notez que les appareils de lecture n'afficheront jamais les moitiés d'une ligne.
Vous devez donc prendre en compte les cas où nous ne lisons pas complètement en bas, ce qui signifie que si nous pagayons vers le bas, nous avons besoin d'un chevauchement assez décent, et en fait 10% d'une page peuvent ne pas sembler étranges dans ces situations.
Il s'agit donc d'une ligne fine entre un chevauchement suffisant pour déplacer un point de référence à la même granularité que notre granularité de segmentation actuelle et un chevauchement tellement important que le point de référence que nous recherchons est trop bas.
Et c'est là que je suis entré - cela dépend du type de contenu - mais aussi de choses beaucoup plus subtiles telles que l'engagement probable du lecteur; la probabilité que l'utilisateur consomme le contenu de manière séquentielle ou plus aléatoire; les tailles de police; le paragraphe se casse; la visibilité de la fin d'un paragraphe ou l'exhaustivité de l'affichage de la ligne du bas (et de la ligne du haut après la pagination).
De toute évidence, le mécanisme de page vers le bas va devoir travailler dur pour bien faire les choses tout le temps étant donné le nombre de variables travaillant ensemble ici, et c'est une tâche presque impossible. Il y a donc un terrain d'entente qui, selon moi, se situe entre 2 et 6 lignes de texte en fonction de la hauteur relative de la fenêtre par rapport à l'écran.
Ce ne sont que mes réflexions réfléchies sur la question - peut-être que quelqu'un d'autre y trouvera un document.
C'est très individuel pour chaque navigateur, et cela change constamment. Opera n'avait aucun chevauchement jusqu'à la version 12, où il y a un chevauchement minuscule (ce qui dérange longtemps opera utilisateurs). Internet Explorer utilise un chevauchement de 10% qui est un énorme chevauchement, en particulier sur les écrans à faible résolution. Safari fait défiler une page entière "moins un petit chevauchement". Mais pour autant que je sache - il n'y a pas de chiffres à suivre.
Cela ne préoccupe pas vraiment les super utilisateurs, car ils font leur propre personnalisation du navigateur. Mais pour les autres utilisateurs, nous devons résoudre le problème que le chevauchement tente de résoudre. Il est très probable qu'un chevauchement soit présent par défaut pour la raison que l'utilisateur ne doit pas perdre le contexte lors de l'exécution des opérations du bouton [PgDn] en faisant défiler une page.
Pour ceux qui lisent un texte, un chevauchement d'une ligne de texte serait suffisant. Pour le "défilement Facebook", le défilement poste par poste serait le meilleur (comme ils le font dans Google+ en utilisant les boutons J (bas) et K (haut). Mais si vous avez besoin d'un pourcentage, j'utiliserais 5%, soit environ 38,4 pixels sur un écran de 768 pixels de haut. C'est assez bien pour couvrir la dernière ligne de texte de la "page" précédente, mais pas trop élevé pour que les utilisateurs perdent le focus en raison d'un chevauchement trop important.