§06-01
リアルタイムカーソル
他の参加者のカーソル位置と名前を表示する。
同じ画面で誰がどこを見て操作しているかが分かり、作業の衝突を避けられる。共同編集やホワイトボードで使う。
実装のポイント座標は相対値(0〜1)で送受信し、受信側で補間して描画する。送信は rAF や 50ms 程度にスロットリングし、離脱したピアのカーソルはタイムアウトで消す。
- リアルタイム
- アニメーション
- モック
§06
Collaboration
§06-01
他の参加者のカーソル位置と名前を表示する。
同じ画面で誰がどこを見て操作しているかが分かり、作業の衝突を避けられる。共同編集やホワイトボードで使う。
実装のポイント座標は相対値(0〜1)で送受信し、受信側で補間して描画する。送信は rAF や 50ms 程度にスロットリングし、離脱したピアのカーソルはタイムアウトで消す。
§06-02
同じ画面を見ている参加者をアバターで示す。
誰が同じ場所にいるかを常に見せ、他人の作業中に同じ箇所を触る衝突を減らす。共同編集やライブの会議室で、相手の存在を感じさせたいときに使う。
実装のポイント参加者はハートビートで生存確認し、切断検知後は猶予を置いて消す。上限を超えた分は「+N」にまとめ、名前は title だけでなく aria-label でも渡す。
§06-05
@ で相手を指名し通知を届ける。
特定の人に確実に気付いてほしいコメントを届け、受け手は自分宛てだけを一覧できる。会話量が多いチームで埋没を防ぐ。
実装のポイント受信したメンションは発生元(ドキュメント・行)へのディープリンクを持たせ、既読は個別とまとめての両方で付けられるようにする。未読は背景色以外にも印を付ける。
§06-06
投稿にぶら下がる返信をまとめて表示する。
ひとつの話題への返信を元投稿の下にまとめ、本流の流れを汚さない。参加者の多いチャットや掲示板で、話題の混線を防ぐ。
実装のポイント返信は親 ID でぶら下げ、表示は 1 階層に平坦化すると深いネストの横幅崩れを防げる。長いスレッドは中間を折りたたみ「N 件の返信を表示」で展開する。
§06-07
下書きやプレビューを見られる URL を発行する。
アカウントを持たない相手にも成果物を見せて確認を取れる。公開前のレビューや、顧客への途中共有に向く。
実装のポイント公開範囲の切り替えはリンク自体を作り直すのではなくサーバー側の権限で制御する。コピーは navigator.clipboard.writeText の失敗時に手動選択へフォールバックする。
§06-08
他者と同時に編集していることを知らせる。
複数人が同じ文書を触る環境で上書き事故を防ぐ。保存して初めて衝突に気づき、作業が失われる問題に効く。
実装のポイント他者の編集はプレゼンス情報から検知し、セクション単位で警告する。保存時はバージョン番号や ETag で衝突を判定し、差分を見せてから上書きか統合かを選ばせる。
§06-09
編集権を一人が取得して同時編集を防ぐ。
同時編集で上書きが起きると困る対象を、一人ずつ順番に扱えるようにする。設定や請求書など、競合解決より排他が適した場面で使う。
実装のポイントロックは有効期限(TTL)付きで取得し、編集中はハートビートで延長する。強制解除の手段と、誰がいつから保持しているかの表示をセットで用意する。
§06-10
過去の版を一覧し、任意の時点へ戻せる。
いつ誰が何を変えたかを辿り、誤った変更を以前の状態に戻せる。共同編集の文書や設定で、消してしまった内容を取り戻す安心感を与える。
実装のポイントスナップショットは差分で保存し、復元は過去版を上書きするのではなく新しい版として積む。復元前に差分プレビューを出すと誤操作を防げる。
§06-11
メールやリンクで相手を役割付きで招待する。
チームや共有スペースに人を加える入口になる。相手の権限を招待の時点で決めるため、後から権限を直す手間と事故を減らせる。
実装のポイント複数アドレスはカンマや改行で分割して個別にバリデーションし、不正なものをチップ単位で示す。ロールは送信前に明示選択させ、既定値は最小権限にする。
§06-12
期限付きのリンクで外部の人を一時的に招待する。
アカウントを持たない相手に一時的に閲覧や編集を許す。外部の協力者や顧客への共有で、権限が残り続ける不安を減らす。
実装のポイント期限はトークンに埋め込まずサーバー側で失効時刻を管理し、期限切れリンクには再申請の導線を出す。無期限は選ばせるにしても既定値にはしない。
§06-13
ロールごとの操作可否を表で示す。
誰が何をできるかを一覧で確認・変更でき、権限の抜けや過剰を見つけやすい。管理者が複数ロールを設計するときに使う。
実装のポイント権限はロールごとの真偽表としてデータで持ち、UI と認可チェックで同じ定義を参照する。可否はアイコンだけでなく「可」「不可」のテキストも支援技術に渡す。
§06-14
レビュアーを割り当てて承認・却下を進める。
公開や変更の前に担当者の確認を挟み、誰が承認したかを記録する。複数人の判断が必要な業務で、進捗と責任の所在を見える化する。
実装のポイント全体ステータスは各レビュアーの状態から導出し、別 state で持たない。全員承認か一定数承認かのルールを先に決め、却下は理由入力を必須にする。