ネストされた要素が逆方向にスクロールされるのはなぜですか？
私の質問は、スクロールの規則と、一般的な空間スクロールの規則についてです（ここでも水平方向のみですが、垂直方向のスクロールにも同じことが当てはまります）。
以下のモックアップを見ると、左側の<<ボタンをクリックするための認識された期待が、大きなコンテナ内のネストされたボックスが右に移動すること、そして右側の>>ボタンに対してその逆になることがなぜですか。 、ネストされた要素が左に移動することを期待します。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
このスクロール方法は、多くのスライダー、スクローラー、カルーセルなどで見たデフォルトのようです。ネストされた要素の逆のスライド方向をテストしたプロトタイプを作成したとき、それはdidn ' t気分がいい。
この標準的な動作は何に基づいていますか？ネストされた要素を矢印の方向に移動すると直感に反するのはなぜですか？
誰かが私がここで説明しているものと実際に方向が異なる例を持っていますか？
背後には非常に単純なロジックがあり、それが遠近法の違いです。たとえば、下の画像に示すように指などのフレームを作成し、「フレーム」を右に向けて、何が起こるかを確認します。
- フレームを右に移動すると、ビジョンが左に移動します。
- フレームを左に移動すると、ビジョンが右に移動します。
次に、誰がどこに行くのかを説明するために、2つの視点の1つを描く必要があります。指のフレームについて話す場合、指は左に移動しますが、ビジョンについて話す場合、ビジョンIS右に移動します。
コンピュータでは、画面は静止していて動かない。そのため、何かを動かすことを考えるときはいつでも、スクリーンの代わりに動くビジョンを想像します。上記と同じ学習を続けてください。これは、なぜ>>が実際にVISION TOWARDSを左に移動することを意味し、<<はVISION TOWARDSを右に移動することを意味するかを説明します。
概念モデルは「左矢印が要素を左に移動する」ものではありません。それは、「左矢印で要素on左に移動する」です。
このような間接的な操作では、UIの空間投影ではなく、ユーザーがユーザーが消費しているコンテンツの観点から考えていると想定するのはおそらく公正です。
この質問を読んで最初に頭に浮かんだのは、「相対性理論」でした。より科学的な方法であなたを説明しようと思います：
フレームの左端の後ろに隠れているコンテンツを見たいとしましょう。左ボタンをクリックします。これで、コンテンツを再表示するには左に移動する必要がありますが、コンテンツスライダーフレームは静止しています。これで、コンテンツスライダーフレーム内のアイテムが右に移動するはずです。下の画像で視覚化できるものと同じです。他の車のレストフレームから1台の車の動きを見るとき。
この標準的な動作は何に基づいていますか？また、ネストされた要素を矢印の方向に移動すると直感に反するのはなぜですか？
Mac（実際にはLisa）が開発されて以来、ビューポート/フレームの動きの方向を示す矢印は、単に主要な規則です。 Appleがこれを確立し、Microsoftが続き、その後は誰もがその一般的な慣習に反対するのはおかしいでしょう。しかし、常にそうであるとは限りませんでした 初期のGUI履歴スクロールについて 。
これらは単なる慣例であり、コンテンツの動きの方向とは対照的に、ビューポートの動きの方向に焦点を合わせることについて、それほど優れた、または「自然な」ものはありません。実際、数年前のデスクトップソフトウェアでは、この強調（マウスホイールとトラックパッドにより、ビューポートではなくコンテンツが移動する）Apple多かれ少なかれ、この強調が逆転しました）。
デスクトップ環境では、通常、カルーセルの使用法はワイヤーフレームで説明したとおりです。つまり、左矢印をクリックすると、左の要素が右の要素を押し出し、その逆も同様です。
これは、誰かがこれを始めて誰もが追随し、誰も挑戦したり変更したりしないという事実のために、支配的な慣習のためだけではありません。事実、Appleがこの動作を導入し、新しいOSXではパラダイムが逆転したため、左にスクロールするとすべてのコンテンツが左に移動し、逆も同様です。
以前の規約には、ユーザーの注意とフォーカスエリアに関連する別の側面があります。これは主に、ユーザーがマウスを画面の特定の場所にポイントしてクリックしてカルーセルを左または右に移動させる、マウスベースの対話から始まりました。認知的に、彼/彼女がその行動をとると、彼らの注意、焦点、および視覚も、画面の特定の場所、つまり左または右の矢印/ボタンに向かって移動します。これを考慮し、周辺のビジョンを考慮すると、コンテンツを左に押すと右にスクロールし、逆も同様です。ユーザーが左ボタンをクリックして、左からコンテンツが引き込まれ、既存のコンテンツが右にプッシュされると、ユーザーは、視野を移動するのではなく、周辺視野を使用するだけで、フォーカスを移動せずに新しい要素を見ることが簡単になります。 /カルーセルの他の極端にフォーカスします。これは、コンテンツが多く、ユーザーが方向に連続的にスクロールしている場合に特に重要な役割を果たしました。つまり、カルーセルに10個の要素があり、現在の位置が3番目または4番目のコンテンツがカルーセルに表示されるようになっているとします左側に隠れています。ユーザーがビジョンを左矢印に移動してスクロールを開始すると、この領域に焦点を合わせ続けることができ、周辺のビジョンを使用して、表示されている各コンテンツをスクロールおよびスキャンし続けて、探しているコンテンツを見つけます。
このパラダイムは劇的に変化し、ユーザー操作がポインターベースではなくフリックベースのタッチベースのモバイルの場合には逆転しました。ポインタやボタンが含まれていなかったため、フォーカスエリアを画面の特定の場所に移動してスクロールするアクションを検討する必要はありませんでした。むしろ、ユーザーはカルーセル領域内のどこかを左または右にフリックしてスクロールできます。そのため、特定の左/右の領域ではなく、カルーセル全体がフォーカスエリアになりました。この場合、カルーセルを現実の世界として扱い、ビジョンを左に動かすと左にあるものを見ることができ、逆も同様です。
AppleはiOSでこのパラダイムシフトを導入し、その後OSXにもそれを継続しました。 OSXでも動作し、トラックパッドにマルチタッチ操作が導入されたため、ユーザーはトラックパッドの特定の領域を使用して（従来のPCベースのトラックパッドのように）スクロールする必要がなく、2本の指を使用して2本の指をフリック/移動することでスクロールできます。トラックパッドの任意の領域で一緒に。
気づくと思いますが、今日でも電話だけでなく、デスクトップ/ラップトップまたはタブレットでも、両方のタイプの対話パラダイムが使用されています。カルーセルの端にある左/右ボタン/矢印/グラフィックを押してスクロールするボタンベースのカルーセルと、ユーザーが水平スクロールまたはトラックパッドまたはマウスホイールを使用してスクロールする暗黙のスクロールバーベースのカルーセルがあります。最初のケースでは、それが使用されているプラットフォームに関係なく、動作は同じです-左クリックするとコンテンツが左から引っ張られます。一方、2番目のケースでは、タッチベースのデバイスが私たちの生活に浸透していることを考えると、2番目のパラダイムが注目を集めています。 。これは、上で説明したビジョン/フォーカス/注意のコンテキストが原因です。
これで問題が明確になることを願っています。
問題は、これを誤って「スクロール」と呼んでいるのに対し、実際には「ページング」であると考えています。
このUIには、各画面に[次へ]ボタンと[前へ]ボタンがあった旧式のウィザードアプローチのレガシーがあります。時間の経過とともに単語が削除または矢印に置き換えられ、デザイナーが前のページと並んで次の「ページ」を表示し始めただけです。この問題は、ページが単一の水平方向の列に空間的に配置されることをアニメーションで補強することで悪化します（ページ全体の古い方法が、次々のものと瞬時にかつ無秩序に次のように置き換えられ、空間的な配置はまったく意味がありません）。
どちらかと言えば、ページはメモ帳のようにスタックに配置されると理解されていました。多くのアプリは、実際に隅にあるページカールを使用して、進んでいるページを表しています。