パスワードダイアログはポップアップまたは既存のウィンドウのどちらにあるべきですか？
たとえば、何らかの理由でパスワードの取得が必要な電子メールクライアントについて考えてみます。ダイアログは既存の、おそらく主権的な姿勢のウィンドウの一部である必要がありますか？それともポップアップする必要がありますか？同様に、Webアプリケーションでは、別のページに切り替えるか、現在のページを使用する必要があります。
私が見ているように、ポップアップの欠点は、ポップアップ（！）であり、アプリの他の部分との関連付けが解除されることです。
ポップアップソリューションは、最も人気のあるソリューションのようです。私のVPNクライアントでも、小さなダイアログを開いてから、ボタンを押してパスワードプロンプトを取得する必要があります。
インラインプロンプトの例はより制限されています。 Twitterなどの一部のWebアプリケーションは、ダイアログをスライドして開きます（http-grrを使用する場合でも）。 PuTTYはターミナルウィンドウでSSHパスワードの入力を求めますが、ここでの動機はtelnet（プロトコルがパスワードを処理しない場合）と同じである可能性があります。
頭に浮かぶ2つのシナリオがあります。
- ユーザーはログインせずにサイトのコンテンツにアクセスできます
- 資格情報が提供されるまで、アクセスは一切許可されません
Twitterは最初のものに属します。ログインしなくても、トップのツイートやユーザーのプロファイルなどを確認できます。したがって、ポップアップでユーザーをブロックしたり、別のページに強制的にログインしたりしても意味がありません。
メールクライアントは、ユーザーがログインするまでメールを何も表示しないため、ログインプロセスにページ全体を費やしています。
つまり、ユーザーがページ上の残りのデータを操作する必要があるかどうかによって異なります。
ユーザーが既にログインしていて、再度プロンプトを表示する必要がある場合は、質問がより興味深い方向に進みます（Rahulがポイントしているリンクされた質問を参照）。次に、ユーザーがログインせずにデータを安全に操作できるかどうかも異なります。
ほとんどの場合、ユーザーを中断することは理にかなっています。その場合、ポップアップが最適に機能します。
Stackexchangeファミリーのサイトを見てください。多くの異なる認可プロバイダーのサポートのため、ログイン専用のページ全体があります。認証スキームの豊富さを単純な一連のログインプロンプトで伝える方法はありません。
より単純なスキームでは、ユーザーのログインへのアクションのフローを壊さない方が望ましい場合があるため、ログインが上部にあり、ページとシームレスであるfileplanetのようなサイトがあります。
ダイアログ、つまりポップアップは、はい、いいえ、キャンセル、閉じるなど、かなり単純なアクションを必要とする情報をユーザーにすばやく表示するためにのみ使用する必要があります。ユーザーは、それ以上の方法でそれらと対話することを要求されるべきではありません。