これは、ユーザーが大きな変更セットを入力しているか、小さな1回限りの変更を行っているかによって異なります。
スイッチをオンにする必要がある「編集モード」を備えたテーブルを以前に開発しました。編集モードになると、選択した行のすべての編集可能なフィールドがテキストフィールドになったため、どのコンテンツを変更できるかは明らかでした。変更されたフィールドは緑色で強調表示され、削除された行は赤色で強調表示されます。保存する前に、変更セットを確認するためにフィルタリングできます。このアプローチは、大規模な変更セット、およびほとんどの場合データを表示していて、誤って何かを変更しないことを確信したいユーザーにとっては良いことです。
私が最近見た傾向は、編集しているものにできるだけ近くに編集ボタンを配置することです(ただし、要素に集中している場合のみ)。
私が使用している少なくともいくつかのWebアプリがあり、フィールドの上にカーソルを置くと鉛筆アイコンが表示されます。そこからクリックまたはダブルクリックして、その1つのフィールドの値を変更できます。明らかに、アプリはさまざまなタイプのレイアウトを使用しますが、レイアウトを試して、何がより効果的に機能するかを確認できます。
一部のアプリはインライン編集を直接使用し(下図を参照)、他のアプリはページをオーバーレイするモーダル入力を表示します。インライン編集は私の好みです。すばやく編集するためにマウスや指をあまり遠くに移動する必要がないからです。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
この設計は、少数の編集が予想される場合、またはユーザーが単一の値をすばやく編集できるようにする場合に適しています。もちろん、行ごとに一度に複数の値を編集する必要があると予想される場合は、少なくとも左から右に読む言語では、ボタンを最初の列に配置するのがおそらく最善でしょう。これは、大量のデータがある場合(ユーザーが編集ボタンを見つけるために右にスクロールする必要がある場合がある場合)にも当てはまります。
ボタンに加えて、対象のデバイスにキーボードがある場合、ESCとEnter/Returnが(それぞれ)キャンセルボタンと保存/編集ボタンに配線されていることを確認してください。彼らがしたくない、またはアクセシビリティのニーズがある場合は、マウスを使用してください。
最初に、左側の編集ボタンが付いているものは破棄します。これは、行を読み取って編集することを決定するという自然な流れに反するためです。
次に分析する必要があります:
これらの答えに応じて、入力、行、または列の編集の間で異なるオプションを選択します。
私にとってほとんどの場合、行の編集が最も効果的です。行の編集は、ユーザーが編集したいすべての入力をクリックするのを邪魔しないが、すべてを編集しないため、編集されたすべてのトラックが失われる中点であるためです。これは例です:
モーダルを開いてこの入力についてユーザーに通知することは可能です。この入力は変更のみ可能であり、ユーザーがこれを変更したときにのみ保存ボタンを表示します。この場合のミニアニメーションを使用して、このオプションについて詳しく説明します。
紙に書いてあるように、消しゴムを手に入れてその値を変更するのがいいと思います。
代わりに、1つのボタンを追加します。それぞれの値に編集ボタンを追加します。変更できるのは、ユーザーが保存ボタンを1つしか見なかったため、ユーザーに疑いが生じます。