このタイプの UI は、さまざまな Web サイトや .net ブックで頻繁に表示されます。
これらのタイプのユーザー インターフェイスは、商用および/またはカスタマイズされたビジネス ソフトウェアで受け入れられるか、または人気がありますか?
ご注意ください
(1) Binding Navigator の使用、および
(2) マスター グリッド、ディテール グリッド、および入力領域を同じフォームに配置する。
UI がどんなに些細なものであっても、検索機能は常に必要ですが、ここでは利用できません。そしてもちろん、膨大なデータを扱う UI でBinding Navigator を使用することの関連性はわかりません。
私も最初に気づいたのは、検索の欠落でした。
したがって、メイン グリッドの高度な検索と、列のフィルター オプションと並べ替えオプションが必要だと思います。
マスター/詳細に関しては、メイン グリッドから選択 (ダブルクリック/入力) する機能があれば、より直感的であり、編集する注文の詳細と、注文を含む同様のグリッドが表示されます。詳細。
より直感的である理由は、ユーザーが毎回別のウィンドウを扱っているためです。すべてが詰め込まれた雑然としたメイン ウィンドウに頭を悩まされることなく、目の前のタスクに対処できます。
Webに最適なインターフェイスではないかもしれませんが、たとえば、フォーム間の変更が本当に必要ないときに時間の無駄になる一部のERPフォームには適しています。
たとえば、フォーム間で変更する必要のない注文を登録する場合、同じウィンドウで同じ作業を繰り返し行うため、時間を節約できます（この作業をキーボードでのみ実行できる場合は、より多くの時間を節約できます）。
したがって、適切なインターフェースの定義は、それが想定されている用途に常に関連しています。
この例では、orders-gridを1つのダイアログに配置し、orderdetailビューを別のダイアログに配置します。次に、最初/前/次/最後のボタンを詳細ダイアログに移動し、ユーザーがグリッドに戻らずに、ある注文から次の注文に移動できるようにします。
また、新規/削除ボタンを詳細ダイアログにコピーします。この場合も、ユーザーが現在の注文を削除したり、（同じウィンドウまたは新しい注文で）新しい注文を作成したりできるようにします。
また、概要と詳細の両方に印刷ボタンを追加します。ビジネスソフトウェアのユーザーは、印刷物が大好きです。:)
すべてを1つのダイアログに配置するのは、情報が少なく、詳細ダイアログがやり過ぎだと感じた場合にのみ行う必要があります。
マスター/詳細ウィンドウは許容されますが、マスター/詳細ウィンドウが「詳細」ペインの内容がウィンドウ内の選択されたオブジェクトまたはアクティブなオブジェクトによって決定されるマルチフレームまたはマルチペイン ウィンドウを意味する場合、本来あるべきほど普及していません。 「マスター」ペイン。マスター/詳細は基本的に Windows エクスプローラーや Outlook などの多くの電子メール クライアントにあるため、ユーザーは一般にマスター/詳細に精通しています。
検索とマスター/詳細は相互に排他的ではないため、小さなデータ セットに限定する理由はありません。マスター ペイン自体は、データベース テーブル内のすべてのレコードを表すのではなく、フィルター処理またはクエリの基準を満たす一連のレコードである場合があります (通常はそうです)。これは、ウィンドウの即時適用フィルタリングまたは「ファセット」コントロール、または「フォルダ」として表される固定フィルタリング基準の別のペイン (たとえば、処理する注文の「受信ボックス」など)、または別の検索またはクエリ ウィンドウまたはダイアログ (たとえば、顧客 VCTE のすべての注文を表示するため)。
複数のタスクをサポートする定期的に使用されるアプリを扱っている場合は、通常、小さなウィンドウをたくさん配置するよりも、適度に大きなウィンドウに多くのものを収めるのが最善です。小さな窓を分ける:
より多くのナビゲーションを意味し、より多くのユーザー時間がかかります。
ユーザーは、混乱してウィンドウを「見失ったり」したり、1 つのウィンドウが他のウィンドウとどのように関連しているかを忘れたりして、混乱を招くことがあります。
一部のフィールドは、コンテキストを提供するためにウィンドウで繰り返す必要があり、そうでない場合よりも全体的に複雑になります。
通常、ビジネス ソフトウェアでは、1 つのウィンドウに収めるにはアプリ内の情報が多すぎるため、コンテンツを複数の大きなウィンドウに分割する方法が問題になります。ルールは、ユーザーが最もよく一緒に行うことをまとめることです。ユーザーがウィンドウを切り替える回数を最小限に抑えたい。多くの場合、これを実現する最善の方法は、マスター/詳細ウィンドウを使用することです (上記の検索方法を使用)。複数のクラス/テーブルの複数のオブジェクト/レコードを含む多くのタスク (たとえば、顧客の VCTE 注文履歴を調べて、注文した製品が時間の経過とともにどのように変化したかを確認する、詳細属性を過去の注文から新しい注文にコピーする)、およびマスター/詳細ウィンドウを使用すると、ユーザーは、ウィンドウ ナビゲーションなしでそれらを完了することができます。マスター/詳細ウィンドウにより、ユーザーは異なるクラスを含むタスク間を簡単に切り替えることができます。
これを、検索基準と検索結果のリストの両方に 1 つのウィンドウがあり、結果リスト内のオブジェクトの個別の詳細ウィンドウがある UI と比較してください。これは Web ベースのビジネス アプリでは一般的ですが、多くの場合、UI またはビジネス プロセスの設計が不十分であることを示しています。別の詳細ウィンドウを持つ検索結果ウィンドウがある場合、次の 3 つの可能性があります。
ユーザーは、結果リスト内の複数のオブジェクトで作業することが期待されています。ただし、その場合、ユーザーが検索結果ウィンドウと詳細ウィンドウの間を行き来する必要がないように、結果リストは詳細を含む別のウィンドウに (マスター/詳細として) 表示する必要があります。
ユーザーは、結果リストをスキャンして 1 つのオブジェクトを探し、詳細ウィンドウでそのオブジェクトを操作する必要があります。ただし、その場合は、検索/クエリ機能を改善して、ユーザーが検索条件から直接オブジェクトにアクセスし、無関係な結果のスキャンをスキップできるようにする必要があります。
ユーザーは検索を繰り返し実行し、結果リストをスキャンしてから検索条件を微調整して、必要な結果を取得することが期待されています。ただし、検索するのがユーザーの仕事になることはめったにありません。検索は、ユーザーが仕事をするために必要なオブジェクトに到達するために行うものです。ユーザーが検索に多くの時間を費やしている場合は、ユーザーが実際に作業を完了するために必要なオブジェクトにすばやくアクセスできるように、より優れた検索機能を提供する必要があります。
詳細はhttp://www.zuschlogin.com/?p=31を参照してください。