ユーザー インターフェイスの原則

このトピックでは、直感的なユーザー インターフェイスとユーザー エクスペリエンスの設計原則を Windows アプリケーションに実装する方法について説明します。

• はじめに
• 適切な UI の基本原則
  • 間隔と配置
  • [サイズ]
  • グループ化
  • 直観性
• より優れた機能的なユーザー エクスペリエンスのための 20 のヒント
  • 標準を使用する
  • 重要なボタンに注意を引く
  • アイコンを使用して認識を簡略化する
  • ヘッダーを使用して認識を簡略化する
  • カスタム メッセージ ボックスを使用する
  • 代替コマンドを含める
  • 重要なアクションを処理する方法
  • RadioButtons にするか ComboBoxes にするか
  • ユーザーを混乱させない。
  • 進行状況の提供
  • ウィザードを使用して複雑な手順を簡略化する
  • テキストのトーンを正しく取得する
  • ListView の方が優れている場合がある
  • 階層リンク コントロールとサイドバーを使用してナビゲーションを簡略化する
  • プリティ グラフィックスを使用する
  • 可能な場合はサイズ変更可能なフォームを提供する
  • サイドバー/タスク ウィンドウを使用して他の機能を提供する
  • 通知の選択を行う
  • ツール ヒントを提供しよう。
  • 些細な事を忘れない
• まとめ

はじめに

多くの場合、開発者はエンド ユーザーの視点を考慮に入れるのを忘れます。 開発者は、アプリケーションを動作させるために努力します。お客様は、アプリケーションが動作することを期待し、ソフトウェアに対する認識がこの要件を中心にしています。 これは特に、小売ソフトウェアを開発する場合や、技術者以外のユーザーが使用する場合に当てはまります。 開発者は、ソフトウェア設計プロセス全体を通じてエンドユーザーのニーズを認識する必要があります。

ソフトウェア アプリケーションは、可能な限り簡単にナビゲートして使用できる必要があります。 多くのソフトウェアが作られる中、エンドユーザーが本当に気に入り、すぐに快適に使える素晴らしい UI を持つソフトウェア プリケーションは、10 中 4 本と言われています。

企業向けに大量の社内使用ソフトウェアが作成されています。 社内で開発された場合でも、コンサルタントの世話を受けている場合でも、多くの場合、最小限の時間、労力、またはコストが、より良い UI の作成に投資されます。 開発サイクルでは、特に Windows アプリケーションの世界では、`デザイナー` の役割はまれです。

アプリケーションの見栄えを良くし、UI の機能を向上させるために従う必要がある基本的なルールがいくつかあります。 それはあなたの部分にあまりにも多くの時間やお金の投資を必要とせず、投資に良いリターンを追加します。

先に進む前に、(少なくともこの記事の範囲について) ユーザー インターフェイスとユーザー エクスペリエンスの区別をしましょう。 ユーザー インターフェイス (UI) とは、アプリケーションのビジュアルとコントロールを指しますが、ユーザー エクスペリエンス (UX) には、UI に関連するアプリケーションの UI と動作の両方と、ユーザーがアプリから取得する "感情" が含まれます。 見栄えの良い UI を設計するだけでなく、優れた動作を確保することも重要です。

ここでは、アプリケーション設計フェーズに簡単に統合できる UX 設計の 20 ポイントを説明します。 その結果、より優れた直感的な機能 ("人間の UX") を備えた、より豊富なアプリケーションが得られます。 私たち全員が知るように、アプリケーションの Windows Vista 世代は、見た目も動作も別のものである必要があります。 このトピックは、現在のユーザーに未来を味わってもらいながら、将来のアプリケーションに備えるのに役立ちます。

次のセクションでは、適切な UI デザインの基本について説明します。

適切な UI の基本原則

プロフェッショナルな見た目の UX は、次の 4 つの要因に依存します:

• 間隔と配置
• サイズ
• Grouping
• 直観性

8.0 より前のバージョンの Microsoft Visual Studio では、間隔とサイズ設定が最適とはいえませんでした。 4 x 4 または 8 x 8 のグリッドが常に機能するとは限りません。 SnapLines を含めることで、プロセスが大幅に簡略化されました。 以前のバージョンの Visual Studio では、ラベルをテキスト ボックスに合わせるか、さらに悪いことに、複数のラベルを対応するテキスト ボックスに配置することは非常に困難でした。 SnapLines により、このプロセスが大幅に簡略化されました。

以降のセクションでは、プロフェッショナル UX 設計の 4 つのより重要な側面について説明します。

間隔と配置

2 つのコントロール間の間隔が重要です。 次のスクリーン ショットは、ユーザー情報の入力フォームが適切に設計されていないことを示しています。上位 2 つのテキスト ボックスが近すぎる、その下のリストが遠すぎる、フォームに使用されていない余白が多数あります。

次のスクリーン ショットでは、コントロールが適切な間隔とサイズで配置された、よりプロフェッショナルなダイアログが表示されています。 これは前のスクリーン ショットと同じ形式ですが、SnapLines で推奨される間隔を使用するように変更されました。 ラベルは、コントロールの実際の下罫線ではなく、テキスト ボックスまたはその横にある他のコントロールのテキスト ベースラインに合わせることをお勧めします。 SnapLines は、その配置に達すると別の色に変わり、通常は下の罫線より数ピクセルだけ上になります。

間隔に関する正確な規則はありませんが、SnapLines には適切な間隔を設定するための非常に便利なガイドラインが用意されています。 適切な間隔を保つために役立つその他のツールは、[コンテナー] ツールボックス グループの [レイアウト] コントロールです。 TableLayoutPanel は、入力フォーム スタイルのダイアログ ボックスを作成する場合にも非常に役立ちます。

サイズ

サイズにも同じ考慮事項が適用されます。 ツールボックスからフォームにボタンをドラッグすると、高さと幅が最適になります。 推奨される最大幅 (重大な理由がある場合を除く) は、元の幅を 2 倍にするためです。

[スタート] メニューの [実行] ウィンドウ、または任意の Windows エクスプローラー オブジェクトの [プロパティ] ダイアログを見ると、ボタンのサイズは `ちょうど` になります。 エンド ユーザーに気づいてもらわなければならない非常に重要な機能がある場合は、大きなボタンを使用したり、標準以外の色を表示したりする以外の方法があります (後で詳しく説明します)。

次の図には、3 つのボタンがあります。 最初のボタンは最も推奨されるサイズであり、ツールボックスからドラッグ (またはダブルクリック) したときに既定で作成されるサイズです。 場合によっては、テキストの超過によりボタンを長くしなかえればならないこともあります。 2 番目のボタンは、大きいけれども許容できるサイズのものです。 他のコントロールをレイアウトするのに問題になることはないでしょう。 ただし、3 番目のボタンは完全に許容できないサイズです。 テーマ付きコントロールを描画するために Windows が使用するテーマ ビットマップがわずかに歪んでいることさえわかります。 また、他のコントロールを直感的に配置するのが難しくなります。

Grouping

通常、アプリケーションには多くのコントロールが含まれています。 適切で直感的なグループ化をすることでのみ、これらすべてのコントロールを使いやすくすることができます。 関数ベースまたは分類されたグループ化は、タブ コントロールによって最適に実行されます。 たとえば、`アカウント`、`レポート`、`従業員`、`プロジェクト` は、一般的なビジネス アプリケーションのタブに最適な候補となるでしょう。 兄弟グループ化 (同じ最終結果に寄与するコントロール) は、グループ コントロールで行うのが最適です。 このようなグループ化に罫線付きのパネルを使用することはお勧めしません。 グループ コントロールを使用すると、特にサブコントロールがわかりやすい場合に、ラベル コントロールの追加の重みを節約できます。

グループ コントロール内のグループ コントロールは、1 つの大きなグループ コントロール内に 2 つまたは 3 つ以下のコントロールがない限り、推奨されません。

直観性

これは、優れたユーザー エクスペリエンスの最も重要な側面です。 直感的な UX により、説明の必要性が軽減されます。 ユーザーにはコントロールで何ができるかしかわかりません。

直感的なデザインの重要なトピックは、色分けです。 その好例が Windows XP で、テーマ別アプリケーションのナビゲーション、[ログオフ] や [コンピュータの電源をオフにする] ダイアログなどの機能に新しいソフトスクエア ボタンを提示しました。

これらのコントロールの色分けは、そのボタンが押された結果の重大度に基づいて決定されました。 ナビゲーションは緑色で、`進め` の信号とよく似ています。 [シャット ダウン] のように作業が失われる可能性があるものは、警告サインのように赤色に色づけられています。 ログオフや休止状態などの準クリティカルなボタンは黄色です。 ヘルプなど、ユーザーの作業プロセスに重大な影響を与えないニュートラルなボタンは、ソフト ブルーです。 スキン UI を作成するときは、これらの色の側面に留意する必要があります。

色によるコンテンツの認識の最たる好例は、Microsoft Office OneNote です。 アプリケーションのタブは異なる色に設定できますが、基本的には Windows XP スタイルの全体的なデザインの適切な部分のように見えます。

もう 1 つの重要な側面は、アプリケーション内のテキストです。 最近では、Windows ソフトウェアで記述された命令に使用される言語を簡略化するためのさまざまな取り組みが行われています。 ソフトウェア内でのテキストの使用方法については後で説明しますが、次の小さいけれど重要な詳細に注意してください。

MSN Messenger の [オプション] ダイアログに [Web カメラの機能を共有する] というチェック ボックスがありました。開発者や技術に詳しい人ならその意味がわかるでしょうが、初心者のユーザーなら、チャットの相手側にいる他のユーザーにも Web カメラを使わせることができると思うかもしれません。 最近のバージョンでは、これを "マイ Web カメラ:自分が Web カメラを持っていることを他のユーザーに知らせる" に変更しています。 これは、専門的な知識を持たず、シンプルな言い方に慣れている対象ユーザーには最適です。

よりシンプルな言い方を使用すると理解しやすくなりますが、利点もあります。 科学的な研究によれば、新しいことを理解しようとするとき、人間の心理はより単純な言葉のほうが働きやすいということです。 多くの場合、脳は `it`、`for`、`that` など一般的な単語を迅速かつ簡単に処理するため、上記の例では、`Web カメラ` や `他のユーザー` のように目立つ単語を理解するために、より多くの `帯域幅` が割り当てられます。

メッセージ ボックスのタイトル、GroupBox キャプション、その他のテキスト ブロックを使用すると、コントロールのグループの機能をエンド ユーザーにわずかな文字数で簡単に伝えられます。

直感性も親しみやすさから生まれます。 例えば、[OK] ボタンと [キャンセル] ボタンの配置は、私たちの頭の中で非常に統一され、うまく配置されているため、もしダイアログでこれらのボタンが逆の順序（[OK][キャンセル] の配置ではなく、[キャンセル][OK]）で配置されていたら、間違って [キャンセル] を押してしまうかもしれません。 Windows ベースのアプリケーションなど、特定の標準を 1 年以上使用すると、習慣が生まれます。 業界標準に従うことは (それがどんなに明文化されていないものであっても)、ソフトウェアを使いやすくなります。

初期の Windows Vista プレビュー ビルドの 1 つでは、ウィンドウの [最小化]、[最大化]、[閉じる] ボタンが異なっています。 以前のバージョンの Windows では (特に 1 台のモニターを使用する場合)、画面の右上隅にカーソルを移動してクリックする習慣が身に付きます。 これにより、常にウィンドウが閉じられます。 Windows Vista のこの特定のビルドでは、[閉じる] ボタンとウィンドウの右端の境界線の間に約 8 ピクセル分のスペースがありました。 余分なスペースを持たせたことで、見た目は格好よくなりましたが（おそらくボタンがクールな輝きを放つアニメーションを表示するために必要だったのでしょう）、開いているウィンドウを簡単に閉じることができず、イライラさせられました。 気持ちの再調整は難しいものです。 幸いなことに、次のビルドでは、この問題に対処しました。 ウィンドウの境界線と閉じるボタンの間にスペースが残っていますが、そのスペースをクリックするとウィンドウも閉じられます。

直感的な設計の非常に重要な要素は、`精神的な帯域幅` の量 (何かを理解するために心が要する時間) です。 `帯域幅` の使用量が少ないほど、ユーザー エクスペリエンスが向上します。

これらは、ソフトウェア アプリケーションを使用する "エクスペリエンス" に寄与する小さな要素です。 次の例では、実際のヒントとテクニックを使用してアプリケーションを改善するためのヒントを示します。

より優れた機能的なユーザー エクスペリエンスのための 20 のヒント

より優れたユーザー エクスペリエンスの目標は、見栄えの良い、よりシンプルで簡単で機能的な UI を持たせることです。 以下のヒントは、UI をより効果的に形成するのに役立ちます。

標準を使用する

オペレーティング システム レベル、ブランド レベル、またはアプリケーション レベルに関係なく、ソフトウェア環境の確立された標準はきわめて重要です。 ブランディングだけでなく、規格はユーザーの頭の中で諺のようなスキーマとして機能します。 ユーザーがソフトウェア プリケーションで長時間作業すると、使い慣れてきて自動的に生産性が向上します。

標準について説明する前に、まずこれらの標準とは何かを説明しましょう。 標準には、[OK] ボタンや [キャンセル] ボタンのようなダイアログ ボックス上の特定の方法によるコントロールのレイアウト、Windows XP のダイアログのようにウィンドウ上部の角を丸くしたユーザー インターフェースの形状、アイコンのスタイル、その他のグラフィックスのスタイル、アプリケーションの対話型動作など、ありとあらゆるものが含まれます。

アプリケーションが特定のニッチに分類される場合は、別の標準セットに従う方が良い場合もあります。 たとえば、アプリケーションで Office OneNote 2003 のアプリケーションまたはアドオンがサポートされている場合は、Office の UI と対話機能の標準のスタイル、特に OneNote 自体に従うことをお勧めします。 これには、標準ツール バーではなく Office スタイルのコマンド バーの使用や、ビジュアルと動作の両方など、その他のコマンド バーの使用が含まれます。 アプリケーションが Microsoft Visual Studio .NET カテゴリの一部になる場合は、別の標準セットがあります。 実際、このようなアドオンやサポート アプリケーションの場合、Microsoft などの企業は、書面によるガイドラインをリリースしています。 また、場合によっては、グラフィックスやデザインの概念が保護された知的財産であることにも注意してください。 必ず適切なドキュメントをチェックして、そうした設計を作成するためのライセンスがあることを確認してください。

標準の 3 番目の例は、タブレット PC 環境です。 これらの標準は、オペレーティング システムのガイドラインとアプリケーション ガイドラインの境界を超えるものです。 Tablet PC SDK のドキュメントには、「アプリケーションの計画」トピックに非常に役立つ情報が含まれています。 これらの設計に関する推奨事項は、Office 2003 または Visual Studio のガイドラインとは異なり、ユーザーがアプリケーションを操作する方法と、その動作に直接影響します。 たとえば、アプリケーションにドッキング ウィンドウがある場合、ドキュメントでは、画面の向きがいつ変更されたかを検出できること、およびドッキング ウィンドウが必要に応じて縦向きまたは横向きで適切に再構成されることを確認することをお勧めします。 タブレット固有のアプリケーションを設計していない場合でも、これらのガイドラインを確認する必要があります。

スマート クライアントの台頭に伴い、アプリケーションは、通常の PC、タブレット PC、モバイルまたは Ultra モバイル デバイス、メディア センター PC など、さまざまなハードウェア間の境界を跨ぐものになりました。 各状況で、異なる (または追加の) 標準セットに従う必要があります。

アプリケーションがオペレーティング システム レベルまたはアプリケーション レベルの標準を共有する場合、ユーザーはソフトウェアを使い慣れやすく、学習と使用が容易になります。 この結果、生産性を直接向上させることになります。 ユーザーは、新しいソフトウェアをできるだけ早く使用して生産性を高めたいと考えています。

重要なボタンに注意を引く

他に 4 つまたは 5 つのボタンが横たわっている場合でも、ユーザーを最も重要なボタンに誘導する必要がある場合があります。 サイズや色、フォントを変えることは、標準を破ることになり、お勧めできません。 代わりに、いくつかの簡単なテクニックを使用してこれを実現できます。

1 つ目は、次の図に示すように、他の重要でないボタンを LinkLabels に変換することです。 これにより、ユーザーはこれらのリンクがタスクを実行することを認識しますが、標準の設計ガイドラインを破ることなく、目立つボタンに注意を向けるようになります。

2 つ目は、次の図に示すように、左に水平レイアウトの場合は左、垂直レイアウトの場合は上に、最重要のボタンを 1 行目に配置することです。 これはターゲット ユーザーのカルチャによって変わる可能性があることに注意してください。アプリケーションが右から左に記述される言語であれば、問題のボタンを右端に配置したほうが上手くいくかもしれません。

推奨されるオプションは、既定でフォーカスを受信するように設定することです。 たとえば、削除の確認ダイアログでは、[いいえ] オプションを強調表示する必要があります。これにより、ユーザーは誤って何かを削除できなくなります。

アイコンを使用して認識を簡略化する

アイコン (特に Windows XP および Office 2003 のアイコンとツール バー ビットマップ) は、UI とユーザーが実行する必要があるタスクの認識を高速化するのに役立ちます。

たとえば、メッセージ ボックスに最もよく表示される感嘆符アイコンが表示されると、そのアイコンの横にあるコントロールに関連するリスクのレベルがすぐにわかります。 同様に、アプリケーションがどれだけ適切に配置されているかに関係なく、多くのコントロールを配置する場合、探しているコントロールのセットを見つけるのが難しい場合があります。

Windows XP Service Pack 2 では、"自動更新" という名前のシステム プロパティ コントロール パネル アプレットに、更新されたタブが追加されています。 更新プログラムを自動的にダウンロードする、更新プログラムをダウンロードするがインストールのタイミングはユーザーに決定させる、更新プログラムが利用可能な場合はユーザーに通知するがダウンロードは開始しない、自動更新を完全に無効にする、という 4 つのオプションがあります。

新しい PC ユーザーは、これらの更新プログラムの内容を認識していない可能性があり、どのオプションを選択するのが最適か分からない可能性があります。 そのため、Microsoft では、"安全な" オプションであることを示す最もおすすめの横に大きなチェック マークが付いた緑色のシールド アイコンと、ユーザーに有害な可能性があるアイコンの横に大きな "x" が付いた赤いシールド アイコンが表示されています。 これは重要な状況、特にユーザーがあまり多くのテキストを読む時間がない場合に非常に役立ちます。

同じ システム プロパティ アプレットでは、各タブには複数の GroupBox があり、タスクごとに異なるコントロールがあります。 コントロール グループのタスクを簡単に表す相対グラフィックが各グループの横に配置されます。 この種類のグラフィカル コードは、物理的なファイルや駐車場での色分けと似ています。 これは、雑誌の記事に少なくとも一部のビジュアルを含めるという原則同様に機能し、読者の関心を維持します。

適切なアイコンを選択することも重要です。 Microsoft では、Visual Studio 2005 の一部として多くの標準グラフィックスを提供しています。 これらは最良の選択です。 独自のアイコンを作成する場合は、上記の「標準の使用」セクションで説明したように、これらのグラフィックスのオペレーティング システム レベルまたはアプリケーション レベルの標準に従うことを強くお勧めします。

「Windows ユーザー エクスペリエンスの操作ガイドライン」には、Windows スタイルのアイコンを作成するための非常に役立つガイドが含まれています。

ヘッダーを使用して認識を簡略化する

ヘッダーは、ダイアログ全体を 1 つの文 (および必要に応じてグラフィック) で説明するのに最適な方法です。 ヘッダーは、その中のナビゲーションやコマンドに対応するのにも役立つ場合があります。 ヘッダーは、ダイアログがポップアップ表示されたときにユーザーに最初に表示されるため、通常の説明ラベルよりも効果的に機能します。

Windows インストーラー ウィザードは、おそらく最も一般的なヘッダーです。右端の単純なアイコンです。ダイアログを説明するタイトル ラベル (インストール フォルダーの選択など)。ダイアログの目的を説明するサブ見出し (たとえば、ソフトウェア ファイルがインストールされるフォルダーを選択します)。

たとえば、アカウント セクションを含む一般的なビジネス アプリケーションがあるとします。 Windows Vista でサポートされているデザイン パラダイムに従って、ミッション クリティカルな情報と関連コマンドをヘッダー (シナリオで呼び出す場合はフッター) 自体に提供できます。 ユーザーが "Big Company" のアカウント ファイルを開きました。ヘッダーは、次のスクリーン ショットに示すような内容になります。

次のスクリーン ショットは、ダイアログ ボックスの詳細ヘッダーの例を示しています。

同様に、これらのコマンドをヘッダーに移動することで、Windows XP スタイルのタスク ウィンドウを追加する必要を回避できます (特に、いくつかのコマンドを使用するだけで、垂直方向のスペースが大量に無駄になる場合)。

ヘッダーを設計するときは、次の点に注意する必要があります:

• 背景色がダイアログの背景色と異なっていることを確認します。 多くの場合、標準の Windows 組み込みコントロールの表面色の上に白いヘッダーが表示されます。 しかし、特別なテーマやカスタムの色がヘッダーを混乱させないようにしたい場合は、Color.FromKnownColor と ControlLight と ControlDark の色を使用して LinearGradient を描画します。
• 可能であれば、ヘッダーの高さを 150 ピクセル未満にしてください。 通常、100 または 120 の高さでうまくいきます。 原則として、フォーム全体の高さの 1/4 未満であることを確認します。
• 上記のヘッダーに示されている情報のインプレース編集を追加する場合は、LinkLabel をテキスト ボックスに動的に置き換え、編集が完了したら、もう一度入れ替えます。
• フォントのサイズが 10 pt を超えるタイトル ラベルがある場合は、Arial または Franklin Gothic Medium を使用します。 MS Sans Serif は、ギザギザが過剰でプロらしく見えません。 Franklin Gothic Medium は、Windows XP の設計ガイドラインに関するドキュメントの推奨事項です。 Windows Vista を対象とするアプリケーションの場合は、システムの既定のフォントである Segoe UI フォントを使用します。

カスタム メッセージ ボックスを使用する

標準の Windows メッセージ ボックスで使用できるオプションは非常に限られています。 単純に Yes/No または OK/キャンセル では回答できない質問をユーザーに尋ねる必要がある場合は、複雑になります。

技術に詳しくないユーザーが多いため、Windows アプリケーションは使いやすくなりました。 場合によっては、ボタンにわかりやすいテキストやいくつかの追加のコントロール (LinkLabels など) を提供して、手元のタスクを簡単に実行できるようにする方がはるかに簡単な場合があります。

Microsoft .NET Framework を使用すると、カスタム ダイアログを簡単に実装できます。 カスタム ダイアログ フォームに 2 つのプロパティを割り当てるだけで、またはコードを 1 行で割り当てるだけで、フォームは標準のメッセージ ボックスと同じように動作します。 ボタン クリック イベントで、ダイアログの DialogResult プロパティを DialogResult.Ok または DialogResult.Cancel に設定します。 親フォームから ShowDialog([OwnerForm]) メソッドを使用します。 このメソッドは、DialogResult 値を返します。

DialogResult のすべてのメンバーを使用できます。 これらの同じオプションは、標準の MessageBox.Show メソッドで使用されます。

または、ダイアログの AcceptButton プロパティを btnOK に設定し、CancelButton プロパティを btnCancel に設定することもできます。 これにより、Enter キーと Esc キー が btnOK ボタンと btnCancel ボタンのそれぞれの Click イベントに自動的にマップされます。

カスタム ダイアログを盛り上げるヒントを次に示します:

• 複雑なトピックの場合は、適切なテキスト ラベルの下に "詳細を見つける" というリンク ラベルを使用して、ローカルまたはオンラインのヘルプへのリンクを提供します。
• [はい]/[いいえ]/[キャンセル] ボタンの代わりに、[ファイルの保存と終了]、[保存せずに終了]、[終了しない] など、ボタンをクリックしたときの結果を明確に示すテキストを使用します。ただし、可能な限り、標準の [はい]/[いいえ]、[OK]/[キャンセル]、およびそのような標準ボタンを使用するようにしてください。 使い慣れてくると、生産性が向上します。
• 左側 (またはターゲット カルチャの設定に応じて右側) に 50 ピクセル分の余白領域を保持し、ダイアログのシナリオを表すアイコンを追加します。 情報ダイアログの場合は、標準のメッセージ ボックスで使用される "i" アイコンを使用できます。セキュリティ ダイアログの場合は、ロック アイコンまたはキー アイコンを使用できます。 Visual Studio 2005 には、優れた高品質のグラフィックスが搭載されています。
• これらのボタンに適切なキーボード ナビゲーションが用意されていることを常に確認します。ユーザーは、メッセージ ボックスのキーボード ショートカット (たとえば、OK には O、Yes には Y、キャンセルには C など) を頻繁に使用します。 カスタム ダイアログでそれが使用できないと、ユーザーは間違いなく困ることでしょう。

代替コマンドを含める

2 つの重要な要因によって、代替入力方法の必要性 (フラストレーションとレイジネス) が決まります。 フラストレーションは、コンピューター ユーザーにとっては日常茶飯のことです。 フラストレーションがあるときは、タスクをすばやく実行する必要があります。 余分なクリックや数秒の待機時間は、ストレスにさらされている人を本当にいらいらさせます。それは皆さんもご存じでしょう。 レイジネスは、キーボードかマウスのどちらか今使っている方だけでタスクを終わらせようとさせます。 ただし、これら 2 つの要因以外に、代替の入力方法を使用すると、ユーザーはタスクを簡単に実行できます。

たとえば、いずれかの側に 2 つのボタン ([追加] と [削除]) があるリスト ボックスがある場合は、それらのボタンに似たメニュー コマンドを含むリスト ボックスのコンテキスト メニューを追加する必要があります。 これにより、ユーザーは最も適切な方法を選択できます。 Windows Vista ユーザー エクスペリエンス ガイドラインにあるように、初心者はコンテキスト メニューをよく使うので、右クリックする場所にコンテキスト メニューがあることを期待します。

同様に、テキストまたは数値入力にはビジュアル コントロールを使用します。 たとえば、スライダーは整数を指定するために使用され、カレンダー コントロールは日付入力に使用されます。 単に入力する方が、より快適に入力できる場合もあります。 スライダーにリンクされた数値アップダウン コントロールを追加する場合や、カレンダー コントロールの代わりに DateTimePicker を使用すると、ユーザーにとって違いが出ることがよくあります。

重要なアクションを処理する方法

重要で回復不可能な機能を実行する場合は、通常、メッセージ ボックスをポップアップしてアクションを確認することを推奨します。 さらに一歩進めましょう。 次のスクリーン ショットでは、同様のカスタム メッセージ ボックスが表示されますが、利点が追加されています。タイマーは進行状況バーを使用して視覚的に表示されます。

使用できるシナリオ固有のバリエーションがいくつかあります。 実行する操作が非常に重要な場合 (原子力プラントの過負荷からファイルの完全な削除に至るまで)、タイマーが切れた後の既定の操作を取り消す必要があります。 ダイアログが消えるのではなく、テキスト ラベルが変更され、操作が取り消されたことを示します。 ユーザーは、コマンドの確認または取り消しを選択できます。

重要な操作を実行するボタンが明確にマークされていることを常に確認します。常に、操作を正確に記述するクリア テキストを使用します。 操作がファイルの削除である場合は、「リポジトリからファイルを取り除く」とは書かずに、「リポジトリからファイルを削除する」と書き込みます。ファイル リストを操作するときに、[削除] メニュー コマンドで選択したファイルがハード ディスク自体から削除された場合 (ファイル リストからの削除ではなく)、この重要な性質を適切に強調し、操作によってファイルが完全に削除されることを明示的に強調する必要があります。

「あなたはその最悪の仕事と同じくらい良い仕事をしている」と誰かに言われたことがあります。ソフトウェア アプリケーションにも同じことが当てはまります。 アプリの 1 つの不適切なエクスペリエンスは、ユーザーに大きな否定的な印象を与える可能性があります。 これが起こらないようにするには、アプリケーションがクラッシュした場合に正常にダウンすることを確認する方法があります。 データ復旧を追加したり、ユーザーがそのデータのコピーを保存したりできる場合は、大きなプラスになる可能性があります。 アプリケーションがクラッシュした場合は、ユーザーに適切に通知する必要があります。 JIT デバッガーまたは重大なエラー ダイアログは不十分です。 クラッシュの処理方法について話すことはこの記事の範囲を超えていますが、ユーザーに謝罪し、状況を知らせる (できれば、このクラッシュから回復する方法についての詳細情報へのリンクを含む) 簡単なダイアログがユーザーにとって非常に有用であるということを推奨しています。

さらに一歩進めたい場合は、お気に入りのグラフィックデザイン アプリケーションの 1 つを実行できます。 クラッシュした場合は、回復ダイアログが表示されます。これにより、作業中のファイルの別のコピーを保存し、クラッシュに関する情報 (個人情報は省略可能) を入力して作成者に送信できるフィードバック ダイアログが表示されます。

RadioButtons にするか ComboBoxes にするか

一見、1 対多の選択を行う方法は、それほど困難でも重要でもないように見えます。 時によってはそうなる可能性があります。特にシナリオが時間の影響を受けやすい作業に使用されるアプリケーションである場合です。

実際の例を見てみましょう。 Microsoft は最近、グラフィックス アプリケーションのプレビュー バージョンである Expression Graphics Designer (以前のコード名は "Acrylic") をリリースしました。 このアプリケーションで特定のプロパティを個別に割り当てる必要があった約 20 のグラフィックスオブジェクトが私にはありました。 それは悲惨なプロセスでした。 これを行うには、オブジェクトを選択し、設定ウィンドウを表示するためのボタンをクリックし、オプションを設定する必要がありました。 このようなオプションでは、次のスクリーンショットでわかるように、ComboBox から 2 つの選択肢を選択する必要がありました。

コンボボックス リストをドロップダウンして2番目の項目 (2つの項目のみ) を選択しなければならないような場合は、本当にいらいらさせられるでしょう。 私たちがあまり意識していないのは、ドロップダウンリストが表示されるまでの時間です。 それは多くの時間を浪費し、フラストレーションもたまるでしょう。 これは、特に使用可能な領域が非常に多い場合に、2 つの RadioButton を含む GroupBox に配置することで簡単に解決できます。 CorelDRAW、Microsoft Access などのアプリケーションでも同様の問題に遭遇しました。

ドロップダウン アニメーションのために時間を無駄にするだけでなく、"精神的な帯域幅" も無駄になります。2 つの "常に表示される" RadioButton では、カーソルがクリックする位置が無意識に認識されます。 ComboBox では、リストが描画された後にのみ処理されます。 それはどうでもいいことのように思われますが、実は非常に重要なことなのです。

特に 4 つ以下の選択肢がある場合は、RadioButtons を使用することをお勧めします。

ユーザーを混乱させない!

頭に拳銃を押し付けたくなるほど、これは開発者がユーザーに行うことができる最も破壊的なものです。 アプリケーションが、不必要であろうとなかろうと、メッセージ ボックスやタスク バーの点滅で、ユーザーが他のアプリケーションで作業している間に邪魔をした場合、ユーザーからマイナスポイントを獲得します。

タスク バーの点滅は便利ですが、アプリケーションのプロセスでユーザーからの入力を続行する必要がある場合や、ユーザーに伝えるために重要な情報がある場合にのみ呼び出す必要があります。 ユーザーがタスク バーを自動非表示にしている場合、タスク バー ボタンが点滅すると、ステータス バーや他の低い位置にあるコントロールの上にタスクバーが表示され、ユーザーが点滅するボタンをクリックするまで再び非表示にならないため、ユーザーがステータス バーや他の低い位置にあるコントロールにアクセスするのを妨げる可能性があります。

MSN Messenger などのインスタント メッセージング クライアントによって有名になった "トースト" ウィンドウ (図 10 を参照) は、迷惑な作業フローや作業フローを中断することなくユーザーに通知するための優れたソリューションです。 トースト ウィンドウの作成に関して Bill Wagner の優れた記事があります。 他のアプリケーションのトーストを妨げないのが良いポリシー (およびマナー) です。 このようなウィンドウズの妨害は迷惑で非生産的である可能性があります。 1 つの解決策は、オペレーティング システムによって提供される ToastSemaphore ミューテックスを使用して、トーストの競合を回避することです。

場合によっては、トーストで複数の項目を表示する必要があります。 3 つ以上のトーストをポップアップすることはまったく推奨されません。 代わりに、一方のトーストをポップ/フェードして、それぞれを循環する方が良いでしょう。 Microsoft Outlook では、受信したメールをユーザーに通知するときに同様のソリューションを実装しています。

進行状況の提供

多くの場合、ユーザーが待機する必要のあるタスクがあります。 もちろん、これはユーザーが単に嫌がることの 1 つです。 しかし、さらに悪いのは、何が起こっているのか分からずに待っているときです。 アプリケーションが Web サービスまたはリモート コンピューターに接続する必要がある場合や、大きなデータ チャンクを処理している場合があります。その理由が何であれ、ユーザーには内部で何が起こっているかを認識させるか、少なくともあいまいにでも認識を与える必要があります。 状況に基づいて、これを行うさまざまな方法があります。

Web サービスやネットワークまたはインターネット サーバーに配置されたオブジェクトなど、遠いオブジェクトに接続している場合は、単純な進行状況ダイアログ (次の図を参照) またはステータス バーでホストされている進行状況バーを表示することをお勧めします。 付随するラベルは、プロセスの現在の状態を記述する必要があります。 たとえば、Web サービスに接続してデータを処理する場合は、"Web サービスに接続中..." または "処理の間しばらくお待ちください..."このプロセスが同期的な場合は、プロセスが完了するまでユーザーがアクセスできるすべてのコントロールを無効にするか、モーダル ダイアログ ボックスとして進行状況を表示することをおすすめします。

進行状況バーを使用していて処理時間が不明な場合、または最大値がない場合は、進行状況バーのスタイルをマーキー モードに設定することを強くおすすめします。

人気が高まっているもう 1 つの方法は、進行状況を表示する固定の "トースト" ウィンドウです。 Microsoft AntiSpyware ダウンローダー/アップデーターまたは Norton AntiVirus のメール スキャン トーストが、この良い例です。 もちろん、これは非同期プロセスにのみ使用する必要があります。 そうしないと、ユーザーの不信感を買う可能性があります。 このようなウィンドウは、更新プログラムのダウンロードやスケジュールされたタスクの実行などのバックグラウンド処理に最適であり、"Always on top" に設定しないでください。

ウィザードを使用して複雑な手順を簡略化する

単一のフォームで多数のコントロールに直面した場合、一般的なユーザーは限りなく混乱すると仮定しても安全です。 多くの重要なコントロールがある場合、グループ化、サイズ変更、または間隔の量が役に立たない場合があります。

このようなシナリオでは、ウィザードが最適です。 該当するタスクまたはカテゴリごとにコントロールを分割し、別の手順で配置できます。 これは、ユーザーが集中し続け、タスクに圧倒されないようにするのに役立ちます。 [ヘルプ] ボタンを使用して、ステップ固有またはタスク固有のヘルプを提供できます。 詳細は、 Wizardsを参照してください。

ウィザードは、アプリケーションの初期構成を設定するのにも適した方法です。 多くのアプリケーションでは、このようなウィザードを使用して、セットアップが完了した直後または初回使用時に、個人用に設定された構成を設定します。 このような初期ウィザードは、可能であれば省略可能にする必要があります。ユーザーが任意の時点でキャンセルした場合、指定されていない設定は既定値になります。 ウィザードを少しグラフィカルにできる場合 (「プリティ グラフィックスの使用」セクションを参照)、構成タスクがはるかに簡単になります。

テキストのトーンを正しく取得する

Windows ユーザー エクスペリエンスの操作ガイドラインでは、"テキスト トーン" について非常に重要な点が明らかにされています。 これは、アプリケーション内のテキストによって与えられる印象と感情です。 これは、単純なツール ヒントから命令ラベル コントロールまで、あらゆることに適用されることです。

前に、MSN Messenger の [Web カメラ] オプションでのテキストの変更について説明しました。 これは、適切なテキスト トーンと呼ばれます。 技術に詳しくないユーザーや初心者のユーザーを扱う場合、メッセージを伝えることには別の側面があります。

自己解凍アプリケーションのテキスト ボックスの上に "解凍先パス" と記述すると、技術に詳しいユーザーは "C:\Temp\MyPath" のような入力を簡単に思いつくでしょう。初心者ユーザー ("お母さん "を思い浮かべてください) はすぐに困惑し、マニュアルを参照したり、技術サポートに電話したり、最悪の場合はあきらめてしまうことでしょう。 代わりに、"これらのファイルを配置するフォルダーを選択する" というユーザーの操作を指定することをお勧めします。さらにそのテキストボックスの横にある [参照する...] ボタンは、[フォルダーの選択...] と名前を変えてもいいでしょう。

ユーザーが実行する内容を明確に説明すると、ヘルプ ファイルの必要性が軽減されるか、少なくともヘルプ ファイルに含める必要がある詳細が少なくなります。

Windows ユーザー エクスペリエンスの操作ガイドラインからの最良の提案は、任意のソフトウェアに適用されます。 ライターは会話調の文章を心がけなければならないと記載されています。 ガイドラインでは、「他の人に言わない言葉を避ける」と定義されています。

テキストを書き込むためのいくつかのヒント:

• ユーザーを 3 人称で語るのは避けます。 "ユーザー" の代わりに "あなた" と言います。
• 可能な限り、"名前:" または "電子メール: " の代わりに "My name:" または "My E-Mail address:" を慎重に使用します。
• 複数のオプションを指定する場合は、ユーザーの観点からテキストを書き込みます。 たとえば、2 つの RadioButtons の上に "このネットワーク上の [ユーザー名] のアクセス許可を選択する" などのラベルの下に 2 つの RadioButton がある場合は、RadioButton テキストを "[ユーザー名] を許可する" と "[ユーザー名] を禁止する" に置き換えます。
• テキストがリンクに使用されている場合にのみ下線を引きます。 下線付きのテキストがリンクでない場合は、ユーザーを混乱させます。
• 太字のラベルで重要な情報に注意を引きますが、慎重に使用してください。 太字のテキストが多すぎると混乱が生じ、フォームの全体的な影響が薄くなってしまいます。
• チェック ボックスのテキストを書くときには、選択した場合、選択しない場合、またはクリアした場合に何が起こるかを簡単に把握できるようにします。 推奨されるオプションは、チェックボックスが選択した結果を示すテキストを直接書き込むことです。 たとえば、「パートナーから役に立つ情報を送信しない」ではなく、「パートナーから役に立つ情報を送信する」と書きます。多くのマーケティング関係者がこの特殊な例について議論しているのは想像に難くありませんが、言いたいことはお分かりいただけるでしょう。
• ボタンに似たコントロール (通常は、コマンド ボタンの外観を持つ RadioButton) が有効または無効になっている場合は、正しくラベル付けしてください。 プロセスが有効になっている場合は、"有効にする" または "無効にする" ではなく "有効" と書きます。 「有効」と書くと、現在の状態が表示されます。 ボタンがクリックされ (有効)、ボタンに "有効にする" と表示されている場合は、混乱を招き、問題が発生する可能性があります。 "有効にする" と書くと、プロセスがアクティブでないとユーザーが思い込んでクリックしてしまうかもしれません。

時によっては ListView を使うほうがよい

多くの場合、選択タスクには DataGrid や ListBox、または ComboBox にこだわりがちですが、Windows XP 以降のバージョンの Windows では、ListView を使用すると、より大きなオプションを提供できます。

ListView コントロールの細かい点:

• アイコンとビットマップを使用して項目の認識を高速化します。
• 詳細ビューまたはタイル ビューで追加情報を表示します。
• Visual Studio 2005 では、追加の分類のためにグループを作成することもできます。 グループはすべてのビューにまたがり、柔軟性があります。 グループを使用して、親ノードよりも子ノードの数が多い階層ビュー (TreeView など) をフラット化することもできます。 その良い例は、Windows XP の [ネットワーク接続] ダイアログで、[グループに表示] を表示し、ビューを [詳細] に設定した場合です。
• ListView コントロールをカスタマイズするには、OwnerDraw プロパティを設定し、DrawItem イベントと DrawSubItem イベントを使用して手動で描画します。
• ListView アイテムの簡単なインプレース編集をサポートします。
• 手動での並べ替えを簡単にサポートします。
• ユーザーが最も使い慣れたビュー (大きいアイコン、小さいアイコン、リストなど) を選択できるようにします。

階層リンク コントロールとサイドバーを使用してナビゲーションを簡略化する

"サブナビゲーション" は、複雑な UI のキーとなります。 複雑な UI を持たせることから逃れられない場合があります。 このような状況で行う最善の方法は、ユーザーのエクスペリエンスを可能な限り簡単にすることです。 リンク ラベルで構成されるサイド バー、または階層ベースのナビゲーション用の TreeView は、現在のダイアログのタスクの兄弟レベルのナビゲーションを提案します。 これにより、ユーザーは自分がどこにいるかを知りながら、プロセスの手順間を簡単に移動できます。

TreeViews やその他の同様に複雑なナビゲーションを使用して階層ベースのナビゲーションを実行する場合、ユーザーにとって適切なユーティリティは階層リンク コントロールになります。 Visual Studio には、この組み込みコントロールはまだ搭載されていませんが、自分で作成する方法については、「階層リンク コントロールの作成」を参照してください。 階層リンク コントロールを使用すると、階層に関連する現在の場所を簡単に見つけることができます。

階層リンク ナビゲーションは、フォームにヘッダーがある場合に簡単にヘッダーにマージできます。 ヘッダーの前のセクションを参照してください。

プリティ グラフィックスを使用する

誰もが、少なくとも大多数の人は、クールなグラフィックのアプリケーションを好みます。 美しいグラフィックスを備えた UI が必ずしもすべてのアプリケーションにとって論理的な選択ではありませんが、素晴らしい印象を与えるのに役立ち、作業に楽しいものにすることもできます。 もちろん、グラフィックスは生産性を妨げるべきではありませんが、正しく使用すれば、生産性を上げることができます!

多くのグラフィックが必要なわけではないし、必ずしも多くの作業を必要とするわけでもありません。 プロが設計したスプラッシュ スクリーンやヘッダー (前述のように) がそのトリックになります。 予算が許す場合は、ツール バーやウィザードなどの適切に設計されたグラフィックスを使用できます。 アプリを美しく見せ、よりプロフェッショナルな外観にします。 それは微妙な効果ですが、プロフェッショナルな外観は信頼と安定性を伝えます。 小売アプリケーションを作成する比較的小規模な会社の場合、これは考慮すべき重要な側面です。

常にプロがデザインしたグラフィックを使用することを心がけます。 ロイヤリティフリーのグラフィックは簡単に入手でき、手頃な価格です。 デザイナーも雇ってもいいでしょう。 しかし、もしグラフィックが得意でないのなら、自分で試してみようとはしないことです。 専門的に設計されたグラフィックスを取得または使用できない場合は、まったく使用しないことをお勧めします。

小さなグラフィックスの場合は、Visual Studio 2005 に搭載されているアイコンとビットマップをいつでも探すことができます。 (以前のバージョンに搭載されていたグラフィックスは推奨されません。)

可能な場合はサイズ変更可能なフォームを提供する

サイズ変更可能なウィンドウは、解像度に依存しないウィンドウに似ています。 解像度に依存しないウィンドウは、96DPI 画面と 300DPI 画面のどちらを使用する場合でも同じように表示されます。 アプリケーションの UI が解像度に依存しないものであろうとなかろうと、サイズ変更可能なものであれば、よりうまくいくでしょう。 もちろん、これは多くのシナリオには当てはまるわけではありませんが、良い汎用ルールです。

ウィンドウが何らかの種類のリスト (特に ListViews) を扱う場合、これはさらに重要になります。 サイズを変更すると、ユーザーはより多くのデータを同時に確認できます。

たとえば、ユーザーが大きなコレクションから画像を選択する必要があるアプリケーションがあるとします。 開いているダイアログではサムネイルビューを選択できますが、ダイアログは固定サイズであり、サムネイルリストには一度に4つのサムネイルのみが表示されます。 コレクションに 100 の画像がある場合、スクロールと見た目 (繰り返しの作業) は非常に面倒で効率が低下する可能性があります。 ダイアログのサイズが変更可能な場合、ユーザーは、快適な大きさにしたり、少なくとも画面で許可される大きさにしたりして、タスクをすばやく完了できます。 リストに水平スクロール (詳細な ListView や DataGrid など) がある場合は、さらに面倒です。 サイズ変更可能なウィンドウは、このような状況で非常に役立ちます。

サイドバー/タスク ウィンドウを使用して他の機能を提供する

前に説明したヘッダーと同様に、サイド バーとタスク ウィンドウは、追加の機能とユーティリティ コマンドを提供する優れた方法です。 たとえば、Office Word 2003 のタスク ウィンドウは非常に便利で、アクセスしやすく、邪魔にはなりません。 また、オンライン リソースに接続するときに非同期的に機能し、ユーザーにマルチタスクのオプションを提供します。

タスク ウィンドウまたはサイドバーの作成は、ドッキング パネルを作成するのと同じくらい簡単で、タイトル バーとして機能する滑らかなグラフィックを上部に配置することもできます。 それには、色付きのラベル コントロールを使用することもできます。 タスク ウィンドウには多くの機会があります。

追加の機能があり、それをユーザーに非侵入的に提供する場合は、タスク ウィンドウほど便利なものはありません。 タスク ウィンドウを "自動的に隠す" にしたり、Visual Studio ツール ウィンドウのように折りたたんだりすることもできます。

通知の選択を行う

以前は、カスタム メッセージ ボックスを作成する方法について説明しました。 アプリケーションのメッセージ ボックスがユーザーに頻繁に表示されるようであれば、ユーザーが選択できるチェック ボックスを追加して、今後そのダイアログが表示されないようにするのが賢明です。 このようなオプションは、より明確なメッセージに特に適しています。

この使い慣れた例として、Visual Studio の [検索] ダイアログがあります。 テキストを検索または置換すると、結果を示すメッセージ ボックスが Visual Studio に表示されます。 ただし、そのメッセージ ボックスを無効にするオプションも提供されます。 Enter キーを押すか、検索するたびに [OK] をクリックしなければならないのは、本当に迷惑です。

Visual Studio のもう 1 つの便利な点は、ダイアログが無効になっている場合でも、その操作の結果がステータス バーに表示されるということです。

ツール ヒントを提供しよう。

ツールヒントを使用すると、時間を大幅に節約できる場合があります。 ボタン、チェック ボックス、およびその他のコントロールはあいまいな場合があり、ユーザーが何をすべきかが不明な場合があります。 ツール ヒントは、状況依存のヘルプの最適な形式を 1 行で提供します。 ユーザーは、ヘルプ ファイルで何かを検索したり、別のウィンドウを開いたりすることなく、何を行うかをすばやく決定できます。

多くの場合、アプリケーションではこれをスキップします。 すべてのあいまいなコントロール、可能ならすべてのコントロールにツール ヒントを追加するようにしましょう。 付属のラベルまたはコントロール独自のテキストのテキストを繰り返すのではなく、そのコントロールに関する追加情報を提供します。 テキストでは、コントロールの機能をほんの数語で説明する必要があります。

些細な事を忘れない

些細なことで悩まされることもあるが、それを無視することは作られる印象に影響を与えます。 私は以前、ソフトウェア業界の重要な人物が作成したアプリケーションを使用していましたが、フォームの BorderStyle が Sizeable に設定されていたのに、フォームの右側のコントロールは固定されていませんでした。 そのため、業界の重鎮が作成したアプリケーションは、プロフェッショナルではない雰囲気を醸し出していました。

このような「些細なこと」が全体的な印象の中核です。 アプリケーションの UI と UX は、少なくとも最初に、ユーザーがアプリケーションの判断をする対象となるものです。 UI に明らかなバグが見られる場合は、アプリケーションの強力で効果的ではないと認識される可能性があります。

まとめ

私たちは、ごく一部の、人間ユーザー エクスペリエンスにのみ触れました。 ユーザー エクスペリエンスがよりシンプルになり、効果的で、楽しく、使いやすいものになるにつれて、そのユーザー エクスペリエンスを作成するタスクは非常に複雑になります。 しかし、いくらかの先見性と適切な計画を立てれば、優れたユーザー エクスペリエンスを作成できます。

最適なユーザー エクスペリエンスを作成する最善の方法は、特別なテスト グループを使用するか、自分で行うかに関係なく、特に UI を対象とした使いやすさのテストを行うことです。 アプリケーションをリリースする前にユーザー エクスペリエンスのテストに費やす時間が長いほど、より良いものになります。 そうすることで後々のトラブルを避けることができるでしょう。