ユーザーがCRUD操作を実行するのに最適なUXは何ですか？
ユーザーは、エンティティのリストにバインドされたデータグリッドで作業します。 CRUD操作は、データグリッド（インライン編集）またはポップアップ（ユーザーが「作成」または「編集」ボタンのグリッドツールバーをクリックする）で直接実行できます。
これらの2つの方法のどちらが最近、より良いUXと考えられていますか？これら2つよりも良い3番目の方法はありますか？
これに対する明確な答えはありません。
使いやすさと実装の観点の両方から、2つはかなり異なります。そして、それらはレコード編集戦略に分類されます。レコードは表形式で提示できますが、カレンダー上のイベントもレコードと見なされます。
基本的に、決定はいくつかの主要な要因に要約されます。
- 方法複雑レコードは：
- フィールドの量
- 検証の複雑さ
- ユーザーが特定のフィールドを編集するquick方法が必要になる頻度はどれくらいですか？
- レコードを編集している間、ユーザーは画面上で他のレコードを表示を利用できますか？
原則として、3つの主要なパターンがあります。
モーダルダイアログ
ユーザーがレコードを編集する場合は、モデルダイアログが表示されます。このパターンにはいくつかの利点があります。
- 行き止まりナビゲーションを実装します。つまり、ユーザーは保存またはキャンセルを押してダイアログを終了することで、元の場所に戻る以外の場所に移動することはできません。このタイプのナビゲーションは非常に直感的で明確であり、ユーザーは何が起こるかを明確にする必要があります（他のソリューションとは異なります）。
Cancelオプションを使用できます。- 削除ガード-誤った削除を防ぐために、多くのインターフェースは削除ボタンをインタラクション階層の深いところに配置します。ダイアログでは、ダイアログ内の削除ボタンを「埋め込む」ことができ、ユーザーがレコードの削除をリクエストするために少なくとも1回クリックする必要があることを確認します。
- ダイアログを使用しているということは、表示スペースが増えることを意味します。
- ヘルプテキストを提示する
- データを見出しにクラスター化する
- より明確な方法で検証エラーを提示する
- 1対多のデータ操作が可能です。レコードに複数の添付ファイルを含めることができるとしましょう。ウィンドウを表示しているため、これらを編集できます。
- プログラムでこのタイプのパターンを実装するのは簡単です。ユーザーが新しいレコードを作成すると、クライアント側でのみ作成され、Saveでのみサーバーに送信されます。他のソリューションでは、実装はもう少し複雑です。
このパターンのバリエーションは行き止まりページであることに注意してください。つまり、オーバーレイダイアログは表示されませんが、（原則として）保存またはキャンセルしか実行できないページに移動します。これは、Googleがイベント編集を実装する方法です。
このパターンについて検討する必要があることの1つは、別のフォームに移動する必要がある場合、多少面倒になる可能性があることです。たとえば、レコードフィールドの1つがcustomerであり、顧客を追加する機能を提供したい場合、追加のフォームを表示する必要があります。一般に、モーダルからのモーダルは素晴らしいアイデアではありません。そして、最もエレガントなソリューションは、モバイルインタラクション方式でのhub-and-spokeパターンの実装です。
インプレースフィールドエディター
ここでの利点は、迅速であることです。ユーザーは、ビューから移動することなく、フィールドをクリックして編集できます。
ただし、いくつかの複雑な点があります。
- ユーザーが編集が終了したフィールドを持っていることをどの程度正確に知っていますか？ほとんどの場合、これはOnBlurイベントによって実現されますが、エディターが開いているときにユーザーがナビゲーション項目をクリックするとどうなりますか？
- 変更がユーザーにどのように示されるかサーバーに永続化（データベース）。編集が完了すると、リクエストがサーバーに送信され、サーバーは成功または失敗して戻ります。 ExtJSは、フィールドの左上隅に小さな赤い三角形を付け、サーバーが成功を返すと三角形が消えます。さらに複雑なのは、フィールドが編集されたが、サーバーが戻る前にユーザーが画面から移動した場合です。
- 画面に表示されなくなりましたであるデータに対して成功/失敗のフィードバックをどのように提供しますか（そしてプログラムでこれを考慮する必要があります。そうしないとエラーが発生します）。
- この場合、検証エラーの表示は、少し単純になる可能性があります（特に、一部の検証がサーバーで発生するため-たとえば、セッションタイムアウトを検討してください）。
- プログラムで、ユーザーがCreateをクリックすると、通常は新しいレコードリクエストをサーバーに送信し、新しいIDを取得して、編集可能な新しいレコードをテーブルに入力します。
これらをモーダルダイアログの利点と比較すると、多くがインプレースパターンでサポートされていないことがわかります。たとえば、キャンセルオプションはありません。
考慮すべきもう1つのことは（特にこのパターンで、ただしモデルダイアログの1つでも）テーブルの並べ替えとページ付けは、テーブルが人の名前でアルファベット順に並べ替えられている場合、非常に混乱する可能性があります。ユーザーが文字Zの周りのエントリを表示し、名前が「Adam」である新しいユーザーを入力すると、どうなりますか？
インプレースレコードエディター
これには、インプレースフィールドエディターの効率（速度）の利点がありますが、保存およびキャンセル操作が可能です。つまり、本質的には、インプレイスエディターとミニフォームとの一種の結婚です。
保存もキャンセルも押されずにユーザーがナビゲーション項目または別のレコードをクリックした場合に発生するような、それらの操作に関するいくつかの問題があります。
インスペクターペインを使用した編集モード
Inspectorsは、プロパティエディタの最新の名前です。選択されたレコードデータをフォームに表示する画面上のセクションです。ユーザーが編集をクリックしない限り、フォームは表示モードになります。ユーザーが保存またはキャンセルをクリックするまで、データを編集できます。
このパターンの主な問題は、レコードが編集モードにある間、画面上に多くの対話の機会があることです-ユーザーが保存を押すのを忘れることがあります。
モーダルダイアログパターンには多くの利点がありますが、ユーザーは編集中に他のレコードを表示できます。