モーダル・イン・モーダルの
迷宮
「編集」ボタンを押すとポップアップが開く。
その中でさらに「確認」を押すと、またポップアップが開く。
スマホで見ると、閉じるボタンは画面のはるか外側にありました。
- 「画面遷移させるのが面倒」という理由でモーダルを使っている
- モーダルの上に、アラーとや別のモーダルを表示している（2階層以上）
- スマホでキーボードが開くと、モーダルの入力欄が隠れて見えなくなる
- ブラウザの「戻る」ボタンを押すと、モーダルではなくページごと戻ってしまう
ユーザーは閉じ込められ、離脱するしかなくなります。
01. 出口のない部屋
Edit Profile
Enter your details...
Are you sure?
Cannot close this on mobile...
🔒
Ajax（非同期通信）の普及により、「画面遷移せずにその場で編集」できるUIが流行しました。
しかし、それは「開発者が楽をするため」の道具ではありません。
モーダルの中にモーダルを表示する「ネスト（入れ子）」構造は、ユーザーの空間認識を狂わせます。
特に画面の狭いスマートフォンでは、複数のレイヤーが重なると「今どこにいるのか」「どうすれば戻れるのか」が完全にわからなくなります。
それが守れないなら、ページ遷移させろ。
「確認ダイアログ」程度ならOS標準のアラートを使うべきですし、複雑な入力が必要な「詳細設定」なら、独立した別ページを作るべきです。
「閉じるボタン」が画面外にはみ出して押せなくなる実装ミス（オーバーフロー）は、Webアプリにおける「監禁罪」です。
02. 「URLがある」という価値
モーダルにはもう一つ、致命的な欠点があります。
それは「URLが変わらない」ことです。
パーマリンクの重要性
「この商品の編集画面」をチャットで同僚に送りたいとします。
しかしモーダル実装の場合、URLはトップページのままです。
リンクを開いた同僚は「で、どこ？」と迷子になります。
重要な機能やコンテンツには、必ず固有のURL（パーマリンク）を持たせるのがWebの基本原則です。
戻るボタンの挙動
ユーザーは「閉じる」ためにブラウザの「戻る」ボタンを無意識に押します。
しかし、モーダルは履歴に残らないため、サイトのトップページやGoogle検索結果まで戻されてしまいます。
（History APIで制御することも可能ですが、実装コストは高いです）
03. フラットな世界へ
AppleやGoogleの最新デザインガイドラインでは、モーダルの使用は限定的です。
画面遷移を恐れないでください。スマホアプリのように、スライドして新しい画面が出る方が、
「戻れる」安心感があり、ユーザーにとっては使いやすいのです。