最近のアプリケーションではダイアログを避けるべきですか？
私が設計した最後のシステムでいくつかのダイアログを使用しました。アプリケーションは多くのデータベーステーブルを備えたビジネスアプリケーションであり、データを表示するために多くのデータグリッドを使用しました。テキストCreate new itemまたはCreate new groupまたはグリッドにリストされているものを含むボタンをデータグリッドの下に配置するのが一般的でした。言い換えると、ボタンはテーブルに新しい行を作成するために使用されました。
ユーザーがボタンをクリックすると、テキストフィールドと下部に送信ボタンを備えた新しい（モーダル）ダイアログが作成されました。しかし、これは本当に推奨される方法ですか？または、モーダルダイアログなしでアプリケーションを設計するにはどうすればよいですか？
これがWebアプリケーションだった場合、おそらくフォームを含む新しいWebページにユーザーを送りましたが、それはモーダルダイアログに似ています。
最近のアプリケーションではダイアログを避けるべきですか？そして代替案は何ですか？
原則として、必要な場合にのみダイアログボックスを使用してください。直接操作、入力、またはインプレース編集を使用することをお勧めします。ユーザーは、プライマリウィンドウに表示されるデータオブジェクトを直接操作します。オブジェクトを作成する場合、その場で編集する方法には次のいずれかがあります。
オブジェクトを作成し、フィールド値を入力するためにデータグリッドに空白行を追加する挿入ボタン、
データグリッドの下部（または他の場所）の永続的な空白行–ユーザーが値を入力すると、アプリは新しいオブジェクトを作成します。
SOでこれらの2つのアプローチを比較します。「 テーブルビュー、追加ボタン、または空白行に挿入する場合、何が最適ですか？ 」
どちらのインプレイス編集アプローチと比較しても、ダイアログボックスには次の欠点があります。
追加学習。アプリにウィンドウを追加し、タイトルバーとボタン（[OK]や[キャンセル]など）とフィールドを追加します。フィールドは、親データグリッドに既に存在することが多いですが、配置が異なります。これは、ユーザーが学ばなければならないことを徐々に増やします。
注意シフト。ダイアログをポップアップするには、ユーザーが新しいものに注意を向ける必要があります。これは、特定の再配置コストがかかり、ユーザーがデータの制御にあまり気がつかないようにします。
追加のクリック。ダイアログボックスを実行して閉じる必要があります。これには、少なくとも1つの余分なボタンクリックが必要です。対照的に、インプレイス編集では、ユーザーは保存する前に複数のオブジェクトを作成できます（保存が自動でない場合）。
モダリティ。モーダルダイアログボックスが必要な場合は、ユーザーの柔軟性を取り除き、ユーザーに作成を完了するか、中止するよう強制します。作成を完了するためにアプリの他の場所から追加の情報が必要な場合は、行った作業を破棄する必要があります。
仕事の損失のリスク。 [キャンセル]ボタンを誤って1回クリックすると、ユーザーが行ったすべての入力が元に戻り、ダイアログが閉じて、ユーザーに最初からやり直させます。複数入力のワンクリック損失は、適切に設計されたプライマリウィンドウの特性ではありません。さらに、プライマリウィンドウは通常、元に戻すをサポートしています。
ダイアログは、パラメータを必要とするアトミックアクションに使用する必要があります。つまり、技術的または論理的にアクションを完了するために、アプリがユーザーからの特定の入力を必要とする状況です。たとえば、オブジェクトを作成するときにデフォルトにできないフィールド値が必要な場合は、ダイアログを使用することをお勧めします。
このような作成ダイアログには、必須フィールドのみがあり、オプションフィールドはないはずです。ユーザーにオプションのフィールドをデータグリッドに戻させます。モダリティと損失のリスクがあるため、対話はできるだけシンプルにする必要があります。おおまかな目安として、ユーザーは約20〜30秒で入力を完了することができるはずです。これは、やり直す必要がある許容できる量です。
Webアプリでは、別の入力ページはモーダルダイアログボックスとほぼ同じであり、ユーザーが他のことをする前にトランザクションを完了するかキャンセルすることを強制されます。これは、多くのWebアプリに、直接操作するデスクトップ同等の流動的な感触と比較して、不格好な「間接的な」感触を与えます。
Mac OS Xには、仮想デスクトップ（およびデュアルスクリーンセットアップ）であるスペースがあります。マルチウィンドウアプリはSpacesではうまく機能しません。モーダルダイアログは依然として間違ったデスクトップにポップアップする傾向があります！
代わりに、親ウィンドウにマウントされているシートを使用すると、同じ方法でユーザーを悩ませることはありません。
うまくいくこともあれば、うまくいかないこともありますが、あなたが提案した例では、ajaxの更新によって新しい行がテーブルに配置される可能性があるようです。新しいデータ行/グリッドのダイアログボックスを使用し、次に送信ボタンを使用したことを示しました。はっきりしないのは、これが編集可能なコンテンツの確認ダイアログなのか、それとも単なるイエス/ノーなものなのかです。また、ユーザーがコンテンツごとに編集/追加して、新しい行をデータグリッドに追加することも明確ではありません。
ダイアログボックスなしで、ページ内でユーザーが新しい行を作成/編集してから更新できるように思えます。何らかの理由で新しいパネルを開く必要がある場合、実際には新しいブラウザーインスタンスを開かないため、一般的にはスタイルの良いモーダルがダイアログボックスよりも優先されるため、ユーザーをページから離すか、コントロールを削除しますそれらから。ほとんどのUXの調査では、「戻る」ボタンがブラウザ制御メカニズムを完全に理解できる唯一の要素であることが示されています。ユーザーに応じて、ポップアップやタブ付きのUIもヒットしたり失敗したりします。
デメリットも記載されていると思います。しかしながら、私はあなたが対話を却下することができる、またはすべきであるとは全く考えていません。
インライン編集/作成（Excelの場合と同様）は、大量のレコードをすばやく入力する場合や、非常に特定の値を編集する場合に便利です。
ただし、テーブルリストに表示されているよりも詳細なレコードを保存する必要がある場合は、最適ではない可能性があります。たとえば、人物の名前、住所、生年月日が表示されます。ただし、新しいレコードを入力するときは、社会保障、出生地、親との関係、司法のステータス、またはその他のさまざまなオプションも含めることができます。
ダイアログは、リンクされた情報のドロップダウンボックスを提供し、フィードバックを提供し、日付ピッカーまたは他のui要素を入力することで、UIをより簡単にするのにも役立ちます。それらのほとんどは、UIを大幅に混雑させずにインライン編集に入れることはできません。
情報を保存するアクションをデータ入力から切り離すことは単に負担になるだけではなく、レビューの構造化された瞬間を提供することも役立ちます。すべて記入しましたか、それでいいですか？たとえば、オンラインで何かを注文するとき、私はそのオプションがとても好きです。情報を段階的に収集して記入することができ、実際に完了する前に決定の明確な瞬間があります。
そのため、フィールドの数、提供される情報のタイプ、情報が収集される構造など、コンテキストに依存すると思います。私は一般的に対話を避けることはお勧めしません。彼らがどこに適しているか、どこが適していないかを考えてください。
モーダルか否かについては、非モーダルは混乱を招く可能性があります（ダイアログが他の人の背後に隠れて失われたり忘れたりする可能性があるため）、モーダルはそれを苛立たせます（あなたがしていること以外に何もできないため）。モーダルダイアログは最適な方法ではありませんが、もう一度盲目的に回避するのではなく、適切な場所で使用してください。
画面が大きくなると、テーブルの概要の横にダイアログ（または詳細ビュー）を配置するオプションになる場合があります。繰り返しになりますが、スマートフォンの増加に伴い、多くの画面が小さくなり、同時にいくつかのセルしか表示されていないときにテーブルを編集するとうまくいかないため、ダイアログの重要性が高まっています。