編集画面から離れるときの確認は、すべての移動を止めるためのものではありません。保存していない変更が失われる場面を見つけ、残るか離れるかを選べるようにするために使います。
この記事は編集フォームの設計・レビュー向けです。架空の社内お知らせ編集画面を例にします。状態や表示文は設計案であり、離脱率などの効果を検証した事例ではありません。
「入力したことがある」と「未保存」は違う
タイトルを変更してから元へ戻した場合、変更は残っていません。一方、タイトルを空にした場合は、文字がなくても元の保存値から変わっています。単に入力イベントが起きたか、欄が空でないかだけで判定すると、どちらも取り違える可能性があります。
この作例では、最後に保存できた内容と現在の入力内容を比較します。添付の追加・削除や公開範囲の変更も対象です。表示順を変えただけなど、保存対象ではない操作は含めません。
| 状態 | 画面内の一覧リンクを押した場合 |
|---|---|
| 開いた直後で変更なし | そのまま一覧へ進む |
| 変更を入力済み | 未保存の変更を破棄するか確認する |
| 変更を元の値へ戻した | そのまま一覧へ進む |
| 保存処理中 | 保存中と示し、完了前の移動をどう扱うか案内する |
| 保存に失敗 | 入力を残し、未保存の扱いを続ける |
保存成功時は「送信した値」を保存済みの基準へ更新します。保存中にも編集できる画面なら、その間に追加された変更まで保存済みにしないことが必要です。この例では保存中の編集を一時的に止める案にし、操作再開の表示まで確認します。
確認文は、失うものと選択肢を揃える
画面内のリンクを押したときは、次の確認を出す案にします。
変更を保存せずに離れますか？
この画面で変更したタイトルと本文は保存されません。
［編集を続ける］［変更を破棄して離れる］
対象には実際の未保存項目を反映します。「はい」「いいえ」だけにせず、押した後の状態を操作名へ含めます。「保存して離れる」を追加するなら、保存エラー時は移動せず、その場で修正できる必要があります。
独自の確認ダイアログには、文言以外の動作も必要です。W3C APGは、開いた際の内部へのフォーカス移動、ダイアログ内のTab移動、閉じた後のフォーカスの扱いを説明しています。Dialog (Modal) Pattern
この例では最初に「編集を続ける」へフォーカスを置き、Escapeでも編集画面へ戻します。破棄しなかったときは、移動を始めたリンクへ戻す案です。画面の背後だけ操作できてしまう状態も確認します。
タブを閉じるときは同じ表示を約束できない
ブラウザを閉じる操作と、アプリ内の一覧リンクは分けて設計します。MDNによると、beforeunload の確認文はブラウザが定めたもので、ページ側から自由に指定できません。また、特にモバイルではイベントが発火しない場合があります。必要なときだけリスナーを登録することも勧められています。Window: beforeunload event
したがって「タブを閉じても必ず確認が出る」という仕様にはしません。未保存時の補助として使い、長文を扱うなら下書き保存も別に検討します。下書きを設ける場合は、保存場所、保存時点、復元できる期限、共有端末での扱いを決めます。警告を付けたことと、入力を復元できることは別です。
自動保存があっても、未保存の時間はある
自動保存を採用した場合、「保存中」「保存済み」「保存できませんでした」を区別します。通信が完了する前に保存済みと表示すると、安心して閉じた利用者の変更が失われる恐れがあります。
複数のタブで同じ内容を編集するなら、別タブの変更を上書きする問題も残ります。離脱確認だけで解決しようとせず、競合時に再読み込みや比較を案内する仕様を別に決めます。
保存と移動を組み合わせて試す
1文字変更する、元に戻す、全削除する、添付だけ変更する、保存を失敗させる、という順で一覧リンクを押します。さらにタブを閉じる操作やモバイルのアプリ切り替えも確認します。確認が出た回数だけでなく、戻ったときに入力が残るか、保存成功後に不要な確認が出ないかまで見ます。
保存状況の表示は処理中の表示、保存済みデータそのものを削除する場合は削除の確認ダイアログへ分けて考えられます。