モーダル（ウェブ）内のスクロールに関する研究？長所短所？
Web UIの観点から、モーダルウィンドウ内でのスクロールに関して、調査または定義されたベストプラクティスはありますか？特定のリンク、研究などを提供してください。
私は、モーダルが常にユーザーのビューポート内（内）に制約される必要がある学校にいます。コンテンツが長い場合、コンテンツはモーダル内でスクロールする必要があります。
ただし、同僚はモーダル内でスクロールしないようにしています。つまり、モーダルはビューポートを超えて（高さを）伸ばすことができ、ユーザーはスクロールの下でモーダルのコンテンツにアクセスします。
以下は、（モバイル/ハンドセットのWebコンテキストでの）説明のためのワイヤーフレーム比較です。 
私の質問の前に、モーダルは小さな情報ややり取りのために意図された方法でのみ使用すべきだと思いますが、これが守られていない場合があります。
編集：
可能なアプローチ。明確に1つのスクロールバーのみを維持し、各アプローチの長所と短所に対処できます： https://trello.com/card/complete-trello-api-v1/4d5ea62fd76aa1136000000c/1397
主にあなたのコントロールの及ばない理由のためにあなたの同僚に同意します。また、Trelloがモバイルアプリで使用しているソリューションにも特に反対しています。
私の推論は次のとおりです：
すべてのケースでブラウザ独自のスクロールバーを使用する場合、ユーザーが下にスクロールしたときにフォーカスのあるアイテムはそれほど重要ではありません。ほとんどの（すべての？）ブラウザーで、スクロールバーのないページでスクロールバー付きのモーダルを開き、下矢印キーまたはPageDown関数を押すと、スクロールしませんスクロールしませんユーザーがスクロールを試みる前にモーダル自体をクリック（またはタブ移動）しない限り、モーダルのコンテンツ。これは、モーダルがウィンドウの大きなパーセンテージを占める場合に特に厄介です（そのため、ユーザーがページダウンを押すと、モーダルのコンテンツがページダウンすることは合理的に予想されます）。
二重スクロールの問題を回避します。他のコメントとここでの回答で述べたように、それ自体がスクロールできるページでコンテンツペインをスクロールする場合の予想される動作は、いくぶん未定義です。これはWindows 8（Windows 8.1まで）の注目すべき問題であり、Metroアプリでマウスのスクロールホイールをスクロールすると、アプリのディスプレイ全体がネイティブに水平にスクロールされ、マウスカーソルがたまたま垂直スクロール可能なサブペインのゾーンに入るアプリ（動作がすぐにサブペインを垂直にスクロールするように変更された場合）。つまり、ユーザーは、その状況に戻るために実行したアクションを元に戻してout戻すことができませんでした。また、ユーザーがサブペインを最後までアクティブにスクロールし、その後スクロールし続ける場合（たとえば、慣性スクロールのあるデバイス上）も問題です。サブペインが最後までスクロールされたら、ページはすぐにスクロールを開始する必要がありますか？その場合、サブペインの通常の「スナップバック」効果が削除されます。
モバイルでは、タッチスクリーンの非常に、非常に端のみを使用してスクロールする癖があります。私の指は比較的固いエッジ（デバイスのエッジ）を上下に動いているので、誤って水平にスクロールすることなくスクロールを垂直軸に制限する方がはるかに簡単です（これは、特にダブルタップした場合に苦痛になる可能性があります）。ページ上のテキストの列を拡大します。水平方向にスクロールすると、列が中央から離れます）。タッチパネルの側面とスクロール可能なセクションの間に任意のギャップを導入すると（Trelloのように）、ウィンドウの端に沿ってスクロールできるという私の期待が崩れ、指を比較的異常な位置に移動する必要がありますペインをスクロールする場所。一般的に、あなたはヒットターゲットをはるかに小さくしました（モバイルデバイスの画面のエッジは比較的小さな物理的なターゲットですが、筋肉を使用できるため、実際の指でターゲットを設定するのは非常に簡単です）メモリのみ—実際にスクロールペインを処理する必要はありませんis）。
それとは別に、小さなフレームのモバイルデバイス（つまり電話）でモーダルインターフェイスを特にで開くというアイデアは嫌です。画面のスペースはすでに制限されており、画面全体を引き継ぐ各詳細ビューの予想はすでに明確になっています。小さな小さなポップオーバーディスプレイで詳細ビューを開くと、「戻る」ボタンが期待どおりの場所から（少なくともiOSでは）効果的に移動し、chrome =コンテンツの周り。
モーダルビューには常に簡単な情報が含まれている必要があります。スクロールビューは使用しないことをお勧めします。主にモーダルがほとんど迷惑であり、人々がそれらをできるだけ早く取り除きたいと思う理由が主な理由で、モーダルが非常に「キャンセル」ボタンを発音しているのはそのためです。 AppleのHIG（ヒューマンインターフェイスガイドライン）のモーダルセクションでもこれについて説明しています。
長すぎる警告メッセージを作成しないでください。可能であれば、メッセージを1行または2行で表示できるように十分短くしてください。メッセージが長すぎるとスクロールしますが、これはユーザーエクスペリエンスとしてはよくありません。 - From Appleヒューマンインターフェイスガイドライン から
モーダルは通常、非常に焦点が絞られ、コンテンツの量が少ない必要があることに同意しますが、これは常に機能するとは限りません。相互作用の多い大きなモーダルウィンドウを使用することが理にかなっている状況は数多くあります。あなたの例はその1つであり、Facebookに写真ポップアップがあり、会話も表示されます。私は多くのデザインでこのパターンを利用してきましたが、うまく機能する傾向があります。したがって、モーダルは完全ではありませんが、非モーダルオーバーレイや新しい画面への移動などの他のオプションは、常に利用可能であるとは限りません。
とは言っても、DA01は、常に1つのスクロールバーしか持たないように努めるべきだとすでに指摘しています。
スクロールバーは2つのことを行います。それは、画面外にコンテンツがあることを示すことと、そのコンテンツを表示するためのコントロールです。そのため、スクロールバーは、視覚的にもそのコンテンツに明確に関連付けられるべきだと思います。 Trelloの例は奇妙な点です。スクロールバーはウィンドウ全体をスクロールする必要があるように見えますが、これは右端にあるためポップアップのみをスクロールするためです。
私はこの状況について特別に研究しているわけではありませんが、物事に影響を与えるコントロールがその物事に近く、明確に関連していることは、インターフェース設計の基本的なルールの1つです。ビューポートの端にスクロールバーがあるものよりも、モーダルの中または近くにスクロールバーがあるモーダルの例が多くあります：Facebook写真ポップアップ、Safariリーダーモード、OSXメールアプリ作成モーダル、Gmail作成オーバーレイなど
モーエン内の唯一のスクロールバーは、モーダルの一部にあるべきだと私は思います。モーダルで「グローバル」スクロールの使用を検討している場合は、そのコンテンツ用の新しい画面を作成することを検討する必要があるかもしれません。