表の行内編集UI：入力エラー、保存状態、競合への対応

表の行を直接編集するときは、「入力中の値」と「保存済みの値」を混同させないことが第一です。行の位置を保ち、どの項目を変更しているかを示し、入力エラーと保存の進行状況を伝えます。さらに、ほかの人が先に同じレコードを変更した場合の戻り道も必要です。ここでは、購買担当者が仕入先一覧の単価 $24.00 を変更する場面を通して考えます。

列の構成、情報密度、並べ替え、空状態から設計する場合は、先にPixso のデータテーブル設計ガイドを参照してください。この記事では表の骨格はすでにあり、別画面に移らず一件の価格を安全に変更することに焦点を当てます。

入力欄より先に、編集の区切りを決める

一行には仕入先名、品目コード、単価、通貨、更新日時があります。担当者は隣の仕入先と比較しながら単価だけを直したいので、全面的な編集画面に移ると比較の文脈を失います。行内編集なら文脈は残りますが、「入力欄から離れたら保存されるのか」「保存ボタンを押すのか」を曖昧にしてはいけません。

価格のように結果へ影響する値では、行ごとの「保存」「キャンセル」を明示すると、確定の時点が分かりやすくなります。サーバーが保存を受け付けるまでは元の $24.00 が保存済みの値です。入力中の値を集計やほかの人の画面に反映してはいけません。自動保存を採用する場合も、保存待ち・完了・失敗をはっきり示します。入力欄が消えただけでは、保存できた証拠にはなりません。

編集中は行を見失わないようにします。並べ替えや絞り込みで行が動く表なら、保存まで位置を保つか、確定後に現在の条件から外れることを知らせます。固定の操作バーを使う場合は、どの行に作用するかを表示してください。

一つの入力欄ではなく、六つの状態を設計する

通常の行だけでなく、そこから移る状態を描きます。次の表は同じ仕入先レコードを通して使う、短い状態仕様です。

この価格表では、単価に -5 を入力するとエラーになります。理由は、この例の価格表が負の単価を認めていないためです。「入力が正しくありません」だけでなく、「$0.00 以上の価格を入力してください」と伝えます。値を消さずに残せば、その場で修正できます。これは例の業務ルールであり、あらゆる価格システムがゼロを認めるという意味ではありません。

Atlassian のインライン編集のガイドは、閲覧状態と編集状態を分け、保存、キャンセル、検証を明確にしています。参考にするのは状態の区別であり、操作の細部は価格変更のリスクと自社のデータ仕様に合わせます。

入力時の検証とサーバー側の拒否を分ける

検証には二段階あります。空欄、形式の誤り、負の金額は、送信前に画面で判断できます。一方、権限、通貨の固定、更新された価格ルールなどは、サーバーが最終的に判定します。画面上の検証を通っただけで「保存済み」と表示してはいけません。

入力時のエラーは単価欄の近くに置き、支援技術からも入力欄と結び付けます。赤い枠線だけに頼らないでください。保存後にサーバーが拒否した場合は、入力を残したまま行を開いておき、分かる範囲で理由を示します。「エラーが発生しました」は最後の手段です。権限やバージョンの問題を説明できるのに隠してしまうと、次の行動が選べません。

表示形式も決めておきます。担当者は 24、24.0、24.00 のいずれかを入力するかもしれませんが、受理後の表示は一貫した形式に整えます。通貨を欄名や値の隣に示し、単なる「24」を個数と取り違えないようにします。小数点にカンマを使う地域では、その地域の表記として解析・表示し、「24,50」を黙って別の金額に読み替えないことが必要です。

保存と競合からの復帰を正直に示す

担当者が $25.00 を入力している間に、同僚が同じレコードを $26.00 で保存したとします。バージョンを確認すれば、古い編集で新しい値を無言で上書きすることを防げます。復帰画面では対象行を示し、「あなたの入力: $25.00」と「現在の保存値: $26.00」を並べ、差を確認してから進めるようにします。入力欄に $25.00 が残っていても、保存済みとは呼びません。

選べる対処はシステムの規則によります。上書きを認めるなら、結果を明示したうえで選択させます。認めないなら、現在の値を見ながら編集を続けるか、入力を失わずに判断してキャンセルできる道を作ります。実際に操作を取り消せないのに、モックアップだけで「元に戻す」と約束してはいけません。通信のタイムアウトも確定した競合とは別です。タイムアウト後はサーバーが保存したか不明なため、現在の値や処理結果を確認してから再試行を促します。

複数人で編集する製品なら、引き継ぎ資料に競合判定の取り決めを書きます。保存時に渡すバージョン識別子、比較する項目、競合を示す応答が決まっていれば、古い編集の拒否と一般的な通信障害を画面でも区別できます。見栄えのよい通知だけでは、この仕様を補えません。

キーボードでも同じ行を操作できるようにする

編集操作はマウスなしで到達でき、開始後のフォーカスは単価欄へ移るようにします。Escape でキャンセルするなら製品全体の動作として定め、Enter が複数項目の途中で予期せず送信しないようにします。保存とキャンセルには明確な名前と見えるフォーカスを付け、閲覧状態へ戻った後のフォーカス先も決めます。検証エラーでは、該当欄と理由へ注意を向けられるようにします。

操作できるデータ表にはグリッドのキーボードモデルを使う場合がありますが、グリッドは単にクリックできるセルを並べた表ではありません。W3C のグリッドパターンはフォーカス移動を説明しています。その例をそのまま実装の検証済みコードとは考えず、この製品にグリッド操作が本当に必要か判断します。行ごとに名前の分かる編集ボタンを置いた通常の表のほうが、操作と保守を簡単にできる場合もあります。

狭い画面では仕入先名、編集中の単価、通貨、エラー、保存操作を近くに置きます。補助列を詳細表示へ移しても、編集中の値を隠さないでください。モバイル幅だけでなく表示倍率を上げて確認します。100% では入っていた行操作が、200% では意味の分からないアイコンや横はみ出しになることがあります。

Pixso で判断の流れを試作する

Pixso では、価格表の一行について閲覧、編集、入力エラー、保存中、完了、競合のバリエーションを作ります。同じ仕入先と品目コードを各画面に使えば、レビューする人は六つの別例ではなく一件の変化を追えます。編集と保存の経路をプロトタイプでつなぎます。価格表はキャンバス上で設計するアプリケーションであり、Pixso 自体が価格をデータベースへ確定するわけではありません。

レビューでは、入力中に保存済みの値を探す、負の入力を直す、同僚の $26.00 が現れたときの行動を選ぶ、といった課題を試します。$25.00 が確定したか判別できなければ、見た目を磨く前に状態名や比較表示を直します。その後、プロトタイプと短い状態仕様を使って、検証、バージョン確認、フォーカス移動、エラー応答を開発へ渡します。Pixso で行の状態を設計する。

実装まで守るべき決定をそろえる

必要なのは、新しい価格入力欄だけではありません。入力中の値、保存待ちの値、サーバーが受理した値、拒否した編集を確実に見分けられることです。この仕入先行では、保存のきっかけ、画面とサーバーそれぞれの規則、並べ替え・絞り込み時の扱い、競合とタイムアウトからの復帰、結果ごとのフォーカス先をチームで決めます。これらが画面と仕様に表れていれば、開発者は静止画から動作を推測せずに実装できます。