第17章　人間は、押したあとに反応を待つ

ボタンを押したあとに何も変わらなければ、押せなかったのか、処理中なのか、失敗したのか分かりません。利用者はもう一度押し、前の画面へ戻り、操作を諦めるかもしれません。

必要なのは、派手なアニメーションではありません。操作を受け付けたこと、いま何を待っているか、最後に何が起きたか、次に何ができるかを伝えることです。

この章では、保存と申し込みを例に、操作後の時間を順に見ていきます。

17.1 ボタンがへこむことと、保存できることは別

マウスで押している間にボタンがへこんだり、指を触れた瞬間に色が変わったりすることがあります。これは「いまこのボタンへ触れている」という反応です。データが保存できたことまでは表しません。

保存には、少なくとも次の状態があります。

保存中は、押せたか分からない状態ではありません。処理が続いていることを文字で示します。何を保存しているのかも分かるようにします。

完了メッセージは、どの内容が保存されたか、次に何ができるかを理解できる場所へ置きます。短時間で消える通知だけでなく、必要なら更新時刻や履歴からも確認できるようにします。

保存後にもう一度編集すれば、状態は再び変わります。

一度「保存しました」と表示したままにすると、最新の変更まで保存済みだと誤解されます。内容が変わった時点で、状態表示も「未保存」へ更新します。

アニメーションは、これらの変化をつなげて見せる方法の一つです。動きを止めても、「保存中」「保存しました」「未保存」という意味が文字と最終状態から分かるようにします。

申し込みの送信に数秒かかるとします。押したあとに画面が変わらなければ、利用者は押せなかったと思って、もう一度押すかもしれません。

画面側では、送信を受け付けた直後に処理中だと伝えます。

ボタンを押せない状態にする場合も、薄い色だけでは理由が分かりません。「申し込み中」のように現在の処理を表示します。通信を中止できるなら、その方法も示します。

しかし、画面側で再操作を防ぐだけでは十分ではありません。通信が途中で切れ、利用者がページを開き直して再送する場合があります。

注文や決済では、同じ依頼を区別する番号などを使い、再送されても二重処理にならない仕組みが必要です。画面の「処理中」と、サーバーが一度だけ処理する仕組みは、別々の対策です。

結果が届いたか分からない場合は、すぐに同じ注文を作り直させません。「結果を確認しています」と伝え、すでに処理されたかを調べます。検索のように繰り返しても影響が小さい操作なら、すぐ再試行できる方が分かりやすい場合もあります。

くるくる回る印は、処理が続いていることを伝えられます。しかし、何割終わったかは分かりません。

何を待っているのかを「会場情報を読み込んでいます」のように書きます。長く続く場合は、中止や別の作業へ進む方法も考えます。

全体量を測れる処理なら、実際の進み具合を示せます。

根拠のない進捗率を表示すると、99 パーセントで長く止まったときに、いつ終わるかを予想できません。測れるものだけを進捗として示します。

スケルトン表示は、文章や画像が入る場所を薄い形で先に示す方法です。配置の予告にはなりますが、処理の完了率は示しません。第6章で見たように、繰り返す光を付けなくても「読み込み中」という意味は残せます。

「保存できませんでした」だけでは、次に何をすればよいか分かりません。通信が切れたなら再試行、入力内容に問題があるなら修正、権限がないなら権限を持つ人への依頼など、原因によって次の行動は変わります。

失敗したときにも、入力した内容を消しません。問題のある入力欄の近くへ、理由と直し方を表示します。画面の上部へエラーのまとめを置く場合は、各項目へ移動できるようにします。

サーバーの確定を待たず、手元の画面だけを先に成功したように変える方法もあります。すぐ反応して見えますが、実際の処理が早くなったわけではありません。失敗したら表示を戻す、未送信として残す、再試行できるようにする、といった回復が必要です。

金銭、在庫、権限のように、成功したという誤表示の影響が大きい操作では、確定前に成功を見せることへ慎重になります。

画面に「保存しました」と表示しても、画面を読み上げて使う人へ自動で伝わるとは限りません。通常の完了は、現在の操作位置を奪わず、状態メッセージとして読み上げられるようにします。

すぐ対応が必要な失敗は、より強い通知として伝えます。ただし、すべての更新を警告にすると、読み上げが何度も割り込んで作業を邪魔します。通常の完了と、いま直す必要がある失敗を分けます。

見た目の色、実際に操作できる状態、支援技術へ伝わる状態は別々に作ります。色だけを変えたり、画面の端へ文字を追加したりするだけでは、全員に状態が届くとは限りません。

操作後の反応は、「押せた」という一瞬だけでは終わりません。受付、処理中、成功または失敗、次にできることまでを、時間の順に伝えます。

操作の結果が分かっても、うまくいかなかった理由を利用者のせいにすれば、同じ失敗を繰り返します。

次章では、失敗を防ぎ、起きたあとに安全に戻れる画面を考えます。

W3C WAI, “Understanding SC 4.1.3: Status Messages.” 操作位置を移さずに、処理結果を支援技術へ伝える方法の解説です。
WAI-ARIA 1.2, “status role.” 通常の状態メッセージを伝える役割の仕様です。
WHATWG, “The progress element.” 測定できる進捗と、終了量が不明な状態を表す HTML 要素です。