Webページが水平ではなく垂直にスクロールするのはなぜですか？
ウェブページは右から左ではなく上下にスクロールするのが一般的な慣例ですが、トイレットペーパーのロールに書かれていないすべての印刷物は水平に「スクロール」します。なぜウェブはこの古代の慣習を破ったのですか？
主な利点は、1つの垂直列から次の垂直列に移動する必要があるため、「ページをめくる」ときに発生する垂直ジャンプがなくなることです。これはおそらく私たちの目には簡単であり、これらのジャンプがコンテンツの不適切な場所で発生する可能性があるという懸念を取り除きます（物事をより均一にします）。さらに、ページが水平ではなく中央の垂直線で出会ったときに開いた方が簡単であるため、本はおそらく水平にスクロールします。
ほとんどの場合、Webページとワードプロセッサが主に垂直方向にスクロールする他のUX理由はありますか？
私たちは上から下へ読んだので、これは単に行われたと信じています。選択はかなり早い段階で行われ、おそらく技術的な制限に大きく影響されました。
テキストは線形にエンコードされるため、ほとんどのテキストエディター（ワードプロセッサーとは限りません）では、表示できる列と行の数に制限がありました。ずっと前に戻ると、これは通常、80列と25〜40行（VGAでは80x25）の線に沿っていました。画面がいっぱいになると、一度に1ページまたは1行スクロールするのが一般的でした。前の行を維持せずにページ全体をスクロールした場合、これは本を読むのに似ています。ただし、スクロールが少なければ、テキストを水平方向にスクロールして表示する余地がありませんでした。したがって、垂直にスクロールするのは自然なことでした。また、プログラムで一方向のスクロールとレンダリングを制限する方が簡単なので、早期にテキストを表示するグラフィックアプリケーションに影響を与える可能性があります。
プログラマーはコマンドラインの古い垂直スクロールツールに慣れていたので、これはより複雑なディスプレイに引き継がれたとは確信できません。これは今、人々が今日慣れていることに影響を与えています。初期のソフトウェアの多くは、ユーザーエクスペリエンスの研究に基づいていませんでしたが、プログラマーが自分で決めたものに基づいています。多くの場合、デザイナーの助けがなくても。
最近のWebサイトはこの規則に違反し、ページの水平スクロールを使用する場合があることに注意してください。特に、jQueryなどのグラフィカルライブラリを使用するHTML5サイト。
垂直スクロール対水平スクロールのテキストを読む経験に関する研究を他の誰かが知っているなら、私はそれらについて聞いてみたいと思います。
マイクロソフトのユーザーエクスペリエンスインタラクションガイドラインによると、
「人々は左から右、上から下の順序で読んだ（西洋文化の場合）
読み取りには、没入型読み取りとスキャンの2つのモードがあります。没入型読書の目標は理解力です。 ...スキャンの目的は、物を見つけることです。 」「ユーザーは、スキャンするときにテキストやナビゲーションペインの大きなブロックをスキップする傾向があります。すべてが同じである場合、ユーザーはまずウィンドウの左上隅を見て、ページ全体をスキャンし、右下隅でスキャンを終了します。左下隅を無視する傾向があります。」
意識して試してみるまでは信じられませんでした。案の定、10/10倍私の目は右下隅にドロップダウンしながら自然に左から右にスキャンしました。ページが水平方向にスクロールされた場合、ページコンテンツの45％が失われます。
読む価値があります： http://msdn.Microsoft.com/en-us/library/windows/desktop/aa511279.aspx#placement
テキストを使用する場合、下にスクロールすると、水平スクロールよりもゆっくりとテキストを表示できます。別の行を表示したいだけの場合は、ページ全体をめくる必要はありません。コメンテーターの1人が述べているように、上から下に読むので、垂直スクロールは、「行を消費する」方法と一致します。ユーザーが上から下の水平スクロールを読む言語の場合、より理にかなっています。
人間は一度に複数の単語を読み、その文脈で単語や文字を認識します。
なぜあなたはこれをレイドできるのですか？
垂直方向にスクロールすると、コンテキスト全体（テキストの新しい行）が表示され、水平方向にスクロールすると、理解するのに十分なコンテキストがなく、一度に1つの文字または単語のみが表示されます。
それは確立された規則についてではなく、これらの規則は同じ理由で存在します。印刷されたテキストがページにまたがると、理解が難しくなります。私たちの脳はテキストを文脈でよりよく理解するので、理解しやすくなるように整理することが最も重要な目的です。
スクロールの初期の実装では垂直スクロールが好まれたためです。先例が設定されると、それが支配的になる傾向があります。
この情報グラフィックによると、スクロールバーはしばらく前からありました。次に、Appla Lisaについていくつかの 詳細情報 を見つけました。
Lisaチームは、魅力的なフォントで80列のテキストを表示できるように、水平解像度に合わせてディスプレイを最適化することを決定しました。垂直方向のスクロールは、水平方向のスクロールよりもテキストの方がはるかに優れているため、垂直方向の解像度はそれほど重要ではありませんでした。デザイナーは、縦横の2倍の水平解像度をLisaに与え、720 x 360ピクセルディスプレイを使用し、ピクセルの幅が2倍の高さにした。これはワードプロセッサのようなテキスト指向のアプリケーションには最適でしたが、グラフィカルアプリケーションの場合にはやや不便になりました。
私は2つの理由があると思います：
- 上から下へ、そして幅の広い列は、読みにくくなります。途中で鼻をかいて、線がどこにあったかを忘れてしまうからです。したがって、水平方向にスクロールする場合は、ページごとに2列必要になるため、水平方向にスクロールする前に読んだ文章を読みやすくなります。
列が1つしかない場合は、新しいコンテンツを読む前に新しい列が画面に収まるまでスクロールする必要があるため、水平方向にスクロールするときに多くの時間を浪費することになります。スクロールしながら、新しいコンテンツの読み取りを開始できます。
70年代、80年代、90年代に垂直スクロールが当たり前になったのは、このためだと思います。
その後、理由2もありました。
- 水平にスクロールしたスクロールホイールを想像してみてください...
それを考えると中指が痛くなります。
はい、マウスホイールでの垂直スクロールの動きは、水平方向の動きよりもはるかに簡単です。1つは垂直、もう1つは水平で、2つのスクロールホイールを持つマウスは市場で失敗しています。スクロールホイールを横に傾ける機能を備えたマウス水平方向のスクロールもそれほどうまくいっていません。これらは揺れるため、垂直方向にスクロールしたいときにホイールを傾ける可能性が高くなります。
現在のマウスでは、水平スクロールが一般的になる方法はありません。なぜなら、それが... ^^の問題だからです。
タッチスクリーン/タブレットを使用すると、水平方向のスクロールがはるかに簡単になりますが、1。で述べた問題が依然として存在します。
左から右、上から下に書くシステム 書き込み方向 は、限られた幅と（実際には）無制限の高さの実際の紙または仮想紙を使用すると、より簡単になります。この制限された幅/無制限の高さ（または垂直ロール紙）モデルは、コンピューター画面または実際の紙ロールに適用され、実装が容易であり、簡単です他のほとんどのモデルよりも使用する固定サイズのページのシーケンスモデルは、多くのドキュメントプロセッサでサポートされているため、より複雑で、使用するのがより困難です。 縦型ロール紙モデル。ただし、無制限の行長のテキストは読み取りや編集が困難です）。
したがって、当初はマークアップされたテキストドキュメントで構成されていたWebは、コンピュータ画面上でのテキストドキュメントの表示に関する確立された規則に従いました。もちろん、今日のテクノロジーでは、水平または垂直にスクロールするページモデルを実装したり、他のページ遷移メカニズムを実装したりすることは難しくありませんが、優れたol 'vertical roll of紙スタイルのシステム。
より効率的だからです。
水平方向にスクロールする必要がある場合は、テキストの各行を最後までスクロールし、次の行の先頭に戻り、その行の最後までスクロールし、次の行の先頭に戻る必要があります。
垂直方向にスクロールすると、画面上のテキスト全体を読んだ後、複数行（おそらく画面全体）をスクロールして、新しいテキストを読むことができます。
水平方向に追跡する言語専用に設計していると仮定します。
Wordでラップされたテキストの改行は完全に任意である必要があります
テキストのブロックがあり、水平方向にスクロールしたい場合、十分であると判断して改行を追加する必要があるのはいつですか。インテリジェントに改行しようとする場合でも、最初にページのコンテンツを認識してレンダリングできるようにする必要があります。これにより、ユーザーエクスペリエンスが常に変化し、動的に読み込まれる可能性がなくなります。コンテンツ。
固定幅の列を作成することで改行の問題を排除できますが、これはメディアが豊富なドキュメントには適していません
本のような読書体験をシミュレートするため、列を読んだり、水平方向にスクロールしたりするアイデアが本当に好きですが、メディアが含まれているドキュメントには理想的ではありません。メディア。つまり、サイトは最初のデザインで完璧である可能性がありますが、更新する必要がある場合は、メディアの制約があり、再デザインを要求するか、（おそらく）メディアを送信することはできません。さらに、それは不必要な制約なしにユーザー提出を受け入れることができませんでした。
私はいくつかの歴史、タイポグラフィ、HCIを見ることをお勧めします。
歴史的には、巻物は古代エジプトにさかのぼり、記録保持に使用され、その後イスラエル人（文学の記録に巻物を最初に使用）によって使用され、コーデックスまたは製本が発明された1世紀以降に使用されました。これらのスクロールはhorizontal形式であり、垂直ではなく（一方の側で展開され、もう一方の側でロールアップされ）、テキストの列にかなり分割されていたことに注目するのは興味深いです本のページのように。
中世および近世では、ロールと呼ばれる短い文書は、主に会計、法的契約、在庫などの管理目的で使用されていました。巻物とは異なり、ロールは縦書きで書かれていることに注意してください。 フォーマット（垂直にスクロールするWebページのような）であり、多くの場合より広くなります。 [ウィキペディア1][ウィキペディア2]
スクロールとロールは、線形の連続したアイテムです。最初から始めて、読みたいものに到達するまでentireコンテンツ全体を文字通りスクロールします。逆に、本（またはコーデックス）は、閲覧したり、それにディップしたり、前後にめくったりすることができ、一般的には直線性の低い方法で使用されます。これは、はるかにアクセスしやすく、ユーザーフレンドリーであるようです。
活版印刷の観点からは、主にテキストの読みやすさに関する多くの考慮事項があります。ここで指摘すべき主な項目は、ラインの長さです。最適な行の長さは、スペースを含めて50〜75文字と見なされます。短すぎると、読者のリズムが崩れ、読書体験にストレスが加わります。長すぎると、1行の終わりから正しい次の行にスキップするのが難しくなります。 [「Typographie」-E. Ruder]ページごとの行数に関する推奨事項を知りません。
もちろん、これらのユーザビリティの考慮事項はHCIにも適用されます。
- 画面の大きさは関係ありませんが、最適な行の長さを超えてはいけません。
- コンテンツに浸ることができ、簡単に前後にスキップできるはずです。これは、非常に長いスクロールするWebページに特に関連し、ほとんどの人がWebを使用する方法です。
ただし、ページのスクロールに関しては、当然のことながらいくつかの考慮事項があります。
- ページインデックス（FAQページなど）などのナビゲーション、検索、またはその他の手段のいずれかを使用して、目的のページの任意の部分に簡単にアクセスできます（またはアクセスできるはずです）。
- 垂直スクロールを使用すると、一度に任意の量をスクロールできます1行または10ページ（または画面）であるのに対し、水平スクロールでは、一度に1ページに制限されます。
- テキストの列を水平にスクロールするにはどうすればよいですか？列の半分を画面から離して停止することを許可しますか？そうでない場合、水平スクロールはページめくりほどのスクロールにはなりません。
- 多くのテキストをスキャンするの方がはるかに簡単です垂直スクロールするよりも別々のページが生成する連続性の中断がないため、水平方向。