ブラウザページのガイドラインの重複？
ブラウザでPage Downを押すと、通常、現在のウィンドウフルの下部から次のウィンドウフルの上部に表示される数行が表示されます。このオーバーラップの量は、使用しているブラウザーによって異なります（もちろん、特定のフォントサイズを前提とします）。 * nixの "less"コマンドでは、デフォルトのオーバーラップ量はゼロですが、これはユーザーが変更できます。もちろん、ゼロは印刷された本や新聞でも得られるものです。
オーバーラップの量がどうあるべきかについての公開されたガイドライン、またはそのトピックに関する研究はありますか？
更新：貢献してくださった皆さんに感謝します。
私のクエリを促した問題はWebKitです。ここにWebKitベースのKDEブラウザについて投稿しました： https://forum.kde.org/viewtopic.php?f=15&t=108930&sid=c585b1db933e0c0be00ccd27a67e3638 と約Chromeここに： https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/ZQjrFKfMOrY 。
WebKitは約3年前に変更されました。オーバーラップの増加を文書化したWebKitバグレポートで、一部のChromiumの人々は、スクロールインされたページ領域をわずかに明るくしたり暗くしたりして消えてしまうなど、ユーザーの手がかりとなるオーバーラップ以外の微妙なグラフィック効果を検討していると誰かがコメントしました： https://bugs.webkit.org/show_bug.cgi?id=32595#c16
ページングが機能するのはクールだと思うので、ウィンドウの下部に文字の上部だけが表示されている部分的な行はありませんでした。電子書籍リーダーはこれを正しく理解していますが、一般的にはより単純なコンテンツを扱っています。
コンテンツに大きく依存します。表示する最適な量は十分ですが、必要以上ではありません。
しかし、何が「十分」を定義し、何のために十分であるか。
次のページのコンテンツを前のページのコンテンツに関連付けることができるのに十分です。
前の関心点の後に続く次の正確な関心点を見つけることができるのに十分です。
段落の途中の場合は、表示していたのと同じコンテンツが少しあり、実際に前のビューの終わりに関連するポイントにいることを視覚的に確認するのに十分です。
スクロールまたはページを戻さずに残りの部分を表示することなく、何か全体を表示できるのに十分です。
したがって、これは、ページ上の情報のチャンクと、ページ上の情報のフローに関連しています。
テキストを読んでいる場合は、ページのテキストをずっと下に探して継続ポイントを見つける必要があるほど、重なりすぎてはいけません。したがって、たとえば、コンテキストと「ただ読む」行を簡単に省略できるように、数行で十分です。それより少なく、あなたはあなたが本当にあなたが中断したところにいると決定することができません。
2つのページを結び付けるために、そこにその移行コンテンツを含めることが重要です。これは地図（特に実際の紙の地図）に表示されます。オーバーラップが十分にあるため、あるページのエッジを離れて道路または地形を進んでいた場合、別のページの関連するエッジでその小さなセクションを認識できます。ページ。
脳はパターンの構築と認識に非常に優れており、あるページから別のページに移動するとき、通常は読んだばかりのテキストを再度読み取ることはありませんが、スキャンしたばかりの単語のパターンを探して、読書の流れを制限することができます。パターンが認識できないため、情報が多すぎてフローが中断されます。ある行の終わりから次の行の始まりまで指でたどる必要がなく、一度に1行ずつテキストを読むので、行のチャンクに慣れています。つまり、最低でも1行の完全なテキストでオーバーラップする必要があります。
画像を見ている場合、これを検出してページ送りすることで、次の画像またはブロック全体が上部で切り取られるのではなく、表示されるようにすると便利です。
ただし、ページ全体を表示する前にページの下部にあるテキストを必ずしも読み取るとは限らないため、それだけではありません。実際、私たちは最初に思ったよりもずっと下の方を見ています。ページの段落全体を確認して、中断せずに明らかにチャンク全体を処理できるようにします。また、テキスト行の上半分だけが下に見える破線も検出されますが、これも邪魔になるため、現在の関心のあるポイントから距離を離すためにスクロールまたはページを下に移動する場合があります。読み取りデバイスでは、行の半分が表示されることはありません。
したがって、完全に読みきれない場合に対応する必要があります。つまり、ページを下がった場合、かなりの量のオーバーラップが必要であり、実際には、ページの10％が奇妙に表示されない場合があります。状況。
したがって、現在のチャンクの細分度と同じ粒度で参照ポイントを再配置するのに十分なオーバーラップと、探している参照ポイントが遠すぎるほどオーバーラップしていることの間の細い線です。
そして、それは私が入ってきた場所です-それはコンテンツのタイプに依存します-しかし、読者の関与の可能性など、はるかに微妙なものも。ユーザーがコンテンツを順次またはよりランダムに消費する可能性;フォントサイズ;段落が分割されます。段落の終わりの可視性、または下の行（およびページング後の上の行）の表示の完全性。
明らかに、ページダウンメカニズムは、ここで一緒に機能する変数の数を考えると、常に正しく機能するように努力する必要があり、不可能に近いタスクです。したがって、ウィンドウと画面の相対的な高さに応じて、2行から6行のテキストの中間が適切だとお考えください。
これらは、この問題についての私の考えた考えです-おそらく誰かがそれについての論文を見つけるでしょう。
これはブラウザごとに非常に個別的であり、変化し続けます。 Operaオーバーラップはバージョン12までありませんでした。小さなオーバーラップがあります（これにより長時間動揺しますopera users）。InternetExplorerは10％のオーバーラップを使用します。特に低解像度の画面では、大きな重なりがあります。Safariは、ページ全体を「小さな重なりを差し引いて」下にスクロールします。
スーパーユーザーはブラウザの独自のパーソナライズを行うため、これはスーパーユーザーには特に問題ではありません。しかし、他のユーザーについては、オーバーラップが対処しようとしている問題に対処する必要があります。 [PgDn]ボタン操作でページを下にスクロールするときにユーザーがコンテキストを失わないようにする必要があるため、デフォルトでは重複が存在する可能性があります。
テキストを読む人にとっては、1行のテキストの重複で十分です。 「Facebookスクロール」の場合、投稿ごとにスクロールするのが最適です（Google+でボタンJ（下）とK（上）を使用するため）。ただし、パーセンテージが必要な場合、5％を使用します。これは約38.4です。高さ768ピクセルの画面上のピクセル。前の「ページ」のテキストの最後の行をカバーするのに十分ですが、オーバーラップが大きすぎるためにユーザーがフォーカスを失うことはありません。