モーダルと非モーダルダイアログ：
用いるべき場合とそうでない場合
モーダルダイアログはユーザーを遮って何かしらの行動を要求するものである。これはユーザーの注意を重要な情報に向けてもらうことが必要な場合には適している。
まず、モーダルダイアログと非モーダルダイアログの違いをさらに理解するために、「ダイアログ」と「モーダル」という用語の意味するところから考えてみたい。
ダイアログ（＝dialog。dialogueともいう）とは、2人の人の間で交わされる対話のことをさす。ユーザーインタフェースにおけるダイアログとは、システムとユーザーの間の「対話」であり、ユーザーへの情報や行動の要求であることが多い。
ユーザーインタフェースのモード（＝mode。モーダルはその形容詞）とは、同じシステムがやや異なったユーザーインタフェースになった特別な状態のことである。モードによって利用できるコマンドが違うこともあるし、同じコマンド（または行動）でも、システムのモード次第で、結果が違ってくることもある。つまり、モードが違うと、同じ入力をしても異なった結果になるといえる。たとえば、コンピュータはCaps Lockが有効になっていると、特別なモードになる。すなわち、入力された文字がすべて大文字で表示されるようになる。Caps Lockが有効になっているかいないかで、文字入力の効果が変わってくるというわけだ。また、Microsoft Wordは、変更履歴モードにすると、それ以前におこなった編集やコメントがすべて表示されるようになる（一方、デフォルトの標準モードでは、編集やコメントの履歴は記録されないし、表示されることもない）。
「モード」や「ダイアログ」について、以上のような理解があれば、モーダルダイアログの定義は容易だ。
定義：モーダルダイアログとは、メインコンテンツの上に表示されるダイアログで、ユーザーにインタラクションを要求する特別なモードにシステムを移行させるもののことである。このダイアログは、ユーザーがそのモーダルダイアログに明確にインタラクトするまで、メインコンテンツを無効にする。
モーダルダイアログはうちの猫のEmmaのようだ。彼女は毎朝7時にニャアと鳴いて、私に餌を求めてくる。私は寝ようとするか、朝の支度を始めようとするのだが、うちの猫は今度は私の正面に回り、私が彼女のほうを見るまで、さらに大きな声でニャアニャアと鳴き続けるのである。私が自分のタスクを終わらせたいと思えば、そのときにやっていることを即やめて、彼女の対応をするしかない。彼女は我々が眠っている夜中の3時にこの行動をしようとすることもある。もしもお客さんがうちに泊まっているときなら、うるさいし、恥ずかしい思いをすることになるだろう（うちの猫のために言わせてもらうと、餌をもらえさえすれば、彼女はとてもおだやかで、かわいらしく、愛想の良い性格である）。
対照的に、非モーダル（モードレスともいう）なダイアログやウィンドウは、メインコンテンツを無効にしない。すなわち、ダイアログボックスが表示されても、ユーザーインタフェースの機能が変わることはない。したがって、ユーザーはそのダイアログを開いたままで、メインコンテンツと引き続きインタラクトすることが（さらに、もしかすると、そのウィンドウを移動させたり、縮小することなども）可能である。猫のたとえを続けると、非モーダルダイアログとは、食事中のダイニングテーブルのそばに辛抱強く座り、食べものの切れっぱしがテーブルから落ちてくるわずかな可能性を待っている猫のようなものである。うちのEmmaもこうだと、私も落ち着いて食べられるし、会話もできて、夕食を楽しめるのだが。だが、私にできるのは、彼女を完全に無視するか、夫がするように、食事の終わりそうな頃、テーブルの下にいる彼女に食べ物を少しだけ、こっそりあげることである。（おわかりだとは思うが、彼女はかなり丸々としている）。
モーダルダイアログの本来の意図は、エラーなどの、ユーザーの行動が即、求められるシステムの状態を警告することだった。こうした場合には、エラーの修正のためにユーザーを遮ることが不可欠だったからである。そのため、インタフェースで最も目がいく、画面の真ん中にダイアログボックスを置くことで、効果が上がるようにしたのである。ユーザーの注意を引いて、問題を認識させ、それをすぐに修正させる、ということが、こうしたモーダルダイアログの大きなメリットだったのである。
しかしながら、こうした本来の利用方法は変化してきている。最近のモーダルなダイアログやウィンドウは、正当な理由の多少にかかわらず、ユーザーの注意を引くためにもっともらしく使われているからである。
モーダルダイアログのデメリット
モーダルダイアログに起因する一般的な問題には以下のようなものがある：
- 即時対応を必要とされる。モーダルウィンドウは本質的に強制的なものなので、ユーザーはその場での対応を求められる。このダイアログは、システムのモードを変えるので、ユーザーはそのダイアログに応答しないと、今やっていることを続けられないからである。
- ユーザーのワークフローを中断させる。モーダルダイアログはユーザーを最初の段階でおこなっていたタスクから遠ざけるので、割り込みが入るたびに、時間と労力の損失となる。というのも、ユーザーはそのダイアログに対応するだけでなく、本来のタスクに戻ったら、今度は、コンテキストの復元にも時間を使うことになるからである。
- 何をしていたかをユーザーに忘れさせる。コンテキストが別のタスクに切り替わると、モーダルダイアログによって増える認知負荷のせいで、本来のタスクに関わる細かい部分をユーザーが忘れてしまう可能性がある。もしそうだとしたら、本来のタスクのためのコンテキストの復元はますます難しくなるだろう。
- ユーザーに、ダイアログを退ける、という別のゴールを持たせ、それに取り組ませることになる。ダイアログが表示されると、ダイアログを読んで、理解し、そのダイアログについての決断を下す、というステップがユーザーのワークフローにさらに追加される。こうしたインタラクションコストの増加は、そのダイアログが正当なもので、実際に重要な情報を含んでいるのでない限りは、ユーザーをうんざりさせる可能性が高い。この点については後で詳しく説明する。
- 背景になったコンテンツをブロックする。現在のウィンドウの上にダイアログが出ると、重要なコンテンツを覆ってしまうので、コンテキストがなくなってしまう。その結果、ちょうど覆い隠されてしまった情報に関連した質問をダイアログがしてきた場合には、そのダイアログへの応答はさらに難しくなる。
以上のデメリットから、モーダルダイアログはそれほど重要ではない活動に利用されると問題になってくるだろう。
モーダルダイアログ利用のガイドライン
モーダルダイアログはどんな場合に利用するといいのだろうか。モーダルダイアログが本当に必要なのかどうかを判断する助けになるガイドラインは以下の通りである。
1. モーダルダイアログは、重大なエラーを防いだり修正したりする手段など、重要な警告のために利用しよう。
ユーザーの作業が失われたり、ある行動によって壊滅的で取り返しのつかない結果になる恐れがある場合にはいつでもユーザーを遮って、大惨事を避けよう。
モーダルダイアログに相当するほど、エラーが深刻なものであるかを判断するには、以下のことを考えるとよい：
- タスクからユーザーの注意がそれてしまうと、その問題の解決は容易になるだろうか、それとも難しくなるだろうか。できれば、人為的なエラーはそれが起こる前に防ぐに越したことはない。しかしながら、エラーが起こってしまった後は、そのエラーメッセージはモーダルダイアログの中ではなく、メインコンテンツ内に表示したほうが、エラーの修正はしやすい。たとえば、入力フォームのエラーはそのページのエラー発生箇所の横で伝えられるべきである。そうすれば、ユーザーはその問題を解決しながら、エラーメッセージの参照が可能だからだ。しかし、コンピュータを10秒後に再起動することについてのユーザーへの通知は、ユーザーが確実にメッセージに気付けるようにモーダルダイアログに表示してもいいだろう。
- そのエラーは不可逆的か。エラーが不可逆的だと、情報が失われてしまう結果に終わることが多く、タスクが複雑で非常に時間がかかる場合には、特にダメージとなる。たとえば、アイテムをカートに追加しなかったというのは、ECビジネスにとっては不運なエラーだろうが、微妙な通知にユーザーが気づかなかったとしても、このエラー自体はそのユーザーにとっては取り返しの付かないものではない（本当にそのアイテムが欲しければ、もう一度その行動をおこなえばいいからだ）。一方、ファイルを上書きしてしまったり、何百枚ものスライドに対する変更が保存されなかったというのは、どちらも不可逆的な行動である。したがって、割り込みが必要になるし、そうすると歓迎されることが多いだろう。
2. モーダルダイアログでは、現在のプロセスを続けるのに不可欠な情報の入力を要求しよう。
情報が不足しているために、システムがユーザー主導型プロセスを継続できない場合には、モーダルダイアログによってユーザーにその情報を求めることが可能である。
以下に示すEtsyは、ユーザーがお気に入りリストにアイテムを保存しようとすると、モーダルウィンドウを使ってユーザーを遮り、ログイン情報を要求する。
3. モーダルダイアログは、複雑なワークフローをシンプルなステップに分解するためにも利用可能である。
ワークフローというのは、速ければいいというものではない。時間がかかり、精神的（そして、感情的）にも影響を受けるタスクの場合には、一度にたくさんの情報を求められると圧倒されてしまう可能性があるからだ。そういう場面では、モーダルダイアログを使って、複雑な情報をよりシンプルで理解しやすいかたまりに分解するとよい。ウィザードは、モーダルダイアログのこうした利用方法の一般的なものといえよう。
しかしながら、モーダルのステップが複数になるだけで、メインタスクから離れてしまう時間は長くなるので、そもそも何をしていたかをユーザーが忘れてしまう可能性は高くなる。したがって、モーダルに複数のステップが必要な場合には、前進しているという感覚をユーザーに与えるとよい。そうすれば、ユーザーもすぐに投げ出したりはしないだろう。とはいえ、最初から複数のステップが必要な場合には、1ページ全体をそれ専用にしてもいいかもしれない。
4. モーダルダイアログでは、ユーザーに提供してもらうことで、彼らの作業や労力が著しく減らせる情報を依頼しよう。
モーダルが効果的なのは、要求したり、表示した情報が、関連性がある、あるいは、そうした情報によって現在のタスクを効率的に達成できるようになる場合である。
不動産サイトのZillow.comでは、アカウントを持っていなかったり、自分の不動産エージェントがいなくても、物件リストの閲覧が可能である。しかしながら、リストのエージェントに連絡を取ろうとすると、サイトにはモーダルダイアログが表示され、既にエージェントがいるかどうかを聞かれる。この情報はすぐ後のステップ（リストのエージェントに連絡を取ること）に絶対に必要というわけではない。しかし、今後のインタラクションを効率的なものにするには有益である。このダイアログではプログレッシブプロファイリング（訳注：徐々にプロフィール情報を集めること）をおこなっているので、一度に表示される質問は1つで、内容も答えやすい。こうした質問は答えるのにあまり労力が要らない、関連性のある詳細情報が中心である。
プログレッシブプロファイリングのコツは、ワークフローに対するユーザーの期待に沿うことである。つまり、現在のタスクに関連があるか、役に立つ場合にのみ、割り込みは有益なのである。
5. 現在のユーザーフローに関係のない、不要不急の情報のためにモーダルダイアログを使ってはならない。
先ほど説明したように、モーダルダイアログにはさまざまなデメリットがあり、ユーザーのコストとなる。こうしたコストを正当化できるようにするには、モーダルダイアログはタスクへの関連性が高く、内容も重要である必要がある。ユーザーのゴールに直接関係ないモーダルダイアログは、不快なものだと認識され、その企業への信頼を損なう可能性もあるだろう。
また、不要不急の情報がモーダルダイアログのような優先度の高いフォーマットで表示されていると、このフォーマットがまた出てきても、ユーザーが注意を払わなくなってしまう。イソップ物語の「オオカミ少年」のようなものだ。繰り返し人を欺いたために、本当に必要なときには誰も信じてくれないことになる。
一般に信じられているのとは反対に、メーリングリストへの登録というのは、ビジネスのきっかけを作り出すには重要だが、ユーザーにとっては絶対に必要というわけではない。最近、実施したWebユーザビリティ調査で、Eメールニュースレターへの登録に関するモーダルダイアログを心の底から馬鹿にするような発言を我々は聞かされた。
下：ボードが選択されると、Wayfairはモーダルダイアログを使って、ユーザーのボードに友達を招待するように言ってくる。しかし、この行動はユーザーにとっては必須ではないし、アイテムをピンすることのインタラクションコストも増加する。
6. 決済フローのような、リスクもリターンも大きいプロセスをモーダルダイアログで中断してはならない。
決済というのは、ユーザーとビジネスの双方にとって、大きなリスクとリターンをもたらしうるプロセスである。ユーザーの希望は、そのプロセスが確実にシームレスで、安全で、エラーがないことだが、ビジネス側の希望は、ユーザーが購買決定を確実に遂行してくれることだからだ。したがって、必要性に欠けるモーダルダイアログは、良くて、ユーザーの注意をそらすことになるし、最悪だと、ユーザーの信頼を損なうことになるだろう。
旧バージョンのWalmart.comは、モーダルダイアログで、決済中のユーザーにログインを求めていた。このモーダルは、良くて、ユーザーの注意をそらし、単にゲストとして決済を済ませるのではなく、Walmart.comのパスワードを探すという本格的な旅に彼らを送り出してしまうものだが。最悪だと、アカウントを作ることを強制されているようにユーザーを感じさせ、そのために購買決定に悪影響を及ぼすことになるだろう。Walmartはその後、Webサイトのデザインを変更し、このモーダルダイアログを削除してしまっている（しかし、そのデザイン変更では、ゲストとして決済するプロセス自体も完全に削除されてしまったので、今度は決済のために、ユーザーはアカウントを作らなければならなくなってしまった。これは正直、不愉快な変更としかいえない）。
7.モーダルにない情報を別の情報ソースから探さなければならないような複雑な意思決定に、モーダルダイアログを使わないようにしよう。
ユーザーと直接おこなう短い対話のためにモーダルダイアログは利用すべきである。もし、モーダルの要求するものが、複雑な調査や別の情報ソース（これはモーダルで塞がれている可能性もある）の参照なら、モーダルダイアログはそのインタラクションにふさわしいUI要素ではないといえよう。
代わりに非モーダルダイアログを考えよう
そのタスクが絶対的に重要というものではない状況では、非モーダルダイアログが適切なこともある。非モーダルダイアログはモーダルダイアログほど攻撃的でない。ユーザーは自分の活動を続行することが可能だし、そのダイアログが自分に関係なければ無視することもできるからだ。しかしながら、非モーダルダイアログもタスクの邪魔になることはある。とりわけ、画面上の重要な情報を見えなくしてしまう場合や、そのダイアログでかなり複雑なインタラクションを求める場合にはそうだ。
また、非モーダルダイアログのなかには、デバイスやブラウザが変わると、移行がうまくいかないものもある。たとえば、デスクトップのChromeにある非モーダルウィンドウは、iPhoneのSafariでは、以下のMeowbox.comのように、モーダルウィンドウになってしまうことがある。
非モーダルウィンドウが有益なのは、ユーザーがある情報にアクセスするのに、モードの切り替えを素早くおこなう必要がある場合だ。たとえば、Google Mailは、非モーダルウィンドウを新規メッセージの作成手段のデフォルトにしている。そのため、ユーザーはこのウィンドウを開いたまま、作業を継続できるし、作成したEメールを内容を損なわずに最小化することも可能である（あるいは、そのウィンドウを最大化して、モーダルウィンドウにするオプションもある)。このようにビューが分割されるので、ユーザーは、以前のEメールや、現在のEメールの作成に役立つ、追加の情報を見つけ出すことができる。
結論
モーダルダイアログと非モーダルダイアログは、どちらも有用であり、ユーザーの関与を求めたり、促したりするものである。この2種類のダイアログのどちらを選ぶかということに関しては、ユーザーのコンテキストとワークフローについてよく考えるとよい。ユーザーに対して不必要な邪魔をしたり、彼らのワークフローを中断することは避けなければならない。ユーザーが楽に問題を解決し、ゴールを達成できるようにしよう。企業の希望するところが、ビジネスゴールに向かって持続的に進歩していくことなら、デザイン決定で優先すべきはユーザーのゴールだからだ。
モーダルダイアログに関しては次の点をよく考えよう。それは、邪魔されるのが好きな人などいない、ということだ。しかし、そうしなければならないというのなら、そのコストに必ず見合うものにしよう。
