インライン編集またはモーダルポップアップ
UXの観点から、どのオプションが最適かを知りたいです。インライン編集で各行を編集する必要があるかどうかを決定する必要があるテーブルがあります。そこでは、行の各項目をクリックして、モーダルポップアップで個別にまたは一度に編集できます。
インライン、そしてここに理由があります。ポップアップでユーザーが行っていることからユーザーを分離すると、アイテム、詳細、および配置の接続が失われます。方向転換するまでに少し時間がかかります。
ユーザーが製品から離れると、少し時間を取って、頭の中にあるこれらすべての情報を再接続してから開始します。
インライン編集を使用すると、非常に簡単です。
アダム、それは素晴らしい質問です。ただし、ここでは、インラインとポップアップウィンドウの2つのオプションに限定されません。 3番目のオプションは、レコードを編集/作成するページを用意することです。また、インライン+ページ/ポップアップの組み合わせも使用できます。
- インライン-最も限定的なUIソリューションであり、レコードに含まれるフィールドの数を考慮する必要があります。最大6つのフィールドであれば、インラインでも問題ありません。それ以外の場合は、いくつかのフィールドのインラインとレコード全体の完全な編集の両方が必要になります。さらに、編集するデータの量を考慮する必要があります。通常、インライン編集は、apoxのレコードに対して行われます。 255文字です。大きなテキストの場合、インラインは適切なアプローチではありません。検証メッセージが配置される場所も考慮する必要があります。
- ポップアップ-編集しているレコードが本当に複雑でなく、大きなテキストがなく、内部で別のポップアップを呼び出すことを意味しない場合（2つのポップアップは悪い習慣と見なされます）-ポップアップは機能します。
- ページ-レコードを編集するページがある場合、ほとんど制限はありません。大きなテキスト、フィールド値を設定するためのポップアップを使用できます。検証メッセージを配置しても問題はありません。
- インライン+ポップアップ/ページ-この場合、一部のフィールドをインラインで編集でき、他のフィールドは別のページ/ポップアップウィンドウで編集できます。
インラインが推奨されますが、アプリケーションの種類とユーザータスクに実際に依存することを付け加えておきます。
私の経験では、一括編集はエンタープライズアプリケーションにとって非常に重要であり、ユーザーがアイテムを複数選択して一括操作を実行できるようにするのに役立ちます。この場合のインラインは、繰り返し可能な編集が容易ではないため、非常に制限されます。
考慮すべきいくつかの質問は、テーブルの大きさですか？ページネーションはありますか？異なる見解？ユーザーが最も可能性が高く、最も頻繁にテーブルデータに対して実行する必要があるアクションはどれですか。そのようなテーブルは、製品の他の領域のデータを表すために使用されていますか？
私はジョンの答えがとても好きです。
考慮すべき別の側面があります-マルチレコード編集。明らかに、ユーザーが複数のレコードを同時に編集できるようにしたい場合、インラインメソッドは機能しません。 iTunes、またはその他の（より優れた）音楽ID3タグエディタを検討してください。時には曲の名前を修正する必要があります-インライン編集はそのために最適です（ただし、クリックしてレコードを選択するか、クリックしてトラックを再生するか、クリックして特定のフィールドを編集するかを明確にする必要があります）。 。アルバムのすべてのトラックを選択して、ジャンルを変更したい場合があります。これを行うには、行を複数選択してからエディタダイアログを起動し（iTunesではCMD + Iを押します）、1つまたは複数のフィールドに入力すると、レコード全体でそれらのフィールドのみが更新されます。 （これのiTunesの実装は、機能的ではありますが、すぐには直観的ではありません）。
開発者の観点から見ると、時間が限られていて、1つのインプットメソッドしか実装できない場合は、マルチレコード編集を有効にして起動するかどうかを検討する必要があります。もしそうなら、ダイアログを選択してください：使いやすさとパフォーマンスに少し影響しますが、コーディングにかかる時間を大幅に節約できます。
私はこれを言うのが嫌いですが、入力を処理するこれらの2つの方法に固執している場合は、両方を実装し、直感的な方法（とにかくiTunesよりも良い）を見つけて、ユーザーが入力できるようにするのが最善の策です。インライン編集モード（MicrosoftのF2もピットですが、少なくともかなり一貫性があります）、およびユーザーがマルチレコードモードに入ることができます。
考慮すべき最後の1つ：インライン編集を機能させるには、表形式の表示でレコードのすべてのフィールドを表示する必要があります。ユーザーが列を非表示にできるようにする場合、または編集可能なフィールドのサブセットのみを表示することを選択する場合は、何らかの編集可能な「詳細ビュー」を実装するしかありません。
多くの人が一度に変更できるトランザクションデータを備えたエンタープライズアプリを扱っている場合、インラインの方が多くてもmodalにsubmit buttonを使用しますExcelなどのシングルユーザーアプリで作業している人にとっては当然です。
コンテキストをテーブルからシフトアウトするという事実は、ユーザーが編集モードで考え始めるための方法であり、編集可能としてマークされているフィールドは表のセルが編集可能かどうかを推測するのではなく、編集可能。
次に、それをモーダルにしてsubmitボタンを付けると、非常に重要なチェックを1つ実行できます。レコードを変更しているときに、他の誰かがレコードを変更したかどうかを確認します。それが起こったときにそれは迷惑ですが、それはあなたのデータが通過したことを知らず、推定しないよりもはるかに優れています。 「トースト」を表示してユーザーに変更を通知できることも事実ですが、手間がかかる可能性があります。
このコンテキストは編集専用です。一方、検索は、多くのフィールドを持つ非常に奇妙で複雑なクエリでない限り、インラインにする必要があります。
私は言う傾向があります、なぜ両方ではないのですか？
それぞれのアプローチが理にかなっている2つのシナリオを考えることができます。
アプローチ1：インライン
列の総数がかなり少ないグリッド内の少数のセルを更新する必要があると仮定します。 Excelのように動作し、更新を続けることができます。このアプローチでは、Archimedes Trajanoによって強調された問題を考慮する必要があります。同時更新は関係者全員にとって問題になる可能性があります。
アプローチ2：モーダルポップアップ
新しいレコードを作成するか、列の総数が多い場合にレコードの多くのフィールドを変更します。次に、モーダルポップアップを開いて、ユーザーが値をすばやく編集/入力できるようにすることは理にかなっています。ユーザーは各フィールドがどこにあるかを正確に把握し、すばやく更新できるため、これは役に立ちます。データ整合性の問題はそれほど顕著ではありません。
どちらのアプローチでも、革新的な方法をほとんど使わずに複数の編集を行うことができます。