Gmailのような「オンページ」ダイアログが人気のあるUIソリューションにならないのはなぜですか？
数か月前、Gmailには、「オンページドッキング」ウィンドウを含む多くの新機能（...）を備えた新しいUIに切り替えるという選択肢がありました。このUIは、ユーザーがページの残りの部分を操作でき、クラシックモーダルのように邪魔にならないので、個人的に非常に便利です。
このタイプのインターフェースがWebアプリケーションでより一般的ではないのはなぜですか？
アプリケーションで社内ユーザーテストを実施したところ、90％のユーザーが「オンページドッキング」ウィンドウインターフェースを見つけて次のことができることがわかりました。
- 処理速度が速く（認知負荷が低く）、使用速度が速い
- 視覚的な中断を少なくする
パラメーターとシナリオがわからないため、ユーザーテストの結果についてコメントすることはできません。
しかし、Gmailの新しいメール入力方法について話しています。 メールを（別のウィンドウで）作成しながら、デスクトップメールアプリケーションがWebベースのメールアプリケーションよりも優れていたのは、古いメールを自由に閲覧して、参照したいコンテンツを調べることができることです（これはWebメールでも別のウィンドウを使用することで可能でしたが、完全にクリーンではありませんでした）。新しいドッキングされた電子メールメソッドを使用すると、メッセージを入力し続けることができ、他のコンテンツも閲覧できます。
また、これはfacebookと同じです。この文言を見ると、メールではなく「メッセージ」と書いてあります。ゆっくりと徐々に、メールはチャットとマージされています。保管メカニズムは、チャットやメールの場合と同じです。 Facebookではメッセージとメールは同じものです。チャットまたはメールクライアントを使用して相手に連絡すると、その相手はメッセージの受信トレイに届きます。
これが人気のあるUIソリューションではない理由に関する質問に答えるには、どのシナリオでこれが適切なソリューションであるかを尋ねる必要があります。答えはマルチタスクのようなものです。同じビューで他の人を管理しながらタスクに焦点を当てます。そのような機能が必要だと思うサービスはいくつありますか？多くのサービスは、すでにポップアップウィンドウを使用して同様の結果を達成しています。
不適切に使用すると、ユーザーの認知オーバーヘッドがかなり増加します。合理化されたアプリでは、それは理にかなっています（Gmailのように）。
ダイアログはnot modalなので、再度Composeをクリックすると、複数のメールを並行して作成できます。 。並列に作成されたすべてのメールは下書きに自動保存されます、それらはドッキング解除可能ですそしてminimizableウィンドウで、Gmailスタイルの「会話」ビューでまだ受信メールを参照して応答 。
ご覧のとおり、これらのダイアログは非常に強力です。それらが他のアプリケーションに表示されない理由は、interruption-awareアプリケーション内の並列タスクでの作業が、まれに必要とされるパワーユーザーシナリオであることです。一方、Gmailより前にこの形式のダイアログがあったサイトやアプリケーションについては知りません。私の記憶が正しければ、GMailは2012年10月/ 11月頃にこれらを入手しました。これはちょうど半年前のことです。たぶんグーグルはこれらの対話を発明したばかりで、そのアイデアはまだ他のアプリケーションに広がっていません。
「なぜこれがより広く使用されないのですか？」という質問に答えると、Googleが最初に実行する必要があるだけでなく、それ、そしてそれを正しく行いますが、テクノロジーも使用します。
非表形式データのテーブルをまだ使用しているWebアプリケーションがあり、アプリケーションは何年も変更されていません。このようなダイアログには、少なくともJavascriptが必要です。 Webアプリの再設計は非常に複雑な問題です。おそらく、「モダン」（「」がたくさんある）機能を追加することは、一部の企業にとって最優先事項とは見なされない可能性があります。それはおそらくあまりにも長い間存在していた快適ゾーンです。
触れられていないもう1つの側面は、多くのデザイナーが「モバイルファースト」に取り組み、レスポンシブなデザインにはるかに敏感になっていることです。 Gmailのメールクライアントは明らかにデスクトップ製品です。大きなウィンドウに依存しており、他の回答者が挙げたUIの課題の多くを解決するには、ユーザーが他のタスクを同時に実行できるようにするためのスペースが必要です。ただし、小さな画面用に設計することは、単一の焦点のタスクを意味します。2つのコンテキスト間で絶えず切り替えることは、ユーザーの注意にとってまったく最適ではありません。そのため、モバイルデザインに影響を受けたデザイナーは、単一フォーカスのインタラクションについてもっと考えているため、これらの同じウィンドウのダイアログを作成するというUIや技術的な課題の恩恵を受けていません。
ページ上のダイアログには大きな制限が1つあります。それらは常にページのpartを隠してしまいます。
実際のウィンドウが2つあるのとは異なり、ダイアログをブラウザのクロムの外に移動することはできません。たとえば、（Windowsのスナップ機能のように）並べて移動することはできません。それは常にどこかで何かをカバーするでしょう。おそらく、これをダイアログを独自のタブまたはウィンドウに開くだけよりも煩わしい可能性があります-Gmailは移動できません（最小化を除いて）。その下にあるものは、ブラウザーのサイズ変更やスクロールを行わずに隠しコンテンツを表示しないと読み取ることができません。 。他の段落を参照しながらメールを作成するためにそれを使用することは、最後の数段落の右半分に興味がない場合、または繰り返し最小化/復元するコンテンツである場合にのみ機能します。
標準のデスクトップショートカットとツールも適用されません。メッセージボックスをAltキーを押しながら「バックグラウンド」に移動することはできません。ヘッダーをクリックしてドラッグしても、ヘッダーは移動せず、最小化されます。タイピングタスクに焦点を合わせるときにマウスを持ち上げる必要があると、常に不格好で邪魔に感じられます-Googleはおそらく、作成ウィンドウを最小化/閉じるためのキーボードショートカットをいくつか投入していると思いますが、これらは使用しているものではないためです。に、それはヘルプドキュメントを見つけてそれらを調べることを意味するでしょう。ほとんどのユーザー（および私）は、探しに迷惑をかけることはありません。
最終的に、標準的なアプローチ（新しいブラウザタブ/ウィンドウ）はmuchより簡単に実装でき、エンドユーザーにとってより使い慣れています。