ユーザビリティデザイン
アプリケーションの使いやすさは基本的にユーザーによって決まります。インターフェイスの設計は反復的なプロセスです。アプリケーションのインターフェイスを設計する場合、最初のステップから完璧なインターフェイスを実現することはほとんどありません。ユーザーが設計プロセスに早くから参加するほど、より優れた、より使いやすいインターフェイスを作成するのにかかる労力が少なくなります。
良いインターフェースとは何か
ユーザー インターフェイスを設計するときは、Microsoft または他の企業のベストセラー アプリケーションをいくつか検討することから始めることをお勧めします。結局のところ、インターフェイスが貧弱なアプリは売れません。ツールバー、ステータス バー、ツールヒント、コンテキスト メニュー、マークアップ ダイアログなど、多くの一般的なものが見つかります。 Visual Basic にこれらすべてをアプリケーションに追加できる機能があるのは偶然ではありません。
ソフトウェアを使用した自分自身の経験に頼ることもできます。これまでに使用したアプリケーションについて考え、何がうまくいき、何がうまくいかなかったのか、そしてそれをどのように修正できるのかを考えてみましょう。ただし、個人の好みはユーザーの好みと同じではないため、自分の意見とユーザーの意見を一致させる必要があることに注意してください。
また、成功しているアプリケーションのほとんどは、さまざまなユーザーの好みに対応するオプションを提供していることにも注意してください。たとえば、Microsoft Windows Explorer を使用すると、ユーザーはメニュー、キーボード コマンド、またはドラッグ アンド ドロップを通じてファイルをコピーできます。オプションを提供するとアプリケーションの魅力が広がり、少なくともマウスとキーボードですべての機能にアクセスできるようにする必要があります。
Windows インターフェイスのガイドライン
Windows オペレーティング システムの主な利点は、すべてのアプリケーションに共通のインターフェイスが提供されることです。 Windows ベースのアプリケーションの使用方法を知っているユーザーは、他のアプリケーションの使用方法を簡単に学ぶことができます。確立されたインターフェイス ガイドラインから大きく逸脱したアプリケーションは、理解するのが困難です。
メニューはその好例です。ほとんどの Windows ベースのアプリケーションはこの標準に従っています。つまり、左端の「ファイル」メニュー、次に「編集」、「ツール」およびその他のオプションのメニュー、そして右端の「ファイル」メニューです。 .ヘルプ」メニュー。 「ファイル」より「ドキュメント」の方が良い場合、または「ヘルプ」メニューを最初に配置する必要がある場合は、議論する価値があります。これを妨げるものはありませんが、これを行うとユーザーが混乱し、アプリケーションの使いやすさが低下する可能性があります。ユーザーは、アプリや他のプログラムを切り替えるたびに、立ち止まって考える必要があります。
サブメニューの位置も重要です。ユーザーは、「コピー」、「切り取り」、「貼り付け」などのサブメニューが「編集」メニューの下にあることを期待していますが、それらを「ファイル」メニューの下に移動すると、ユーザーは混乱するでしょう。正当な理由がない限り、作成されたガイドラインから大きく逸脱しないでください。
ユーザビリティテスト
インターフェイスの使いやすさをテストする最良の方法は、設計プロセス全体にユーザーを参加させることです。大規模な圧縮アプリケーションを設計する場合でも、小規模で用途が限定されたアプリケーションを設計する場合でも、設計プロセスはまったく同じである必要があります。作成された設計ガイドラインを使用して、インターフェイスの設計を紙の上で開始する必要があります。
次のステップでは、1 つ以上のプロトタイプを作成し、Visual Basic でフォームをデザインします。プロトタイプを開始するには、フォームを表示したり、リスト ボックスにサンプル データを入力したりするなど、十分なコードを追加する必要があります。次に、ユーザビリティテストの準備をします。
ユーザビリティ テストは、ユーザーと一緒にデザインをレビューする非公式のプロセスである場合もあれば、作成されたユーザビリティ ラボでの正式なプロセスである場合もあります。どちらの方法の目的も同じです。何がうまく機能し、何が改善の必要があるのかをユーザーから直接学ぶことです。ユーザーを手放し、アプリケーションに参加させて観察するこのアプローチは、ユーザーに尋ねるよりも効果的です。ユーザーに、一連のタスクを完了しようとするときの思考プロセスを表現するように依頼します。「新しいドキュメントを開きたいので、[ファイル] メニューで探します。インターフェイスのデザインがユーザーの思考プロセスを反映していないことに注意してください。」さまざまなタイプのユーザーでテストします。ユーザーが特定のタスクを完了するのが難しいことが判明した場合は、そのタスクにさらに注意を払う必要がある可能性があります。
次に、レコードを確認し、インターフェイスをより使いやすくするために変更する方法を検討します。インターフェースを変更して再度テストしてください。アプリケーションの使いやすさに満足したら、コーディングを開始する準備が整います。プロトタイプに関する仮定が正しいことを確認するために、開発プロセス中に時々テストも必要になります。
機能の発見可能性
ユーザビリティテストにおける重要な概念は発見可能性です。ユーザーが機能の使用方法を理解できない場合 (またはその機能の存在さえ知らない場合)、その機能は使用される可能性は低いです。たとえば、Windows 3.1 のほとんどのユーザーは、ALT キーと TAB キーの組み合わせを使用して、開いているアプリケーションを切り替えることができることを知りませんでした。ユーザーがこの機能を発見するのに役立つ手がかりはインターフェイスのどこにもありません。
機能の検出可能性をテストするには、タスクの実行方法を説明せずにタスクを完了するようにユーザーに依頼します (たとえば、「フォーム テンプレート」を使用して新しいドキュメントを作成するなど)。タスクを完了できない場合、または複数回の試行が必要な場合は、この機能の見つけやすさを改善する必要があります。
ユーザーまたはシステムに問題が発生した場合にユーザーと対話する
理想的な世界では、ソフトウェアとハードウェアは常に不具合なく動作し、ユーザーは決して間違いを犯さないでしょう。実際には、間違いは避けられません。問題が発生したときにアプリケーションがどのように応答するかを決定することは、ユーザー インターフェイスの設計の一部です。
一般的な対応策は、アプリケーションが問題をどのように処理するかについてユーザーに入力を求めるダイアログ ボックスを表示することです。あまり一般的ではありませんが、より良い対応策は、ユーザーの邪魔をせずに問題を解決することです。結局のところ、ユーザーが主に関心があるのは、技術的な詳細ではなく、タスクを完了することです。ユーザー インターフェイスを設計するときは、考えられるエラーを考慮し、どのエラーがユーザーの操作を必要とするか、どのエラーが事前に用意された解決策で解決できるかを判断します。
わかりやすいダイアログボックスを作成する
場合によっては、アプリケーションでエラーが発生し、状況を解決するために判断が必要になることがあります。これは通常、コードの分岐 (If...Then ステートメントまたは Case ステートメント) として発生します。この判断にユーザーの対話が必要な場合、通常、この問題はダイアログ ボックスを使用してユーザーに表示されます。ダイアログ ボックスはユーザー インターフェイスの一部であり、インターフェイスの他の部分と同様に、そのデザインはアプリケーションの使いやすさに影響します。
プログラムのダイアログ ボックスの設計者の多くは、人々が理解しやすい言葉を話さないように感じることがあります。たとえば、次のようなメッセージ: 「ハードディスク C のセクタが破損しているか、アクセスできません。中止、再試行、無視しますか?」 (図 6.22 を参照) これは、一般のユーザーにとっては理解しにくいものです。これは、ウェイターが顧客に「スープがない、またはキッチンで火が点いている、中止する、もう一度試してください、無視しますか?」と尋ねることに相当します。ユーザーが理解できる方法やフレーズで問題 (および選択) を説明することが重要です。前の例では、「ドライブ C にファイルを保存するときに問題が発生しました。ファイルをドライブ A に保存してください。ファイルを保存しますか?」というメッセージの方が適切です。
アプリケーションのダイアログ ボックスを作成するときは、ユーザーのことを念頭に置いてください。このメッセージはユーザーに有益な情報を伝えていますか?分かりやすいでしょうか？コマンド ボタンで表される選択肢は明確ですか?この選択は与えられた条件に適していますか?迷惑なメッセージ ボックスが 1 つあるだけで、アプリケーションに対してユーザーに悪い印象を与える可能性があることに注意してください。
カスタム ダイアログ ボックスを設計している場合は、標準タイプに固執するようにしてください。標準のメッセージ ボックスのレイアウトから大きく逸脱すると、ユーザーがそれをダイアログ ボックスとして認識しない可能性があります。
ダイアログ ボックスの詳細については、この章の前半の「ダイアログ ボックス」を参照してください。
ダイアログボックスを使用しないエラー処理
エラーが発生したときにユーザーを中断する必要はありません。場合によっては、ユーザーに通知せずにコード内のエラーを処理したり、ユーザーのワークフローを停止しない方法でユーザーに警告したりすることが望ましい場合があります。このテクノロジの好例は、Microsoft Word の「オートコレクト」機能です。一般的な単語のスペルが間違っている場合、Word はその単語を自動的に修正し、後で修正するようユーザーに通知するために単語の下に赤い線を描画します。 。
利用可能な手法は数多くありますが、どの手法が自分のアプリケーションに適しているかを判断するのはあなた次第です。以下にいくつかの提案を示します。
1. 「編集」メニューに「元に戻す」機能を追加します。削除のような状況では、「OK」ダイアログでユーザーを中断するのではなく、ユーザーが正しい決定を行ったことを確認し、後で気が変わった場合に備えて「元に戻す」機能を提供できます。
2. ステータスバーまたはアイコンにメッセージを表示します。エラーがユーザーの現在のタスクに影響を与えない場合は、アプリケーションを停止しないでください。ステータス バーまたは明るい警告アイコンを使用して、準備ができたら問題に対処できることをユーザーに警告します。
3. 問題を修正します。間違った解決策が明らかな場合もあります。たとえば、ユーザーがファイルを保存しようとしたときにディスクがいっぱいの場合、システムは他のドライブの空き容量をチェックします。空き領域がある場合は、ファイルが保存され、何が行われたかをユーザーに知らせるメッセージがステータス バーに表示されます。
4. メッセージを保存し、処理を待ちます。すべてのエラーが重大なわけではなく、すぐに対処する必要があるわけではないため、これらのエラーをファイルに記録し、アプリケーションの終了時または別の都合のよいときにユーザーに表示することを検討してください。ユーザーが入力エラーをした場合 (たとえば、MianSt. の代わりに MainSt. と書くなど)、それを記録します。 「ReviewEntries」ボタンと、ユーザーが修正できるように相違点を表示する機能を追加します。
5. 何もしないでください。場合によっては、エラーが警告を必要とするほど重要ではない場合があります。たとえば、LPT1 のプリンタで用紙の準備ができていないという事実は、印刷の準備ができるまではあまり重要ではありません。メッセージが現在のタスクに関連するまで待ちます。
エラー処理手法の詳細は、第 13 章「コードのデバッグとエラー処理」を参照してください。
ユーザー支援パターンの設計
ユーザー インターフェイスがどれほど優れたデザインであっても、ユーザーがサポートを必要とする場合があります。アプリケーションのユーザー支援モードには、オンライン ヘルプや印刷されたドキュメントなどが含まれます。また、ツールヒント、ステータス バー、「What's this」ヘルプ、ウィザードなどのユーザー支援デバイスも含まれる場合があります。
アプリケーションの他の部分と同様に、ユーザー支援パターン設計は開発に先立って行う必要があります。スキーマの内容は、アプリケーションの複雑さと対象読者によって異なります。
ヘルプとドキュメント
オンライン ヘルプはあらゆるアプリケーションの重要な部分であり、多くの場合、ユーザーが質問があるときに最初に参照します。単純なアプリケーションであっても、「ヘルプ」を提供する必要があります。それを提供しないのは、ユーザーには問題がないと仮定しているようなものです。
ヘルプ システムを設計するときは、その主な目的が質問に答えることであることを忘れないでください。トピック名やインデックス エントリを作成するときは、ユーザー用語を使用するようにしてください。たとえば、「ページをフォーマットするにはどうすればよいですか?」など、トピックは「編集」メニューや「ページ フォーマット」メニューよりも見つけやすいです。コンテキストを忘れないでください。特定のフィールドのヘルプを求めて F1 キーを押しても、コンテンツのトピックだけが表示されると、ほとんどのユーザーはイライラするでしょう。
基本概念の文書化は、印刷または zip ディスクで提供されるかどうかに関係なく、最も単純なアプリケーションを除くすべてのアプリケーションに役立ちます。短いヘルプ トピックでは伝えるのが難しい情報を提供できます。少なくとも、ユーザーが必要に応じて印刷できる ReadMe ファイル形式のドキュメントが必要です。
ユーザー補助装置
ユーザー インターフェイスには、ユーザーを支援するいくつかのテクノロジがあります。 Visual Basic を使用すると、ツール ヒント、「これは何ですか」ヘルプ、ステータス表示、ウィザードをアプリケーションに簡単に追加できます。これらのデバイスのどれが自分のアプリケーションに適しているかを決定するのはあなた次第です。
ツールチップ
ツールチップ (図 6.23) は、ユーザーがユーザー インターフェイスで検索するときに情報を表示する優れた方法です。ツールチップは、マウス ポインタがコントロール上にあるときに表示される小さなラベルで、通常はコントロールの機能の説明が含まれます。通常、ツールチップはツールバーと組み合わせて使用され、インターフェイスのほとんどの部分で適切に機能します。
ほとんどの Visual Basic コントロールには、ツール ヒントの表示に使用されるプロパティ ToolTipText が含まれています。次のコードは、「cmdPRint」という名前のコマンド ボタンのツールチップを提供します。
cmdPrint.ToolTipText=現在のドキュメントを印刷します
インターフェイスの他の部分と同様に、このテキストでもメッセージがユーザーに明確に伝わるようにしてください。
ツールチップの詳細については、『言語リファレンス』の「ToolTipText プロパティ」を参照してください。
「これは何ですか？」のヘルプ
ユーザーが [What's Help] を選択し、コントロール上の [What's Cursor] をクリックすると、What's Help によってポップアップ ヘルプ トピックへのリンクが提供されます (図 6.24 を参照)。 「What's This」ヘルプは、ツールバー ボタン、メニュー項目、またはダイアログ ボックスのタイトル バーのボタンから起動できます。
メニューまたはツールバーから「What's This」ヘルプを有効にするには、次の手順に従います。
1. 支援したいコントロールを選択します。
2. 「プロパティ」ウィンドウで、「WhatsThisHelpID」プロパティを選択します。
3. 関連するポップアップ ヘルプ トピックのコンテキスト識別子を入力します。
4. 他のコントロールについても手順 1 ～ 3 を繰り返します。
5. フォームを選択します。
6. [プロパティ] ウィンドウで、フォームの WhatsThisHelp プロパティを True に設定します。
7. メニューまたはツールバー ボタンの Click イベントに、次のコードを入力します。
フォーム名.WhatsThisHelp
ユーザーがボタンまたはメニューをクリックすると、マウス ポインタが「これは何ですか」というヘルプ ポインタに変わります。カスタム ダイアログ フォームのタイトル バーで「What's This」ヘルプを有効にするには、フォームの WhatsThisButton プロパティと WhatsThisHelp プロパティを True に設定します。
「WhatsThis」ヘルプの詳細については、『言語リファレンス』の「WhatsThisHelp プロパティ」および「WhatsThisButton プロパティ」を参照してください。
ステータス表示
ステータス表示は、ツール ヒントとほぼ同じ方法でユーザー支援を提供するために使用することもできます。ステータス表示は、ツールチップには適さない指示やメッセージを提供する優れた方法です。 Visual Basic の Professional および Enterprise エディションに含まれるステータス バー コントロールは、メッセージを適切に表示できます。Label コントロールはステータス表示としても使用できます。
ステータス表示に表示されるテキストは、コントロールまたはフォームの GotFocus イベントを使用する方法、または MouseMove イベントを使用する方法のいずれかで更新できます。ディスプレイを学習デバイスとして使用する場合は、[ヘルプ] メニューに項目を追加して、その Visible プロパティのオンとオフを切り替えます。
ステータス表示を追加するには、次の手順に従います。
1. フォームに Label コントロールを追加します。
2. メッセージを表示するコントロールを選択します。
3. コントロールの MouseMove (または GotFocus) イベントに次のコードを追加します。 Labelname.Caption=このフィールドに顧客の ID 番号を入力してください マウスがコントロール上に移動すると、このメッセージがこの Label コントロールに表示されます。
4. 他のコントロールについても手順 2 ～ 3 を繰り返します。
ウィザード
ウィザードは、実際のデータを使用してプロセスの実装を段階的にガイドするユーザー支援デバイスです。ウィザードは、タスク固有の支援を提供するためによく使用されます。これらは、時間のかかる (そして面倒な) 学習プロセスを必要とするタスクを支援し、まだ専門知識のないユーザーに専門的な情報を提供します。
Visual Basic の Professional および Enterprise エディションには、ウィザードを作成するためのツールであるウィザード マネージャーが含まれています。
ウィザードの詳細については、第 4 章「プロジェクト管理」の「ウィザードとアドインの使用」を参照してください。
->