Skip to main content

Windows Vista 日本語版 ユーザー エクスペリエンスのトップ ルール


このドキュメントは暫定版であり、今後変更されることがあります。

この記事では、高品質で一貫性のある Windows Vista のユーザー インターフェイスを作成するためのトップ ルールをまとめています。Windows Vista デザイン チームは、開発者によるこれらのトップ ルールの順守を推奨します。

  1. Aero テーマおよびシステム フォント (メイリオ) を使用する
  2. コモン コントロールおよびコモン ダイアログを使用する
  3. 標準のウィンドウ フレームを使用して、グラス風ボーダーを効果的に使用する
  4. Windows Vista のスタイルおよび品質に合致したアイコンとグラフィックスを使用する
  5. 新しいダイアログ ボックスや頻繁に使用されるダイアログ ボックス、エラー メッセージには、タスク ダイアログを使用する
  6. Aero ウィザードを使用する
  7. エクスプローラによってホストされるナビゲーション ベースのユーザー インターフェイスを使用し、[戻る] ボタンを提供する
  8. 標準の Windows 検索モデルを使用する
  9. すべての UI テキストで Windows Vista トーンを使用する
  10. ユーザー インターフェイスをクリーンアップする
  11. 通知を慎重に使用する
  12. 最終調整のための時間を十分に確保する

 

ルール 1: Aero テーマおよびシステム フォント (メイリオ) を使用する

テーマおよび標準のシステム フォントを使用して、アプリケーションに Windows Vista 日本語版と整合性の取れたユーザー エクスペリエンス デザインを実現します。

fig01

  • 視覚的なスタイルをアプリケーションで有効にするには、Theme API を使用します。Windows Vista では、新しい Aero Visual Style を使用してアプリケーションの UI が自動的にレンダリングされます。ユーザー インターフェイス上で Windows Vista のコモン コントロール (ComCtl32 バージョン 6) が適切に使用されていることを確認します。開発者は DrawThemeBackground API を使用して、テーマ パーツを描画できます。
  • Aero テーマの XML ドキュメントを使用します。
  • Windows Vista 日本語版の新しいシステム フォントであるメイリオを使用します。(メイリオ フォントの斜体スタイルは、英語 (半角のアルファベット、数字、記号) のみ対応しています。詳細については こちらをご覧ください。)
  • Windows Theme API を使用して、システムのフォント、サイズ、および色を常に参照し、ユーザーの設定を順守します。フォント、サイズ、または色について、固定された値は使用しません。
  • 標準のシステム要素に似た外観を持つ任意の要素を作成者が独自に描画するには、テーマをペイントする API を使用します。

詳細については、「新機能: Aero の美しさ」、「 新日本語 ClearType フォント「メイリオ」について」、および「新機能: システム フォント (Segoe UI)」を参照してください。

ページのトップへ

ルール 2: コモン コントロールおよびコモン ダイアログを使用する

アクセシビリティを備え、高品質かつ一貫性のある UI をアプリケーションで実現するには、コモン コントロールおよびコモン ダイアログを使用します。標準の UI コンポーネントの再構築に時間をかけることは避け、代わりに、本来の品質やユーザーのニーズに対する理解に基づき、この時間を技術革新のために有意義に活用してください。

fig02

fig03

fig04

  • 次の Windows Vista コモン コントロールを使用します (ComCtl32 バージョン 6): バルーン、チェック ボックス、コマンド ボタン、ドロップダウン リスト、グループ ボックス、ネットワーク アドレス コントロール、リンク、リスト ボックス、リスト ビュー、進行状況バー、ラジオ ボタン、スライダ、静的テキスト、タブ、テキスト ボックス、ツールヒント、およびツリー ビュー。
  • 次の Windows コモン ダイアログを使用します: [色]、[検索と置換]、[フォント]、[ファイルを開く]、[フォルダを開く]、[ページ設定]、[印刷]、および [ファイルの保存] の各ダイアログ ボックス。
  • カスタム コントロールおよびコモン ダイアログのカスタム バージョンは、最後の手段として使用します。すべてのカスタムコントロールで Aero テーマが使用され、アクセシビリティが備えられていることを確認します。

詳細なガイドラインについては、「コモン コントロール」および「コモン ダイアログ」を参照してください。

ページのトップへ

ルール 3: 標準のウィンドウ フレームを使用して、グラス風ボーダーを効果的に使用する

標準のウィンドウ フレームを使用するだけで、Windows Vista のグラス風ボーダーを自動的に実現できます。

fig05

  • 標準のウィンドウ フレームを使用します。Windows Vista の透明なウィンドウ フレームとして表示される新しい "Aero グラス" は、見栄えと軽量さの両方を目指した、新しい美しさの重要な部分です。Aero デザインのこの外観は、Windows Vista 上で動作するすべてのアプリケーションに適用されます。
  • 非クライアント ウィンドウ領域での描画による、独自の非標準ウィンドウ フレームは作成しません。
  • 標準の画面解像度 (1024 x 768 ピクセル) を使用して、サイズ変更可能なウィンドウに最適化します。最小限の Windows Vista 画面解像度 (800 x 600 ピクセル) をサポートします。レイアウトにおいて、小規模なインターフェイス表面上でグラス風効果を使用することも可能で、アプリケーション ウィンドウ内でユーザーの注意をより重要な項目に集中させることに役立ちます。
  • アプリケーションのデザインに追加でグラス風の外観が必要な場合、開発者は Aero Glass API を介してこの視覚的処理を使用できます。アプリケーションにおけるグラス風効果の使用は、必須要件ではありません。UI にグラス風効果を付与すれば優れた Windows Vista ベースのアプリケーションが作成できるわけではありません。グラス風効果の目的は、アプリケーション表面の "重さ" を軽減し、UI の最も重要な部分に注目させることにあります。テキストや対話式の UI ではない、小規模な領域でグラス風効果を使用することが推奨されます。可能であれば、ウィンドウ フレームに接する表面でグラス風効果を使用し、より一体感のある "ルック アンド フィール" を目的としてアプリケーションをウィンドウ ボーダーに視覚的に統合します。

詳細なガイドラインについては、「ウィンドウ フレーム」、「ウィンドウ管理」、および「レイアウト」を参照してください。

ページのトップへ

ルール 4: Windows Vista のスタイルおよび品質に合致したアイコンとグラフィックスを使用する

アイコンは、アプリケーション、アイテム、アクション、実際の対象物、またはシステム内のコンセプト (コントロール パネルやネットワーク接続) を視覚的に表現したものです。UI の意味および目的をユーザーが認識し、習得するのに役立ち、位置およびアイテムを識別して "視覚的なランドマーク化" によりシステム内の検索を可能にします。

fig06

  • 機能やブランドを十分に反映した、優れたアプリケーション アイコンを作成します。識別可能かつ差別化されたアイコンを作成し、すべてのアイコン サイズ、すべての外観で適切にレンダリングされることを確認します。十分に時間をかけて、適切なデザインを作成します。社内グラフィック デザイナがいない場合、多くのデザイン企業のいずれかを選択し、このタスクを専門家に依頼します。
  • Windows Vista クライアント (アプリケーション、デバイス、ドキュメント タイプ、およびコントロール パネルなどのアイテム) で使用されるすべてのアイコンは、Aero スタイルのアイコン ガイドラインに準拠する必要があります。Win 9x および Win 3.1 スタイルのグラフィックスはすべて置換する必要があります。Windows XP スタイルのグラフィックスを Windows Vista で使用することは可能です。ただし、これらも新しいスタイルおよび品質に更新することをお勧めします。
  • 外観ではなく、意味に基づいてアイコンを選択します。アプリケーション全体にわたって、アイコンの意味の一貫性を確認します。システム内または一般的に使用される他の Windows ベースのアプリケーション内の既存アイコンまたは規則と競合しないことも確認します。
  • 必要なすべてのサイズでアイコンをレンダリングします。ただし、ユーザーによって最も頻繁に表示されるサイズのデザインに最適化します。たとえば、エクスプローラでは最大 256 x 256 ピクセルでアイコンを表示可能ですが、ツールバー アイコンは 24 x 24 ピクセルに制限されています。
  • ユーザーが Windows でやり取りするアプリケーションの主なファイル タイプについては、Windows エクスプローラ ビューでのこれらのファイルのライブ プレビューを取得するために、Windows Thumbnail API の使用を検討します。
  • 大きなアイコンには .PNG 圧縮を使用し、プログラムのサイズを制御します。
  • 標準のシステム アイコンを必要に応じて使用します。

詳細なガイドラインについては、「アイコン」、「標準のアイコン」、および「グラフィックス」を参照してください。

ページのトップへ

ルール 5: 新しいダイアログ ボックスや頻繁に使用されるダイアログ ボックス、エラー メッセージには、タスク ダイアログを使用する

ダイアログ ボックスはユーザー コミュニケーションの最も基礎的な形式です。明確なメイン インストラクション (説明部分) および明示的で即座に理解できるコミット (確定) ボタンを備えたダイアログ ボックスは、このコミュニケーションをさらに効果的にします。タスク ダイアログ API を使用すると、開発者は適切にデザインされた、一貫性のあるダイアログ ボックスを効率的に作成できます。適切に記述された、便利なエラー メッセージを提供するタスク ダイアログの作成も可能です。

fig07

fig08

  1. モーダル ダイアログまたは優先度の高いエラー メッセージにはタスク ダイアログを使用して、より優れた、理解しやすい UI を提供し、Windows Vista との外観上の一貫性を実現します。タスク ダイアログには Windows Vista 以降が必要です。つまり、タスク ダイアログは Windows の以前のバージョンには適しません。タスク ダイアログを使用できない場合は、Windows Vista のダイアログ ボックスに関するレイアウト ルールに準じ、Windows Vista テーマ ファイルを参照してダイアログを作成します。
  2. メイン インストラクション (説明部分) を使用し、明確で分かりやすい、簡潔な言葉を使用してダイアログにおける実行内容を説明します。優れた指示は、その操作のしくみに焦点をあてるのではなく、ダイアログの背後にある要点を伝えます。
  3. 続行する前にユーザーが積極的に決定する必要がある、頻度の低い、重要な選択については、モーダル ダイアログ ボックスを使用します。明示的に決断されるまでは変更が有効にならないように、遅延コミット モデルを使用します。
  4. 頻度が高く、繰り返しの多い進行中のタスクには、モードレス ダイアログ ボックスの使用を検討します。即座に変更が有効になるように、即時コミット モデルを使用します。ただし、多くの場合、このようなタスクにはツールバーおよびパレット ウィンドウがより適切な選択肢です。
  5. ユーザーへのメッセージ提供のみを目的とする場合、ダイアログ ボックスは使用しません。ユーザーがやり取りする必要がない場合には、作業ウィンドウ、バルーン、通知、またはステータス バーなどのモードレスの選択肢を使用します。
  6. 一般的なラベル ([OK] など) ではなく、メイン インストラクションへの具体的な応答である明確なコミット ボタンを使用します。ユーザーが読むだけでオプションをすばやく理解できるボタン テキスト提供します。コミット ボタンのラベルは常に動詞で記述します。
  7. ページに小規模な固定されたオプション セットが用意される場合、ラジオ ボタンの組み合わせやコミット ボタンではなく、コマンド リンクを使用します。これを使用すると、ユーザーはクリック 1 回で応答を選択できます。
  8. 詳細設定やほとんど使用しないオプション等、その他のオプションについては、"展開する" ボタンの使用により既定で非表示とするなど、ダイアログのクリーンアップを検討します。
  9. イベントが現在のユーザー アクティビティに関係しない場合や即座のユーザー アクションを必要としない場合、またユーザーがこのイベントを任意で無視できる場合、通知を使用します。このような場合、ダイアログは非常に邪魔になるので使用しません。
  10. ユーザーによるアクションの実行の可能性が低い場合や動作の変更の可能性が低い場合、または混乱を発生させずに問題の削除が可能な場合、エラー メッセージを提供しません。

詳細なガイドラインについては、「ダイアログ ボックス」、「タスク ダイアログ」、および「エラー メッセージ」を参照してください。

ページのトップへ

ルール 6: Aero ウィザードを使用する

シンプルかつ明快、優れたデザインを持ちテーマをサポートする Aero ウィザードが Wizard '97 に取って代わります。Aero ウィザードのページ レイアウトは非常に柔軟であり、サイズ変更が可能です。

fig09

  • "ようこそ" ページは使用しません。ただし、可能な限り、最初の画面で機能的な UI を提供します。次の場合に限り、オプションとして "はじめに" ページの使用を検討します。
    • 重大な前提条件がウィザードに存在し、前提条件なしの続行が時間の無駄となる場合
    • 最初の選択ページに基づくウィザードの目的の判断がユーザーにとって困難であり、より詳細な説明のための十分なスペースが存在しない場合
  • ウィザードの最後に、ユーザーにとって意味のない設定完了ページは使用しません。ウィザードの結果がユーザーにとって明白な場合、最終的なコミットでウィザードを閉じ、完了時のフィードバックがユーザーにとって明確であることを確認します。次の場合に限り、オプションとしてのフォローアップ ページの使用を検討します。
    • 結果が表示可能ではない場合など、完了時のフィードバックをユーザーに提供する他の方法が存在しない場合
    • フォローアップとしてユーザーが実行する可能性が高い関連タスクが存在する場合 ("電子メールの送信" などのフォローアップ タスクの頻繁な実行を回避します)
  • メイン インストラクションを使用し、明確で分かりやすい、簡潔な言葉を使用してページでの実行内容を説明します。優れた指示は、その操作のしくみのみに焦点をあてるのではなく、ページにおけるユーザーの目的を伝えます。他の部分において、言い回しを若干変更しただけのメイン インストラクションを繰り返しません。
  • コミット ページについては、[完了] などの一般的なラベルではなく、メイン インストラクションへの具体的な応答であるコミット ボタンを使用してタスクを確認します。これらのコミット ボタン上のラベルは、それ自体で意味をなす必要があります。コミット ボタンのラベルは常に動詞で記述します。
  • フォローアップ ページの場合、ウィザードを閉じるために [閉じる] を使用します。ウィザード ウィンドウを閉じるために、[終了] または [完了] コミット ボタンは使用しません。
  • 補助的なテキストおよびアイコンを備えた説明的な選択肢を提供し、ウィザード内をユーザーが効率的に移動できるように、コマンド リンクの使用を検討します。
  • 手順のいずれかにビューの表示が関連し、そのウィンドウ サイズを制御することがユーザーの役に立つ場合、ウィザードのサイズを変更できるようにします。

詳細なガイドラインについては、「ウィザード」を参照してください。

ページのトップへ

ルール 7: エクスプローラによってホストされるナビゲーション ベースのユーザー インターフェイスを使用し、[戻る] ボタンを提供する

ナビゲーション ベースのユーザー インターフェイス (単一のウィンドウから移動せず、左上隅に [戻る] ボタンが用意されていることを特徴とする) を使用すると、ユーザーは簡単かつ効率的に、自信を持ってナビゲーションすることが可能になります。ユーザーはいつでも "前に戻る" ことが可能です。本来は "ナビゲーション" しない従来のアプリケーションであっても、フレーム内でのナビゲーション機能を提供することによるメリットがしばしば得られます。

fig10

  • 使用される頻度の低い、複数のステップで構成され順序のあるタスクには、エクスプローラのウィンドウおよびウィザードを使用します。これによって簡単な移動が可能になり、ユーザーは順を追ってタスクを進めることができます。また、間違えた場合には、簡単にやり直すことができます。
  • アプリケーション全体での簡単なナビゲーションをサポートし、ユーザーによるアプリケーション内での異なるビューや記述の切り替えを簡単にするために、[戻る] ボタンを提供します。
  • 元のウィンドウが提供する他のタスクと同時にタスクが実行される可能性が高い場合、複数のウィンドウを使用します。

詳細なガイドラインについては、「ウィンドウ管理」および「ウィザード」を参照してください。

ページのトップへ

ルール 8: 標準の Windows 検索モデルを使用する

Windows Vista の検索ボックスでは、一致をフィルタリングまたは強調表示することで、ユーザーは大規模なデータ セット内部で特定のオブジェクトやテキストをすばやく検索できます。Windows Vista では、検索機能はエクスプローラのすべてのウィンドウにおける構成部分であり、動作も一貫しています。これにより検索と認識がより簡単になります。

fig11

標準の検索コントロールは存在しませんが、プログラムの検索機能を作成する場合は Windows 検索モデルに準拠させる必要があります。

  • アプリケーション ウィンドウの場合、検索ボックスを右上隅に配置します。
  • 標準の [検索] ボタン グラフィックスを使用します。ラベルは使用しませんが、[検索を入力] プロンプトを使用します。
  • 可能な場合は常に "クイック検索" 機能をサポートし、ユーザーの入力中に即座に結果を表示します。より長い時間を必要とする通常検索にもメリットがある場合には、通常の検索および "クイック検索" の両機能を提供します。
  • 可能な場合、検索結果の一覧から直前のビューに戻るための [戻る] ナビゲーションをサポートします。
  • 通常の検索では 5 秒以内に、また "クイック検索" では 2 秒以内に該当する結果を返す必要があります。この時点以降、プログラムが応答し、ユーザーが他のタスクを実行できる限り、より関連度の低い結果を検索機能は時間をかけて表示することができます。"ビジー" インジケータを使用して、動作状況に関するフィードバックを提供します。これにより、ユーザーは検索が実行されていることを認識できます。

詳細なガイドラインについては、「検索ボックス」を参照してください。

ページのトップへ

ルール 9: すべての UI テキストで Windows Vista トーンを使用する

Windows Vista トーンを使用して、明確でユーザーを勇気付け、直感的に操作可能で客観性を備えたユーザー指向の環境を提供することで、個人レベルでユーザーとコミュニケーションを行い、ユーザーが自信を持って操作できるようにします。混乱するような表現や、見下すような表現 (たとえば、"とにかくこれを実行しなさい" など)、また横柄な表現は使用しません。

  • テキストが明確かつ自然、簡潔であることを確認します。また、形式的すぎず、すべてのユーザーが理解できる用語を使用していることを確認します。
  • 可能な場合は日常的な言葉を使用し、会話で使用しないような言葉を避けます。複雑で技術的な概念や動作を説明する場合、これは特に効果的です。ユーザーの肩越しに眺め、タスクを達成する方法を説明している自分自身を想像してみます。
  • 多くの場合、ユーザーはテキストを拾い読みするので、すべての言葉を意味のあるものにします。簡単かつ簡潔な文 (および段落) は、画面上のスペースを節約するだけではなく、概念または動作が重要であることを伝えるための最も効果的な手段でもあります。的確に判断し、文を簡潔にします。ただし、表現が無愛想であったり、理解が困難になるほどには簡潔にしません。
  • 繰り返しを避けます。各ウィンドウを見直し、反復する言葉と記述を削除します。重要なテキストは削除しません。必要な場合は常に明示的である必要がありますが、冗長性を避け、明らかなことは説明しません。

詳細なガイドラインについては、「スタイルとトーン」、「MSX UA スタイル ガイド」、および「MSX UA ワード リスト」を参照してください。

ページのトップへ

ルール 10: ユーザー インターフェイスをクリーンアップする

ユーザー インターフェイスの設計時には、散らかったような印象を与えないようにし、外観を視覚的に統一します。よく整理し、検討した外観を与えるようにします。

  • タスク ベースの分類とラベルを使用して、わかりやすく見つけやすいシンプルな表示としてコマンドを実装します。
  • ドキュメントの作成や表示を行うプログラムでは、[ファイル]、[編集]、[表示]、[ツール]、[ヘルプ] などの標準のメニュー分類を使用します。
  • 上記以外のタイプのプログラムでは、作成するプログラムの用途に基づいて、より使いやすく、自然な分類となるようにコマンドやオプションを整理します。タスクや目的について、ユーザーの観点から検討してください。標準のメニュー分類が、作成するプログラムには適していないと思われる場合、無理に準拠させる必要はありません。
  • よく使用される主要コマンドは、コマンド表示の最上位に配置して、ユーザーがすぐに見つけられるようにします。コマンドが効果的に利用されるよう、使用頻度の高いメニュー項目を下位メニューに配置することのないようにしてください。ただし、使用頻度の高いコマンドであってもツールバーなどですぐにアクセスできるものに関しては、サブメニューに配置してもかまいません。
  • すべてのオブジェクトとウィンドウ領域に対して、コンテキスト依存のコマンドとオプションから構成されるコンパクトなショートカット メニューを用意します。多くのユーザーは、どのような場所においても右クリックでショートカット メニューが表示されることを期待しています。
  • ツールバーや直接実行が可能なコマンドで、大多数のユーザーが使用する大半のコマンドが提供できている場合は、メニュー バーの非表示について検討します。ツールバー内にメニュー バーのチェック マーク オプションを提供し、ユーザーが表示/非表示を選択できるようにします。
  • よく使用される主要メニュー項目についてはアイコンを提供します。アイコンは、標準的でよく知られているもの、またはコマンドの内容を明確に伝えるものであることが必要です。なお、メニュー項目すべてにアイコンを使用する必要はありません。
  • キーボードを使用したアクセスに対応するため、すべてのメニュー項目にアクセス キーを割り当てます。
  • 必ずしも必要でなかったり、実際には使用されないボーダー、区切り線、ボックス、およびその他の視覚的な "ノイズ" を削除します。
  • 不要なテキストを削除します。ラベルでの言葉の重複を除外します。
  • コンテキストや選択に応じ、ホバーによって (マウス ポインタが置かれたときに) 状況を表示したり、UI を変更したりします。
  • 既定の UI を慎重に選択します。可能性の低い状況や複雑な状況に対して最適化するのではなく、最も一般的なユーザー シナリオを対象としてデザインを行い、模範的なエクスペリエンスとして完結することを確認します。
  • 既定の記述においては複雑なものは非表示にします。可能な場合は要素の視覚的なデザインを簡略化し、ポイントしたときに詳細と機能を表示します。
  • レイアウトを改良します。ボーダー、テキスト、およびオブジェクトを揃えます。十分なスペースを提供し、アイテムがお互いに重なったり、詰まって表示されたりしないようにします。
  • UI においては、一般的な要素の一貫した使用を確認します。非標準の使用がユーザーまたはエンド ユーザーのニーズを具体的に満たす場合を除き、標準的なコンポーネントおよびコントロールを使用します。

ページのトップへ

ルール 11: 通知を慎重に使用する

適切に使用される場合、通知はユーザーに情報を伝えるための効果的な方法です。通知は、有用かつ関連性のある、それほど重要ではない情報を表示するには理想的です。その周辺的な、モードレスの表示によって、ユーザーのタスク フローが妨げられないことがその理由です。

fig12

  • 本当に必要な場合にのみ、通知を使用します。優れた通知はユーザーに対して関連性があり、対応する操作が存在するものです。通知を表示すると、ユーザーの操作を妨害し、場合によっては邪魔になることもあります。中断の正当性を確認します。
  • ユーザーによる即座の操作を必要としない、それほど重要ではないイベントまたは状況に通知を使用します。ユーザーによる即座の操作を必要とする重要なイベントや状況には、他の選択肢である UI (モーダル ダイアログ ボックスなど) を使用します。
  • その用途に基づき、7.5 (情報通知) ~ 25 秒(対話的な通知) の範囲で、適切な長さの通知表示時間を選択します。
  • 通知をクリック可能にして、ユーザーによる操作または詳細情報の表示を実行できるようにします。通知のクリックによって、ユーザーが操作を実行できるウィンドウが表示される必要があります。
  • ユーザーに伝える必要がある、最も重要な情報を簡潔に要約する見出しテキストを使用します。ユーザーは通知情報の目的を、迅速かつ容易に理解できる必要があります。
  • 説明を提供する本文テキスト (ただし見出しの情報を繰り返さない) を使用します。また、オプションとして、通知の具体的な詳細を提供し、可能な操作をユーザーに知らせる本文テキストも使用します。
  • カスタムの通知メカニズムは作成しません。代わりに、標準の Windows 通知を使用します。

詳細なガイドラインについては、「通知」および「通知領域」を参照してください。

ページのトップへ

ルール 12: 最終調整のための時間を十分に確保する

高い完成度を達成するために、ピクセル レベルでの視覚的なクリーンアップ、レイアウト (配置、間隔) 修正など、UI の詳細を検討する時間を確保します。視覚的な "完成度" は、通常のバグ修正やその他の品質管理同様に重要な要素です。

認識こそが現実となります。製品全体においてユーザーが高品質を体感できない場合、すべてにおいて品質に欠けると判断される可能性があります。すべてのユーザーに表示される視覚的なバグは、発生することがまれな破壊的なバグよりも、プログラムの評価に対してより深刻な影響を与える可能性があります。

上記ドキュメントへのご意見、ご要望がございましたら、 こちら からお願いいたします。
お客様からのご要望として開発部門にフィードバックし、今後の弊社製品の向上に役立たせていただきます。

 

ページのトップへ

評価してください: