チャットを受信しても、すぐ「既読」にしなかった話

チャットを受信しても、すぐ「既読」にしなかった話

記事
IT・テクノロジー
今日は、Next.jsで開発しているマッチングサービスのチャットを確認した。送受信そのものより、気になったのは「いつ既読にするか」だった。

画面を開いたまま別のタブへ移動していても、メッセージは届く。長いやり取りなら、新着が画面の外にあることもある。データを受信しただけで既読にすると、相手には「見たはずなのに返事がない」と伝わってしまう。通信の成功と、利用者が確認できる状態を分ける必要があった。

そこで、タブが非表示の間は未読を維持し、戻ってきてメッセージが表示領域へ入ったときに既読化する扱いを実装・検証した。チャット画面を開いているだけでは、画面外のメッセージまで一括で読んだことにしない方針だ。

確認には、本番と切り離した検証環境を使った。受け手のタブを見ていない状態で相手側から送信し、既読日時と未読件数を確認する。非表示中は未読が残り、復帰後に表示領域へ入ると既読になること、画面外のメッセージは未読のままであることを確認した。

ここで大切なのは、文字が画面に出たことと、内容を理解したことまで同じにしないことだ。今回の既読はあくまで表示条件に基づく扱いで、人が読み終えた証明ではない。画面上の短いラベルほど、どこまでを意味するのか決めておきたいと思った。

変更は本番にも反映した。ただし、本番で双方が実際に送受信する確認はまだ完了していない。通信復旧後の表示は検証環境で確認できたものの、再取得が起きる細かな条件や、ブラウザーの戻る操作からの復帰などにも確認が残っている。テストが通った範囲と、実際の利用で確かめる範囲は分けている。

予約や問い合わせの仕組みを作るときも、「保存できた」「通知した」「確認された」は別の状態になる。便利な画面を増やす前に、この区別を丁寧に決めることが、行き違いを減らす土台になると感じた。

やり取りや対応状況が分かりにくい業務画面については、出品中の「AI・Webシステム開発の仕様と費用を整理します」からご相談いただけます。普段の運用と困っている場面を伺い、必要な状態表示や改善範囲から整理します。
サービス数100万件のスキルマーケット、あなたにぴったりのサービスを探す