§07-01
In-app notification center
ベルアイコンから通知の一覧を開いて確認する。
見逃した通知をあとからまとめて追える。メンションや承認依頼など、種類の違う知らせが複数の機能から届くサービスに向く。
実装のポイント未読数はサーバーの集計を正とし、ドロワーを開いた時点ではなく項目表示や操作で既読化する。新着は aria-live=polite で控えめに読み上げる。
- 状態管理
§07
Notifications
§07-01
ベルアイコンから通知の一覧を開いて確認する。
見逃した通知をあとからまとめて追える。メンションや承認依頼など、種類の違う知らせが複数の機能から届くサービスに向く。
実装のポイント未読数はサーバーの集計を正とし、ドロワーを開いた時点ではなく項目表示や操作で既読化する。新着は aria-live=polite で控えめに読み上げる。
§07-03
操作結果を短時間だけ画面端に表示する。
保存完了や送信成功など、作業を止めずに結果だけ伝えたいときに使う。取り消しの導線を添えれば確認ダイアログを減らせる。
実装のポイント読み上げは aria-live=polite の領域に任せ、エラーなど操作が必要なものは自動で消さない。Undo 付きは表示時間を長めにし、ホバー中はタイマーを止める。
§07-05
取り消せない操作の前に確認ダイアログを出す。
誤クリックによる削除や解約を防ぐ。やり直せない操作に限って使い、頻繁な操作に付けると確認が形骸化する。
実装のポイント取り消せない操作は対象名や固定文字列の入力で確認させ、一致するまで実行ボタンを無効にする。初期フォーカスはキャンセル側に置く。
§07-06
通知の種類と送り先を表で個別に切り替える。
利用者が通知の種類ごとに受け取り方を細かく選べるようにする。通知が多すぎて全部切られてしまう前に調整の余地を与える。
実装のポイント設定は「イベント|チャネル」の合成キーで平坦に持つと更新が単純になる。各スイッチには「コメント・メール」のように行と列を合わせた名前を付ける。
§07-07
ブラウザを閉じていても OS 経由で通知を届ける。
サイトを開いていない利用者にも更新や返信を知らせられる。メッセージの返信や締切のように即時性が価値になる通知に向く。
実装のポイントブラウザの許可ダイアログは一度拒否されると再表示できないため、先に自前の事前確認を出し、同意後に Notification.requestPermission() を呼ぶ。
§07-08
通知を日次や週次でまとめてメールで送る。
細かい通知を期間ごとに一通にまとめ、受け取る側の負担を減らす。更新の多いサービスで、頻繁な通知による配信停止を防ぎたいときに向く。
実装のポイント集計はイベントごとに送らずバッチで期間単位にまとめ、送信頻度と配信停止をユーザーが選べるようにする。前期間との差分を添えると読む動機になる。
§07-10
自分や関係者の行動を時系列で並べる。
誰がいつ何をしたかを後から追えるようにする。共同作業の変更履歴や、自分の操作の振り返りに向く。
実装のポイントイベントは種別・対象・時刻の正規化した形で記録し、表示文言はクライアントで組み立てる。相対時刻は time 要素の datetime に絶対時刻を持たせる。
§07-12
新機能や変更点を小さな窓で知らせる。
使っている画面を離れずに最近の変更を確認できる。更新頻度が高く、気づかれずに終わる機能が多いサービスで効く。
実装のポイント最後に見たリリースの ID を保存し、それより新しい項目がある時だけドットを出す。ポップオーバーは Esc で閉じ、閉じたらトリガーへフォーカスを戻す。
§07-13
サービスの稼働状況と障害情報を表示する。
障害や遅延が起きているかをサービス側から先に知らせ、利用者の原因探しを省く。問い合わせの殺到を抑え、復旧見込みを共有する役にも立つ。
実装のポイントステータスは本体と別系統のサービスから取得し、本体障害時でも表示できるようにする。状態変化は role=status で通知し、色だけでなく文言で伝える。