ステータスの一括変更UI：選択範囲、事前確認と一部成功

ステータスを一括変更する画面では、確定前に「何件を選んだか」「変更後の値は何か」「変更できない項目はどれか」を示します。実行後も、変更済みと未変更を分けて伝える必要があります。表そのものを設計する段階なら、先にデータテーブルのコンポーネント設計を確認してください。ここでは、複数行を選択した後の操作を扱います。

一つの審査キューで、判断を具体化する

素材の審査キューを考えます。担当者が「対応が必要」で絞り込むと47件あり、2ページにまたがる12件を選んで「公開済みに変更」を選択しました。10件は変更できますが、選択後に別の担当者が1件を公開し、もう1件は担当者のロックがかかっています。画面は、選択対象がその12件なのか絞り込み結果の47件すべてなのか、変更できない2件が全体を止めるのか、10件だけ変更された場合に何を成功と呼ぶのかを明確にしなければなりません。

確認ダイアログだけで済ませず、選択、変更内容のプレビュー、処理中、結果の四つの状態をつなげて設計します。最初から公開済みになった1件とロックされた1件を含めれば、最後にエラー表示を付け足すだけでは解決しない問題が見えます。

選択範囲を曖昧にしない

表の見出しにあるチェックボックスは「このページに表示された行」を選ぶ場合があります。一方、別の操作で「現在の条件に合うすべての結果」へ範囲を広げる製品もあります。この二つは異なる集合です。個別に選んだ場合は「2ページで12件を選択」と表示し、利用者が明示的に範囲を広げた場合だけ「『対応が必要』に一致する47件すべて」と表示します。ページ送りをした途端に「選択した項目を公開」の意味が変わってはいけません。

操作バーでは件数と範囲を一緒に見せます。フィルターが変わったときは、選択した項目IDを保持してその旨を伝えるか、理由を示して選択を解除します。表に別の項目が表示されているのに「12件を選択中」だけが残る状態は避けます。複数ページの選択では、確定前に対象を見直せる入口も必要です。IBM Carbonのデータテーブルのガイドは、選択後の一括操作を行単位の操作とは別の状態として扱っています。ここで決めるべきことは、その状態に何が含まれるかです。

命令ではなく、変更結果を見せる

「12件を公開しますか？」だけでは、誤った選択に気づきにくいものです。プレビューには変更先のステータスを示し、結果ごとに項目を分けます。この例なら次のようになります。

誤った変更先や想定外の対象、変更できない理由が確定前に分かることが重要です。少件数の軽微な変更なら短い要約で足りるでしょう。影響が大きい変更や件数が多い場合は、対象行と変更前後の値まで確認できるようにします。Basis Design Systemの一括編集パターンも、選択件数の表示と複雑な編集のプレビューを勧めています。

変更できない行をどう扱うか決める

見た目の文言だけでは、未定義の処理ルールは補えません。製品担当者と開発担当者は、まず次のいずれかを選ぶ必要があります。

• 全件成功または全件中止：変更できない項目が一つでもあれば、何も変更しません。プレビューで妨げになっている項目を示し、選択から外せるようにします。
• 変更可能な項目だけ実行：10件を更新し、残り2件には触れません。確定前と実行後の両方で、この扱いを明示します。
• バックグラウンド処理：ジョブを開始して状態を追跡します。「依頼を受け付けた」と「項目の更新が終わった」を区別します。

実際の製品とデータの整合性に合うルールを一つ選び、画面間で混ぜないことが大切です。以下では「変更可能な項目だけ実行する」と仮定します。主ボタンは「10件を公開」とし、そのそばに除外される2件を示せます。業務上、全件一括でなければ公開できないなら、変更できない2件を外すまでボタンを有効にしません。通知などの副作用まで取り消せない製品で、安易に「元に戻す」と約束しないでください。

処理中と一部成功の結果を正直に伝える

確定後は対象の集合を固定し、結果が分からないうちに二重送信できないようにします。短い処理なら処理中表示と送信ボタンの無効化で足ります。時間がかかる場合は「変更可能な10件を更新中」のように状態を示し、後から結果に戻れる場所を用意します。実際の進捗と対応しないアニメーションより、現在のジョブ状態のほうが役に立ちます。

10件が成功し2件が変更されなかったなら、「12件すべて公開しました」とは表示しません。「10件を公開、2件は変更なし」と伝え、1件はすでに公開済み、もう1件はロック中であることを確認できるようにします。後者には項目を開く、権限を依頼する、ロック解除後に再試行する、といった次の行動を用意します。処理中に10件のうち1件が失敗した場合は、事前に分かっていた2件の除外とは別に報告します。事前の対象外と実行時の失敗では対処法が違います。

再試行を提供するなら、元の12件ではなく失敗した項目IDだけを対象にします。成功済みの項目にもう一度同じ操作を送らないためです。結果画面は、すぐ消える通知ではなく、例外を解決するための作業の続きです。

確定前に変わったデータを再確認する

選択から確定までの間に、別の担当者が公開したり、所有者や権限が変わったりすることがあります。変更可能かどうかに影響するなら、確定前にプレビューを再計算するか、古い内容での実行を止めて変化した行を知らせます。元々選んだ項目IDも残しておけば、件数が12から11に変わった理由を追えます。

プレビューを開いたまま別のセッションで1件を変更し、戻って確定するテストを行うと設計上の抜けが見えます。競合時の最終動作は製品の方針によりますが、利用者が確認した内容と異なる操作を黙って適用してはいけません。どの項目を再検証し、どのエラーを表示するかを引き継ぎ資料に残します。

小さい画面とキーボード操作も成立させる

選択状態を色だけで示さず、件数を読める言葉で表示します。行のチェックボックスはキーボードで操作できるようにし、最初の選択後には操作バーが見つかるようにします。狭い画面では優先度の低い操作をメニューに収めても、選択範囲と主操作の意味は残します。プレビューでは長い項目名を折り返し、変更前後のステータスを比較できるようにします。表のせいでページ全体が横スクロールする構成は避けます。

フォーカスの移動も決めておきます。プレビューを開いたら見出しまたは最初の操作へ、処理後は結果の通知へ移します。選択解除でプレビューを閉じたら、表の予測できる位置へ戻します。これは完成した製品で検証する実装要件であり、静的な画面だけでは証明できません。

Pixsoで判断の流れを試す

Pixsoでは編集可能な表を一つ用意し、12件を選んだ状態、10件と2件に分かれるプレビュー、処理中、一部成功の結果をそれぞれのフレームで作ります。行とステータスのコンポーネントを再利用し、同じ項目の名前と状態が画面間で食い違わないようにします。フレームをプロトタイプとしてつなぎ、公開済みになった1件とロックされた1件を残したままレビューしてもらいます。ここで描く一括ステータス変更は、Pixsoのキャンバス上で設計するアプリの画面であり、Pixsoが実データのキューを更新する機能ではありません。

レビュー参加者に、選択された集合を特定し、変更されない2件の扱いを予測し、確定後にその項目を見つけてもらいます。画面だけで答えられないなら、色を整える前にラベルやグルーピングを直します。「全件中止」か「変更可能な項目だけ実行」かもフレームのそばに明記し、開発側が画面から推測しなくて済むようにします。実装後には、選択範囲、競合時の動作、読み上げ、再試行を実データで確かめます。

各状態の背後にあるルールを渡す

このキューで必要な仕様は明快です。選択は2ページにまたがる明示的な項目IDで構成され、プレビューでは変更可能な10件、すでに公開済みの1件、ロックされた1件を分けます。確定では変更可能な項目だけを更新し、結果では更新済み・事前除外・実行時失敗を別々に示します。フィルター変更後も選択IDを維持するならその旨を伝え、確定前に適格性が変わればプレビューを更新します。こうしたルールがあって初めて、洗練された「公開」ボタンの動作を検証できます。