CRUDアプリケーション用の流暢なリボンの設計
私は、データベース上で動作するCRUDアプリケーション用のFluent（ "Ribbon"）スタイルのUXの設計に取り組んでいます。
ドキュメントベースのアプリケーション用にリボンを設計する方法については、たくさんの情報があります。 Microsoftガイドライン では、標準のタブとグループを指定することもできます。
ただし、これらの標準グループは、ドキュメント以外の状況にはあまり適していないようです。たとえば、「検索」コマンドは「編集」グループ内にある必要があります。
検索に完全に関連withinドキュメント、検索には関連なしforレコード。
ドキュメント以外のアプリケーションでリボンを使用するためのリソースや例はありますか？
27/9更新：はい、開発中のアプリケーションにリボンが適切であると確信しています。これはドキュメントに焦点を当てたものではありませんが、純粋なCRUDでもありません。多くのビジネス行動を伴う複雑なアプリケーションです。事前にガイダンスを提供できれば、リボンの配置に関するワークショップを実施する方が簡単です。ですから、リソースと例に関する私の元の質問に対するいくつかの回答を期待しています。
あなたが見ることができる最も良い例はMS Accessだと思います。すべてのCRUDコマンドはレコードグループにあり、検索コマンドは検索グループにあります！
リボンは多くのコマンドを含むプログラム用に設計されたもので、CRUDアプリケーションにはコマンドが数個しかない傾向があるため、そもそもリボンが適切なUIではないかもしれません。
MSがリボンをデザインしたときに行ったように、できるだけ多くの人（フィールドを知っている人、できれば顧客）にタブ/グループのリストといくつかのコマンドを渡して、最も論理的な場所を選択してもらいます。コマンド。
そして最も重要なのは、ガイドラインを盲目的に遵守しないでください（ただし、正当な理由がない限り無視しないでください）。個人の好みとユーザーが直感的に理解できるものとを混同しないでください。
私はあなたが私のアプリケーションを使用していて「リボン」インターフェースを設計しているのとほとんど同じ状況にいます。コアの「ビジネス」オブジェクトに基づいてコマンドをリボンにグループ化する状況を考えてきました。言い換えると、私のアプリでユーザーがクライアントとベンダーを管理できる場合、一般的に呼び出すすべてのコマンドを使用してクライアント専用のリボングループを作成し、次にさまざまなコマンドを使用してベンダー専用の別のリボングループを作成することは理にかなっています。それらのオブジェクト\レコードに対して実行する意味がありますか？
これをスケッチしたとき、（少なくとも私には）リボンを1つだけ提供した場合、このスタイルでは画面管理が非常に難しくなり、おそらくユーザーの助け以上に不満を感じることが明らかになりました。
この問題に少なくとも正接して対処する中で私が遭遇した最高のUIについては、Outlook 2010のインターフェイスです。 Outlookは別のナビゲーション要素に依存していますが、たとえばメッセージから連絡先に切り替えると、リボンは変更され、そのときに操作しているインターフェイスでサポートされているコマンドが表示されます。
それをあなたの例に戻すと、特定のレコードを見つけることは、ユーザーが探しているレコードのタイプを知っていることを意味すると思われます。最初にナビゲーションシステムを配置して、ユーザーがコアオブジェクト（顧客ビューなど）に移動し、次に顧客のみに関係する一連のコマンドをリボン内に表示できるようにすると便利です。 Findは確かに「Editing」グループに属している可能性がありますが、そのコンテキストはCustomersビューにのみ関係します。アプリケーション内の他のエンティティに関連する編集グループに別の検索コマンドがある場合もあります。
私もこれについて考えてきましたが、私が思いついた主なアイデアは、Tim Lentineが説明したものと似ています。つまり、私の主要なビジネスオブジェクトごとにタブがあるということです。たとえば、そのオブジェクトに対して最も一般的に実行されるコマンドをそのタブに配置します。たとえば、「注文」オブジェクトには、ステータスの変更（キャンセル、発送など）、請求、請求書の送信などのコマンドが含まれる場合があります。
ただし、Windows Liveフォトギャラリーのリボンがどのように機能するかについても考えています。ある意味で、それは（写真とメタデータの）データベースを管理しています。特に興味深いのは、[ホーム]、[検索]、および[表示]タブです。表示される検索/フィルターボックスのアイデアも気に入りました。
したがって、これらは、私が検討してきたCRUDアプリケーションの2つの主要なリボンのアイデアです。まだ何も決めていません。
フォトギャラリーに沿って、特定のデータのリストを取得したり削除したりするために1つのタブを作成する場合があります（ウィンドウのメインパネルにオブジェクトのリストを表示することを計画していました）。フィルタリング/グループ化用に別のものがあるかもしれません（WLPGの「ビュー」タブと同様）。おそらくレポート用の別のタブがあるでしょう。最初の段落で説明したように、コンテキストタブを使用して、選択したオブジェクトに対して一般的なコマンドを実行することもできます。
リボン付きのCRUDアプリの経験はあまりありませんが、いくつかのアイデアがあります...
Read-ユーザーが特定のオブジェクトを見つける標準的な方法にコミットされた1つ以上のタブを用意します。たとえば、大学のデータベースの場合、学生/教員用のタブ、クラス用、建物用のタブがあります。タブ内のオブジェクトを、学生用とスタッフ用のように、より細かいレベルでグループ化します。単純なフィールドクエリの場合は、プレーンテキストコントロールを直接配置するか、複雑な検索ダイアログをポップアップ表示できます。
作成-削除するタブを1つだけ持つか、読み取りタブに配置します。別のタブを作成する場合は、グループをタブにマップし、セパレータを追加してミニグループを作成します。
更新-このためのコンテキストタブを真剣に検討します。オブジェクトタイプごとに1つのコンテキスト。フォームに複数のタイプがある場合は、キーボードフォーカスでコンテキストを操作する必要があります。それほど楽しいことではありません。フォーム自体でこれらの更新タスクが必要になる場合もあります。特に、applyなどのダイアログの「コマンド」オプションに適切にマッピングされている場合はなおさらです。
削除-既定ではリボン上ではなく、コマンドに埋め込まれます。データの破棄はお勧めできません。代わりに、特定のクエリでのみ表示されるように、データを「アーカイブ」、「廃止」、または「卒業」することをユーザーに推奨します。そして、これらのアクションは一般にオブジェクト固有であるため、フォームまたはコンテキストタブのいずれかに存在します。毎週のバックアップ、アーカイブ、およびメンテナンスタスクで削除を実行します。