dialog要素は利用者に終えてほしい作業が一つに定まる場面で使う

dialog要素は、画面の上に何かを出したいときに使うものではありません。確認、入力、選択など、利用者に一つの作業を終えてもらう必要があり、その作業の終わり方も決められる場面で使います。読ませるだけの説明、比較して選ばせる商品一覧、問い合わせの入口までdialogへ押し込むと、閉じたあとに何をすればよいかが分からなくなります。

dialogを増やすと、画面は一見整理されます。しかし、利用者が今どのpageを読んでいるか、何を確定すると次へ進むか、閉じたら何が残るかを見失いやすくなります。dialogの必要性は、重ねて表示したいかではなく、その場で終えるべき作業があるかで判断します。作業の終わりが決まらない内容は、本文や別pageで読めるようにします。

HTML 5.1のdialog要素は、利用者が作業を行うapplicationの一部を表します。show()で通常のdialogとして開く方法と、showModal()でmodal dialogとして開く方法があります。modal dialogは、ほかの画面操作を止めるため、利用者が先へ進む前に判断や入力を終える必要がある場合に限ります。

本文とdialogの役割を先に分ける

site上の情報には、最初からpageに置くべきものと、必要なときだけ出すものがあります。dialogに置く内容を決める前に、利用者が閉じたあと、どのpageのどの状態へ戻るかを決めます。pageを読んで比較したい情報と、最後に確認する情報を同じ場所へ入れません。

たとえば、問い合わせformの送信直前に、入力したメールaddressと内容を確認させる場合を考えます。送信、修正、閉じるという三つの行動が決まっているので、dialogにまとめる理由があります。一方、サービスの説明や事例を読ませるなら、dialogを閉じた瞬間に情報が消えます。本文または別pageで読めるようにしておくほうがよいでしょう。

料金の説明をdialogにだけ置く場合も注意が必要です。利用者が閉じたあと、比較した金額や条件を読み返せなければ、問い合わせ前にpageを探し直すことになります。詳しい説明は本文に残し、dialogには「この内容で進むか」の確認のように、短時間で終える操作を置きます。dialogは情報の置き場ではなく、操作の区切りとして使います。

通常のdialogとmodal dialogの違いも、見た目だけでは決めません。背後のpageを見ながら補足を選ぶなら、通常のdialogで足りることがあります。背景の操作を止めるなら、利用者に何を終えてほしいか、途中でやめる方法があるかを明らかにします。modalにして注意を引くことと、作業を正しく終えられることは別です。

modalにする前に閉じ方を決める

modal dialogは、背景を操作できない状態にします。したがって、表示する前に次の四点を決めます。

1. dialogを開く操作を一つにする。
2. 閉じる操作を用意する。
3. 実行する操作と、元へ戻る操作を分ける。
4. 閉じたあとに戻る場所を確認する。

閉じるbuttonがなく、送信だけを求めるdialogは避けます。入力を途中でやめる利用者もいます。誤って開いた場合に戻れない設計は、問い合わせを増やすための仕掛けではなく、siteから離れる理由になります。

閉じる方法を一つ決めたら、閉じたあとに何が残るかも確認します。formの確認dialogを閉じたなら、入力値が残るのか、修正するfieldへ戻れるのかを見ます。予約日時の確認を閉じたなら、選んだ候補がどこで見えるのかを確認します。dialogを閉じる操作が、利用者の作業を最初からやり直させる操作になっていないかを実際に試します。

説明用の仮例として、予約日時の候補を選ぶ画面で、確定前の確認をdialogに出すとします。候補日時、確定、選び直す、閉じるを同じdialog内へ置きます。日時の説明、料金、利用条件は前のpageにも残します。dialogだけを見れば決められるようにしながら、閉じても利用者が情報を失わない状態にします。

この仮例で、確定を押した後に何が起きるかも決めます。予約が完了するのか、問い合わせを送るだけなのか、次の確認pageへ進むのかを、button文言と画面で一致させます。「OK」のような言葉だけでは、利用者は何を確定したか分かりません。dialogのbuttonは、実行する作業が分かる文言にします。

dialogを開く前後の画面を実際に確認する

dialogは、開いている状態だけで確認しません。開く前のpage、dialogを開いた状態、閉じた後、実行した後の四つを順に見ます。dialogを開くbuttonが本文のどこにあるか、背景が操作できない状態で必要な情報を読めるか、閉じたあとに元の位置へ戻れるかを確認します。

form内で使う場合は、dialogを開くbuttonと送信buttonを区別します。確認画面を開くためのbuttonが意図せずformを送信すると、利用者は内容を確認できません。dialogで確認したあとに送信するなら、確認、修正、送信の順が画面上で分かるようにします。JavaScriptで表示を切り替えることと、formを送信することは別の操作です。

利用者が長い説明を読む必要があるなら、dialogの中だけに入れません。ページを閉じても読める本文、PDFなどの資料、別pageへのlinkを用意します。dialogは一時的な作業へ使い、重要な条件の正本を隠す場所にしません。操作を止めるほど、そこで読める情報と戻る方法を明確にします。

実装を頼んでも画面上の判断は渡さない

dialogのmarkupやJavaScriptを制作側へ頼めます。しかし、どの操作で表示するか、背景を止める必要があるか、閉じたあとどこへ戻すかは、事業の案内と利用者の行動に関わる判断です。実装を頼むことと、操作の目的を決めてもらうことは別です。

外部の制作者へ頼むときは、dialogの見た目だけを指定しません。開く条件、表示する内容、利用者が選べる行動、閉じる方法、実行後の画面を渡します。制作者はmarkupとJavaScriptを実装し、事業側は表示してよい条件と利用者へ求める作業を確認します。変更後には、依頼した人と実際に問い合わせを受ける人が同じ画面を確認します。

最初の一手は、dialogを出したい場面を一つ選び、「開く条件」「終える作業」「閉じる方法」「閉じたあとの画面」を一行ずつ書き出すことです。四つを決められないなら、dialogを増やす前に本文やpageの構成を見直します。