1つの画面に複数のリスト-最善のアプローチ？
たとえば、Friends用とHobbies用の2つのリストがあるプロファイル画面があるとします。 これは単なる例です。CustomerおよびSuppliersを含むOrders画面でもかまいません。一般的な問題を解決するために、さまざまなパターンの長所と短所を発見したいと思っています。
ソリューションA： スクロール可能なページにすべてを表示する
（リスト自体はスクロールしませんが、長すぎるとページングされる場合があります）
ソリューションB： 2つのスクロール可能なリストボックスがある画面
（画面はスクロールしません）
ソリューションC： リストごとにタブがある画面
（画面はスクロールしません）
ノート
ソリューションAはWebアプリケーションの一般的なアプローチですが、[〜＃〜] b [〜＃〜]および[〜＃〜] c [〜 ＃〜]はデスクトップアプリでは一般的です。どちらのモデルも使用できるリッチクライアントアプリケーションのアプローチを調査しています。予想される慣習は、私にとってそれほど重要ではありません。純粋にユーザビリティの観点から、どのパターンが優れているかに興味があります。
これまでの私の観察：
[〜＃〜] a [〜＃〜]はcontentを強調し、一方で[〜＃〜] b [〜＃〜]および[〜＃〜] c [〜＃〜]の構造を強調します情報。 [〜＃〜] a [〜＃〜]を使用すると、ユーザーは画面をスクロールするまで
Hobbiesが使用可能であることに気付かない可能性があります。[〜＃〜] a [〜＃〜]を使用すると、ユーザーは特定の情報をより多く見ることができます（
Friendsでいっぱいの画面全体を見ることができます）。 [〜＃〜] b [〜＃〜]および[〜＃〜] c [〜＃〜]表示される情報は少なくなりますが、表示されますin context（Profileの上部がスクロールされて表示されなくなることはありません）。[〜＃〜] b [〜＃〜]を指定すると、ユーザーは他に何もしなくても（スクロールまたはクリック）、
FriendsとHobbiesの両方の少なくとも一部が表示されます。FriendsとHobbiesの数が少ない場合、[〜＃〜] a [〜＃〜]は本質的に[〜＃〜] b [〜＃〜]と同等になります。FriendsとHobbiesがたくさんある場合、[〜＃〜] b [〜＃〜]はユーザーにスクロールを要求しますtwo画面の領域。 [〜＃〜] c [〜＃〜]は、Hobbiesを表示するために常にユーザーアクションを必要とします。
あなたの考えは何ですか？
ほとんどの場合、Bが最適です。これにより、ユーザーは最も柔軟性が高くなり、スクロールで別のクラスをスキャンしながら、あるクラス（Person、Friends、Hobbies）から必要なデータを表示し続けることができます。 Bはまた、リストが長い場合にページングする必要を回避します。これにより、複雑さと その他の欠点 が追加されます。
ソリューションAは、ユーザーが詳細を見ると、上部の「プリンシパル」コンテンツ（名、姓などのコンテンツ）を非表示にします。その結果、ユーザーは自分が見ている友達や趣味を正確に把握できなくなる可能性があります。
解決策Aは、ウィンドウサイズによっては、友達がたくさんいる場合に趣味が表示されることに気付かないこともあります。
ソリューションAは、ペインのタイトルとテーブルの列ヘッダーがスクロールしてビューの外に出る可能性があることを意味し、ユーザーは正確に何を表示しているのか混乱する可能性があります（フレンドまたはライバル？出荷日または受信日？）。
ソリューションAとCでは、ユーザーが関心のある友達や趣味を同時に見ることができないため、一部のタスクで問題が発生する可能性があります。ソリューションAの場合、これは友人や趣味が多数いるときに発生します。趣味をチェックするために、ユーザーは友達の間でそれぞれの場所を失い、逆もまた同様です。ソリューションBでは、各リストの目的のポイントまでスクロールして、それぞれを表示できます。
ソリューションCは、趣味と友達の妥協サイズを選択するように強制します。 Personsに1つが多く、もう1つが少ない傾向がある場合は、スペースを浪費するか、スクロールを強制することになります。ソリューションB（およびA）では、趣味と友達に最適なデフォルトのサイズを個別に選択できます。
ソリューションBは、画面の2つの領域をスクロールすることを意味しますが、それは欠点よりも利点の方が多くなります。スキャン速度を上げるために、平均して短いスクロール距離を提供します。ユーザーが友達のスキャンを停止して（または友達を完全にスキップして）趣味のスキャンを開始する場合、Aの場合のように、残りの友達すべてをスクロールして趣味を見つける必要はありません。
データの階層の深さが2より大きい場合、ソリューションAとCは問題になります（たとえば、各友達の家族を表示したい場合）。ソリューションCの場合、タブの内部にタブがあり、混乱する可能性があります。ソリューションAの場合、各友達を家族メンバーのリストで区切るため、友達を比較することが難しくなり、目的の友達をスキャンする時間が長くなり、さらにすべての友達をスキップしてまっすぐに趣味に行くことがさらに長くなります。 2つ以上の深さのページがある場合は、ソリューションBを使用して、すべてのページがアプリ内で一貫しているようにします。
FriendテーブルとHobbiesテーブルが比較的狭い場合、ソリューションBの1つのバリエーションは、2つのスクロール可能なペインを並べて表示することです。これにより、2つのペインの高さが同じになり、無駄なスペースが発生する可能性がありますが、2つのスキニーテーブルを互いに積み重ねるよりも、スペースを浪費することが少なくなります（右側）。ソリューションAおよびCは、このオプションを効果的にサポートしていません。
ソリューションBの場合、ウィンドウはデフォルトで開き、指定されたサイズのウィンドウのそれぞれのアイテムの可能性のある数に最適なサイズのペイン（Person、Friends、Hobbies）が表示されます。ユーザーがウィンドウのサイズを変更する場合、ページがスクロールバーを取得しないように、ペインを適切にサイズ変更する必要があります。スクロールする必要があるのはペインのみです。
ユーザーは常に、ウィンドウまたはページ内のペインを簡単に開いたり、閉じたり、サイズ変更したりして、コンテンツを調整できる必要があります。ほとんどのユーザーがそのコンテンツの関心を引く可能性が低い場合は、デフォルトでペインを閉じて段階的に公開することができますが、一般にすべてのペインをデフォルトで開いて、ページが提供する情報のサンプルをユーザーが取得できるようにする必要があります。上部の[人物]ペインも開いたり、閉じたり、サイズを変更したりできるため、ユーザーが望む場合は、数回クリックするだけでウィンドウ全体を友達で埋めることができます（ただし、人物のペインを維持するために、人物ペインのサイズをスリーバーに変更する場合は除きます）。ビューの名前）。これにより、ソリューションAのBに対する利点が1つなくなります。
ところで、ソリューションAまたはBのいずれかで、一度に3つ以上のペインがある場合、何が何に属しているかを示すある種のグラフィックデザインが必要です。これらの各友達の趣味または人の趣味が一番上にありますか？違いを伝えるために、フォームのインデントを使用できます。
最近まで、WebはソリューションAを使用してきました。これは、最近まで、ページ内にスクロール領域を埋め込むのが面倒だったためです。使いやすさの理由で誰も選択しなかったと思います。
Taking Panes で、ソリューションB（私がマスター/ディテールと呼ぶもの）と代替案について詳しく説明します。
各リストからいくつかの項目を表示し、残りを折りたたんでみませんか？または、アコーディオンを使用しますが、常に機能するとは限りません。
非常に包括的な質問です！
いくつかの考え：
- （有効な）観察結果の一部は、友達/趣味の数によって異なります。現在のデータ（ある場合）に基づいてこれらの数値の平均を計算しましたか？
- 異なる量のデータを使用してA/B/Cテストを実行することを検討してください。あなたはどちらの戦略も違いをもたらさないことに気づくかもしれません...またはあなたはそれらのいくつかの間のいくつかの重要な違いを見逃しました。
- おそらく、戦略Aのスクロールせずに見える範囲に注意を引くことができます（下のスケッチ図を参照）。キャッチーな装飾や見出しを使用して、リンクに注意を引くことができます。例："[First Name] 's social life"：
Cは一目で元気に見えます。 Aはネイティブに見えますが、コンテンツによっては危険に見えます。 Bは「トラップ」感があります。
プログレッシブ開示でオプションAを試すことができます。したがって、ユーザーは最初からスクロールしないページのすべてのコンテンツヘッダーを確認でき、目的のコンテンツを展開していくことができます。また、ページの読み込みが速くなる場合もあります。