次の方法で共有

フォームの全般的なガイドライン

  • [アーティクル]

この記事には、フォームのパターンに関係なく、すべてのフォームに適用されるガイドラインが含まれています。 パターン固有のガイドラインに加えて、このチェックリストを使用する必要があります。

検証のチェックリスト

検証チェックリストには、フォームが UX ガイドラインに準拠しているかどうかを手動で確認する手順が示されています。 このチェックリストには、開発環境を通じて自動的に実施されるガイドラインは含まれていません。 ブラウザーでフォームを開いて、これらの手順を確認します。

標準フォーム ガイドライン

特定のフォームのパターンおよびサブパターンには、これらのガイドラインにあてはまらない場合があります。

  • フォーム レイアウトは、ブラウザーのサイズが変更されたとき、またはアプリが異なるデバイス サイズで実行されたときに反応します。 つまり、レイアウトのリフローを行うか、フィールドをスクロールすることにより、ユーザーがすべてのフィールドにアクセスできるようにする必要があります。

  • フォームの既定の表示/編集状態が正しいことを確認します。 既定では、フォームは表示モードです。 フォームを常に編集モードにする必要がある場合は、明示的に Form.Design.ViewEditMode=編集を設定する必要があります。

    • 表示/編集状態は、エンティティの状態に適切である必要があります。 たとえば、エンティティの状態が転記済で、フォームが編集できない場合、既定の状態は表示モード (および編集モードを無効にする必要があります) である必要があります。

  • フォーム キャプション:

    • プログラムでフォーム キャプションを設定することは避けてください。 代わりに、フォームのデザイン ノードで TitleDataSource プロパティを設定して、動的にキャプションを提供するフレームワークを有効にすることを検討します。
    • フォームのキャプションをプログラムで設定することを避けられない場合、キャプションを 30 文字以内に留めます。 この規定は、フォームに大きなフォント サイズを使用するフォーム タイプの場合の規定です。
      • 例外:カスタム ルックアップ、情報ボックス
    • フォーム キャプションは、エンティティの「型」のコンテキストを持つユーザーを提供する必要があります。 フォームのキャプションのフォント サイズと位置は、フォームのタイプによって異なります。
    • 親レコードやその他の状態情報などのコンテキスト情報を伝えるために、フォーム キャプションを使用しないでください。

  • フォーム内にあるすべてのラベルは文ケースです。 フレームワークは、グループ ラベル、情報ボックス キャプション、アクション ウィンドウ タブ ラベル、およびボタン グループ ラベルなどの要素をすべて大文字にすることで整合性を保証します。 これらの文字列は文の場合でも追加する必要がありますが、フレームワークはすべて大文字で表示します。

  • フォーム内のすべてのラベルは正しく綴られ適切な文法を使用しています。

  • 拡張データ型 (EDT) の書式アラインメントの上書きは避けてください。

  • カスタム フィルターを使用するときは、5 未満を指定する必要があります。 代わりに、フィールドのあるフィルター ウィンドウにあらかじめ入力することを検討します。

  • 場合によっては、コントロールを一時的に無効にするか、または非表示にするかを決定する必要があります。 この決定を行うのに役立つ情報は、次のとおりです。

    • コントロールを有効にするには特定の条件を満たす必要がある場合、コントロールを一時的に無効にし、ユーザーはまずこれらの条件を満たすようにいくつかのアクションを実行する必要があります。
    • ユーザーがコントロールを有効にしたり編集したりできない場合、コントロールをユーザーから非表示にするべきです。
      • 例外: コントロールはユーザーにステータスを伝えるために使用されます。

  • このフォームにアクセスするさまざまなロールにセキュリティが適用される場合に違反する UX ガイドラインはありません。

    • 例: ロール A では、フィールド A は必須ではありませんが、ロール B ではフィールド A は必須です。

  • 国/地域コードが適用される場合に違反する UX ガイドラインはありません。

  • 2 つのフィールドで 1 つのラベルを共有できます。 フィールドにグループをグループ化し、グループの FrameType プロパティを GroupedFieldsLabel に設定します。

    単一のラベルを共有する 2 つのフィールドの例。

その他のフォーム ガイドライン

  • 複数行の読み取り専用テキストには、StringEdit ではなく StaticText コントロールを使用します。 StringEdit コントロールは、編集できないため、情報テキストとして意味的に正しくありません。 加えて、StringEdit コントロールは、StaticText コントロールよりも罫線と異なるレイアウト特性を持ち、これらの違いによりユーザー エクスペリエンスが低下します。
  • 常に読み取り専用でデータ バインドされたコントロールは、ViewEdit=表示とマークする必要があります。
  • (ダイアログおよびドロップ ダイアログのみ) デフォルト ボタンとして選択されているボタンは、ユーザーが実行しているタスクに対して最も安全で保護された応答でなければなりません。 たとえば、既定のボタンは、ダイアログまたはドロップ ダイアログの主要な指示に対応する必要があります。
    • 安全性とセキュリティの要素でない場合は、クリックされる可能性が最も高いボタンまたはユーザーにとって最も便利なボタンをデフォルト ボタンとして選択する必要があります。
    • 例外: コマンドを取り消す簡単で明白な方法がない限り、破壊応答を既定のボタンとして選択しないでください。

フィールド状態のガイドライン

フィールドの状態を正しく設定することが重要です。 フィールドの状態は、ユーザーができること、およびその方法についての重要な情報を伝えます。 次のテーブルは、さまざまなフィールド状態を使用するときの重要なガイドラインをまとめたものです。 注記: 過去には、フィールド状態が正しく使用されていませんでした。 ユーザーは、代替可能な方法で Enabled=No および Readonly=Yes を使用しました。 2 つの状態の意味的な相違点に注意してください。

  • 有効化=いいえ - データは無効です。
  • 読み取り専用=はい – データは有効です。
状態 説明
有効化 = いいえ 無効フィールドは、フィールドがエンティティの現在の状態で有効でないことをユーザに伝えます。 フィールドを無効にしてデータ入力を禁止するには、Enabled プロパティを使用します。 無効なフィールド (Enabled=No) にはこれらの特性があります。
  • フィールドは視覚的に表示され、使用不可能に見えます。 テキストは、「無効」な外観を示すために灰色で表示されます。
  • フィールドの値は重要ではなく、処理のためにサーバーに送信されることはありません。
  • フィールドはタブ順でスキップされます。
無効なフィールドは、ユーザーがフォームで実行するアクションによって有効になる場合があります。 ユーザーがフィールドを有効にできない場合は、このフィールドの非表示を検討します。
Readonly=Yes 読み取り専用フィールドについては、データは現在のコンテキストで有効ですが、編集することはできません。 タブ シーケンスでフィールドはスキップされません。 値が編集できない場合は、フィールドの ViewEditMode=表示を検討します。
ViewEditMode=View この状態は、フィールド内の値をユーザーが編集できないようにし、情報提供のみを目的とする場合に使用します。
セキュリティ保護済み セキュリティで保護されている場合、フィールドは通常非表示です。 グリッドで、各行は各列に対してさまざまなレベルのセキュリティを定義できます。 したがって、ユーザーがアクセス権を持たないセルでは、フィールドに南京錠が表示されます。 これはアプリケーション制御能力ではなく、自動的に行われます。
使用不可 セキュリティで保護されたフィールドと同様、各行がさまざまな列セットを持つ場合グリッドにデータを表示できます。 この場合、行に適用できないセルには「not」記号が表示されます。 これはアプリケーション制御能力ではなく、自動的に行われます。

必須フィールド ガイドライン

必須フィールドは、データベースの参照の整合性とビジネス ロジックの整合性を保証するためにユーザーが値を指定する必要があるフィールドです。 フィールドを必須としてマークすることで、ユーザーが何をすべきかについての重要なインジケーターを提供します。

  • すべての必須項目はマーク済です。
  • 必須フィールドは、次の順序でメタデータの概念に設定する必要があります。
    1. テーブル
    2. データ ソース
    3. フォーム フィールド
  • 必須フィールドは、レコードの状態に基づき、プログラムを使用して設定する必要があります。 たとえば、エンティティを転記するために必要なフィールドが、必須とマークされる必要があります。
    • 空のフィールドに関する検証メッセージが表示され、そのフィールドが必須とマークされていない場合、ユーザー エクスペリエンスは低下します。

FastTabs ガイドライン

  • グループ内のフィールドは、FastTab を越えて移動する必要があります。

    クイック タブ間を通過するフィールドの例。

  • 最初のクイック タブのコンテンツは、スクロールせずに完全に表示される必要があります。 FastTabs では、フィールドが表示される際、水平にスクロールしないでください。

  • 最初のクイック タブには、このエンティティにとって最も重要なフィールド (編集頻度が最も高いフィールド) が含まれている必要があります。

  • FastTabs では、概要情報を表示する必要があります。

    • 例外:
      • グリッドのみを含む FastTabs は、概要フィールドを表示することは期待されていません。
      • この機能は現在サポートされていないため、分析コード クイック タブのページには要約フィールドが表示されません。

  • クイック タブにグリッドが含まれている場合は、ツールバーおよびリスト サブパターン ガイドラインに従う必要があります。

ラジオ ボタン ガイドライン

  • すべての ラジオ ボタンに対する Microsoft 標準ガイドラインに従います。具体的には、次のガイドラインを遵守します:
    • ラジオ ボタン コントロールは、相互に排他的な選択肢からオプションを 1 つ選択するために使用されます。
    • 2 つから 7 つの選択肢があります。 7 つ以上の選択肢がある場合は、コンボ ボックスを使用します。
    • オプションのいずれも有効な選択肢でない場合、この状況を反映するには、なしまたは適用されないなどの別のオプションがあります。
    • ラジオ ボタンを選択してもコマンドが実行されたり、ダイアログ ボックスなどの他のウィンドウが表示されたり、選択内容に関連するその他のコントロールが動的に表示/非表示になったりすることはありません。
    • 1 つのラジオ ボタンオプションは常に既定で選択されます。 (ただし、MSDN ガイドライン リンクの例外を参照してください。)
    • 既定のオプションは最も安全です (つまり、このオプションはデータの損失またはシステムへのアクセスを防ぎます)。また、利用可能な最も安全でプライベートなオプションです。 または、既定のオプションが最も一般的で便利なオプションです。
    • すべてのラジオ ボタンには、ラベルが付いています。
  • ラジオ ボタンを選択するために従属するコントロールが必要な場合は、これらのガイドラインに従います:
    • 従属コントロールが表示され、ラジオボタンの右または下に表示されます。
    • 従属するコントロールを使用して、ラジオ ボタンを選択します。
    • 従属コントロールは、他のラジオ ボタンやチェック ボックスを持つネストされたラジオ ボタンではありません。
  • オプションは、論理的な順序でリストされます。
    • 選択される可能性が最も高いものから最も低いものまで
    • 最も簡単な操作から最も複雑な操作まで
    • 最少リスクから最大リスク

チェック ボックスとガイドラインの切り替え

従来のチェック ボックスの代わりに通常はトグル ボタンが使用されます。

チェック ボックスと切替の画像。  

  • すべてのチェック ボタンに対する Microsoft 標準ガイドラインに従います。具体的には、次のガイドラインを遵守します:
    • 既定では、フォームのチェック ボックスの代わりにトグル ボタンを使用します。 ラベルは、Microsoft のチェックボックス ラベルのガイドラインに従う必要があります。
      • 例外:
        • 多数の関連オプションをグループで設定する必要がある場合は、チェック ボックスを使用します。
        • [カスタム フィルター グループ] サブパターン内のチェック ボックスを使用します。
        • 関連するフィールドを収集するフレームで使用されるチェック ボックスのグループ。 この例外は、現在明瞭さを加えるために検討中です。
    • 進捗状況のインジケータとして、チェック ボックス/切り替えボタンを使用しないでください。
    • チェックボックスを使用してコマンドを開始しないでください。 ただし、メッセージ ボックスは、ユーザーに対して選択を調整または明確にするよう表示できます。
    • チェック ボックスが選択された状態を説明するラベルを記述します。 クリアされた状態の意味は、選択された状態と明確に反対でなければなりません。
    • チェック ボックスのグループについては、類似した語句を使用し、すべてのラベルの長さがほぼ同じになるようにしてください。
    • 肯定的な表現を使用してください。 チェック ボックスを選択するとアクションが実行されないことを意味するラベルを付けないでください。

選択パネルのガイドライン

  • 場合によっては、ユーザーが選択できるオプションの個別のリストを必要とし、各オプションが同じインターフェイスを表示します。 ラジオ ボタンを使用してオプションのリストを提示しないでください。 代わりに、カスタム フィルター グループ内のコンボ ボックス コントロールを使用します。
  • 選択リストが品目のセットと共通である場合は、影響を受けるすべての品目の上にコンボ ボックスが表示される必要があります。

グリッドの全般的なガイドライン

  • シナリオが別の並べ替え順序を必要としない限り、グリッドは最初の列でおよび昇順に並べ替えられます。
    • ドキュメントの識別子 (ID) フィールド (販売注文 ID、発注書 ID など)
    • (仕入先の名前、顧客名など) のエンティティの名前/説明フィールド
    • シナリオによっては、シーケンス番号や日付など、ビジネス上の意味を持つ別の列に並べ替えることができます。
  • 編集可能なグリッド:
    • グリッドに必須項目を表示させて設定する必要があります。 レコードが保存される場合のみ不足している必須フィールドをユーザーに警告することは認められません。
    • すべての編集可能なグリッドは新規/削除または追加/削除 ボタンが付いたグリッドの上のツールバー、またはグローバル アクション ウィンドウで持つ必要があります。
  • 最も重要な列が左側になるように列を並べ替えます。 ユーザーの金額列はグリッドの一番右側の位置に配置しているとき最も便利です。
  • イメージの列は、ワークフロー状態など、エンティティまたはプロセスの状態情報を伝えるために使用できます。
  • 一般に、イメージ列はグリッドの左側に配置する必要があり、列ラベルはありません。 イメージの意味はツールチップで示される必要があります。
  • 数値列は、右揃えにする必要があります。 その他のすべての列は左揃えにする必要があります。
  • フォームがビュー モードで開くができ、編集モードでレコードを作成するために使用できる場合、グリッドに接続されているルート データ ソースのプロパティは Insert If Empty=Noである必要があります。この設定は、読み取り専用フォームが開かれたときにユーザーが空白のレコードを見て選択する状況を防ぎます。

エンティティ ステータス フィールドのガイドライン

  • エンティティのステータスは、フォームの右上、タイトル フィールドの右側に表示する必要があります。 詳細フォーム パターンは、状態フィールドを定義できるオプションのグループを提供します。

アクション ウィンドウの標準ガイドライン

  • 標準アクション ウィンドウは、フォームの上部にあり、アクション ウィンドウの標準ガイドラインに従います。
    • 例外:ダイアログ、ドロップ ダイアログ、ルックアップ
  • アプリケーションが追加されたアクションについては、すべてのアクション ウィンドウ間で、同様のアクションのラベルが一貫して使用される必要があります。
  • ボタンの名前にアクションについての適切な説明がされていない場合、ツールヒントに補助的な説明が表示される必要があります。
  • アクション ウィンドウのアクションは、エンティティ全体に適用する必要があります。 アクション ウィンドウのエンティティの部分にのみ適用されるアクションを配置しないようにします。 代わりに、操作が行われるオブジェクトの近くにあるローカル ツール バーを使用します。
  • 標準のアクション ウィンドウには、タブを 10 個以下にしてください。
    • グループごとに 1 〜 8 のアクションが必要です。
    • 最初のタブはホーム タブです。それはエンティティと同じ名前でなければならず、単数でなければなりません。
  • 活動タブ:
    • 特定の活動に関連付けられているアクションは、適切に名前が付けられた活動タブにグループ化する必要があります。
    • これらのタブには、ユーザーが理解できるアクティビティの名前を指定する必要があります。 名前は動作動詞で構成する必要があります。
    • [アクティビティ] タブからシステム定義の操作を削除します。
    • 新規および管理グループ 新規、削除、編集、および保存など、基本アクションに関連するグループ アクション。 例外は、エンティティ内のセカンダリ タイプに関連する 新しい アクションです。
    • 重複する 更新、添付ファイル、Excel にエクスポート、復元、OK、完了 ボタンを削除します。
  • 全般タブ:
    • 特定のアクティビティーに関連しない共通のまれなアクションがある場合、それらは最後のタブに表示され、一般と名前を付ける必要があります。
    • 一般タブで表示されるコマンドを、他のタグで繰り返すことはできません。

キャンバス ガイドラインのボタン

  • フォームに関連するフォームのコンテンツ領域のボタンは、特定のフィールドではなく、標準のアクション ウィンドウまたはツール バーに配置する必要があります。

ボタン画像ガイドライン

  • 画像が必要なボタンは、画像に記号を使用する必要があります。
  • イメージとテキストの両方がボタンの上に表示されている場合は、画像はテキストの左側にある必要があります。  その他の構成はサポートされていません。
  • 標準アクション ウィンドウ:
    • システムの新規/削除ボタンを置き換えるボタンは、新規/削除記号を使用する必要があります。
    • 他のシステムボタンによって使用されるシンボルがない限り、一般的なアクションには ButtonDisplay=自動が必要です。 その場合、TextOnly とする必要があります。  記号が割り当てられている必要があると思われる他の一般的なアクションがある場合は、UX に問い合わせてください。
    • その他の一般的でないアクションは TextOnly にする必要があります。
    • イメージは、アクション ウィンドウのタブではサポートされていません。
  • ツール バー:
    • 追加/削除 (該当する場合) は、最初のボタンで、追加/削除記号を使用する必要があります。また、画像とテキストの両方がある必要があります (ButtonDisplay = 自動)。
    • 一般的なアクションは追加/削除ボタンの右に移動する必要があります。 これらのアクションは、画像とテキストの両方を持つこともできます (ButtonDisplay=Auto)。 適切なイメージが存在しない場合、これらは TextOnly である可能性があります。
    • その後の一般的でないアクションは TextOnly にする必要があります。
  • MenuButtons 内:
    • イメージは、MenuButtons のボタンではサポートされていません。

付録

よく寄せられる質問

このセクションには、このガイドライン/パターンに関連するよくある質問への回答があります。

  • クイック タブで要約フィールドとしてサポートされていないのは、どのフィールド タイプですか?
    • パフォーマンス上の理由から、現時点では、参照グループおよび表示メソッドをサポートしていません。 また、バインドされていないフィールドは、集計フィールドとして使用することはできません。