ユーザー インターフェイスの実装
このセクションでは、Windows アプリケーションのユーザー インタフェースの実装に関連するいくつかのタスクについて説明します。
プロトタイプ
ユーザー インターフェイス (UI) は、ユーザー分析手順で識別されたユーザー シナリオと要件の一覧から設計する必要があります。
プロトタイプは、鉛筆スケッチと同じくらい簡単にすることも、インタラクティブな画面モックアップのように複雑にすることもできます。 検討された破棄された代替手段を利害関係者に示し、なぜ破棄されたのかを説明する場合に役立つ可能性があるため、以前のすべての作業は保持します。
この手順を最大で 2 つまたは 3 つのプロトタイプに制限してみてください。 プロトタイプを網羅する必要はありません。実際のアプリケーションを使用するエクスペリエンスを効果的にシミュレートするだけで済みます。
プロトタイプを示し、ユーザー フィードバックを追跡して、一般的な使いやすさの傾向を特定します。 可能であれば、最も成功の少ないプロトタイプを破棄し、できるだけ多くの有用なフィードバックを 1 つ以上の残りのプロトタイプに組み込みます。 時間とリソースに応じて、このプロセスを繰り返します。
Microsoft ペイントなどMicrosoft Expression Studio 3 の SketchFlow、Microsoft Visual Studio のレイアウト エディター、さまざまなプロトタイプ作成ツールがあります。
構造体
アプリケーションのユーザー インターフェイスを実装する場合は、次の事項を考慮してください。
コマンド構造
メニューとツール バーに基づいて従来のコマンド構造を実装するか、Windows リボン フレームワークに基づく別のコマンド構造を実装するかを決定します。 詳細については、「メニュー、ツール バー 、および Windows リボン フレームワーク」を参照してください。
ウィンドウおよびダイアログ
UI の設計とプロトタイプ作成の作業に基づいて、メイン ウィンドウ、サブウィンドウ、ダイアログ ボックス、メッセージ ボックスなど、アプリケーション ウィンドウを実装します。 UX ガイドラインに従って、ウィンドウとダイアログ ボックスで使用するスタイルとコントロールを決定します。 詳細については、「ウィンドウ、ダイアログ ボックス、およびウィンドウ コントロール」を参照してください。
カスタム コントロール
標準のウィンドウ コントロールの 1 つから必要な機能を取得できない場合にのみ、新しいカスタム コントロールを作成します。 新しいカスタム コントロールは開発に非常にコストがかかり、アクセス可能にするために追加の作業が必要です。 アプリケーションでカスタム コントロールが必要な場合は、それらが支援技術に適切に公開されていることを確認します。 詳細については、「カスタム コントロールと Windows Automation API」を参照してください。
標準ユーザー入力デバイスのサポート
ほとんどの Windows アプリケーションでは、キーボードとマウスによるユーザー入力をサポートする必要があります。 キーボードだけですべてのアプリケーション機能をナビゲートしてアクセスする機能は、視覚障害者または運動能力に問題のあるユーザーにとって特に重要です。 詳細については、「ユーザー入力およびアクセシビリティのエンジニアリング ソフトウェア」電子ブックを参照してください。
表示スタイル、アニメーション、視覚効果
Windows には、視覚的な関心を追加し、他のアプリケーションとは別に UI を設定するために使用できるいくつかのテクノロジが含まれています。 これには、コントロールの視覚スタイルの指定、UI 要素へのアニメーションの追加、UI でのさまざまな視覚効果の実装が含まれます。 詳細については、「ビジュアル スタイル」、「Windows アニメーション マネージャー」、および「デスクトップ ウィンドウ マネージャー」を参照してください。
簡素化
ユーザー エクスペリエンスの成功は、設計プロセス中の開発者のアプローチ、視点、および想定に依存します。 対象ユーザーがアプリケーションをどのように使用できるかについての基本的な理解を得るには、開発者のニーズに合った制約を超えて、広く考える能力が必要です。 プロジェクトの開始時にこの時間、労力、リサーチを投資すると、最後に配当が支払われます。
削減、再利用、整理整頓
機能は、実際に使用されている場合にのみ製品を改善します。 多くの場合、機能が急増すると、アイコン、メニュー項目、ツールバー、ダイアログ ボックスがさらに追加され、価値を追加するのではなく、効率と生産性に干渉する複雑さが生じる可能性があります。
最適な UI は UI ではない
UI は、ユーザーがアプリケーションを操作する必要があることを意味します。 理想的なケースでは、操作は必要ありません。 ユーザーの観点からは、機能するだけです。 ユーザー操作を安全に削除する機能を追加できる場合は、ユーザー エクスペリエンスが大幅に向上します。
UI が少ない方が UI が良い
多くの場合、UI の操作をユーザー エクスペリエンスから完全に削除することはできません。 ただし、アプリケーションに必要なユーザー操作が少ないほど、より優れています。
ユーザーがアプリケーションで実行する最も一般的で重要なアクティビティを特定し、それらの機能を UI で最も目立つようにします。 他の機能やアクティビティを、視覚的、階層的、またはオプションのアプリケーション設定とユーザー設定を使用して、より低いステータスに再分類します。
追加ではなく置き換える
UI ルールの保持では、何かを取り除くことができるときにのみ何かを追加するとされています。 このルールにより、機能がユーザー エクスペリエンス全体に与える影響を考慮して、開発者は新しい機能について客観的に考える必要があります。
新機能は新しい機能であるため、宣伝しないでください。マーケティングと使いやすさを混同しないでください。 ユーザーが製品の新機能を見つけられるように、アプリケーションの最後のバージョン以降に発生した変更を説明する項目をヘルプ メニューに追加します。
ユーザーが限られたソース
一度に公開される機能が多いほど、ユーザーが必要な機能を見つけるのが難しくなります。
割り込むのは失礼
アプリケーションは、ダイアログ ボックスを表示するときに、ユーザーがしていることに関わらず停止し、他の何かに注意を払うことを強制します。 可能な場合は、エラー ケースやその他の破壊的なユーザー エクスペリエンスを回避することで、ダイアログ ボックスの必要性を完全に取り払います。 メッセージのガイドラインの詳細については、「 メッセージ」を参照してください。
シンプルこそ強力になることもある
単純な UI は、機能の欠如を意味しません。 通常、UI が単純になった結果、学習曲線が短縮され、効率が向上し、生産性が向上します。 これにより、ユーザーはアプリケーションの能力を向上できます。
一貫性のある UI は適切な UI
一般に、アプリケーション UI 全体で一貫性を保つよう努めておくことをお勧めします。 一貫性のある UI を提供することで、ユーザーはアプリケーションに対してより短い時間でより能力が向上します。 アプリケーションに関する既存の知識をさまざまな状況に適用し、未知の機能を自信を持って使用することができます。
まれに、一貫性はユーザーにメリットを提供せず、ユーザー エクスペリエンスを低下させる可能性もあります。 その一貫性によってタスクを実行する機能が損なわれる場合は、UI の一貫性を確保しないでください。 一貫性自体は、使いやすさを保証するものではありません。 インターフェイスの一貫性が優れた設計につながると考えるのは間違いです。
たとえば、ビデオ ゲーム UI は通常、ゲームの種類に非常に特化されています。 ハンドルが必要なゲームとジョイスティックとボタンで最適に動作する 2 つの特殊なゲームに適した汎用 UI を設計しようとすると、どちらのゲームでも成功しない可能性があります。 せいぜい中間地点が達成される可能性が高く、どちらにも適していません。
物事の使用方法に関する適切なデータを持つことは、この決定を行う鍵です。 各トレードオフの長所と短所 (スピードや信頼性、学習の容易さ、専門家の能力、グローバル整合性とローカル最適化) を明確にし、製品全体に関連して機能に最適な決定を行います。
設計では、失敗する方法を選択します。1 つ最適化することは、別で失敗することを意味します。 優れた UI 設計の鍵となるのは、アプリケーションのどの特性が最も重要で、どの特性をカットできるかを決定できることです。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示