トレーニング
ラーニング パス
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
注意
この設計ガイドは Windows 7 用に作成されており、新しいバージョンの Windows では更新されていません。 ガイダンスの多くは原則として適用されますが、プレゼンテーションと例には 現在の設計ガイダンスは反映されていません。
その素晴らしい、気まぐれな名前にもかかわらず、ウィザードは実際にはユーザー インターフェイスの特別な形式ではなく、ユーティリティの特定の範囲のみを持っています。
ウィザードは、複数ステップのタスクを実行するために使用されます。
ウィザードの複数の手順は、一連のページとして表示されます。
ウィザードには通常、次の種類のページが含まれます。
最新のウィザード設計では、効率に優れ、短い操作では [進行状況] ページが省略可能になり、多くの場合、最初と最後に従来の [ようこそ] ページ と [おめでとう] ページ が表示されます。
すべてのウィザード ページには、次のコンポーネントがあります。
ウィザードには複数の手順がありますが、これらの手順はすべて、ユーザーの観点から 1 つのタスクに追加する必要があります。 これは、"1 つのウィザード、1 つのタスク" の基本的なウィザード設計原則です。
したがって、この記事では、タスクはウィザードの基本的な機能です (たとえば、セットアップ ウィザードのタスクはプログラムをインストールすることです)。 サブタスクは、大規模なタスクの側面です (たとえば、セットアップ ウィザードのサブタスクは、インストールするプログラムを構成する場合があります)。 最後に、各ウィザード ページは、特定のサブタスクまたはタスクのステップと見なされます (たとえば、プログラムの構成に 2 つまたは 3 つの手順が関係している場合があります)。
メモ:セットアップ、ダイアログ ボックス、進行状況バーに関連するガイドラインは、別の記事で示されています。
ウィザードは、複数の入力ステップを必要とする任意のタスクに使用できます。 ただし、有効なウィザードには追加の要件があります。
ウィザードは 1 つのアトミック タスクを実行しますか? 1 つのタスクではない操作は使用しないでください (1 つのタスクを実行しない限り、プログラム全体をウィザードにしないでください)。 ウィザードを使用して、独立したタスクや主に関連のない手順を組み合わせないでください。
必要な質問の数を減らすことができますか? ほとんどの場合に適切に機能するか、後で必要に応じて調整できる、許容される既定値はありますか? その結果、ページ数を減らすことができますか? その場合は、1 つのページ (ダイアログ ボックスなど) に表示できるようにタスクを簡略化するか、(タスクを直接実行できるように) 完全に入力する必要がなくなります。
必要な質問を順番に提供する必要がありますか? いくつかの可能性がありますが、オプションの質問はありますか? その場合は、ダイアログ ボックスまたはタブ付きダイアログ ボックスを検討してください。
正確:
[Microsoft PowerPoint 印刷オプション] ダイアログ ボックスには多くのユーザー入力オプションが含まれているため、ウィザードで表示できます。 ただし、それらを順番に指定する必要がないため、ダイアログ ボックスを選択することをお勧めします。
ウィザードは、比較的重い形式のユーザー インターフェイスです。適切な軽量ソリューションがある場合は、それを使用してください!
これまで、ウィザードは通常の UI とは異なり、ユーザーが特に複雑なタスク (異なる場所に存在するステップを含む) を実行できるように設計されており、多くの場合、ユーザーの成功に役立つインテリジェンスが組み込まれています。 現在、すべての UI は、タスクを可能な限りシンプルにするように設計されている必要があるため、この目的のために特別な UI は必要ありません。
しかし、ウィザードは特別な UI であると信じられているのは、主に "ウィザード" と呼ばれるためです (たとえば、"ダイアログ" や "プロパティ ウィンドウ" よりもはるかに創造的です)。 代わりに、複数ステップのタスクと見なし、その事実に特別な注意を向けないようにすることをお勧めします。
ウィザードを作成する前に、プログラムのメイン フローからユーザーを本当に中断する必要があるかどうかを検討してください。 より軽量でインラインのコンテキスト ソリューションが存在する可能性があり、最終的にはユーザーに役立ち、効率的に感じられます。 たとえば、プログラムの不適切に設計された機能では、ウィザードで説明して簡略化する必要はありません。これは、機能自体の再設計を保証します。 プログラムに関するより基本的な問題を解決するために、ウィザードをバンドエイドとして使用しないでください。
ウィザードは、ユーザー エクスペリエンスを簡素化するためのキーの 1 つです。 プログラムの構成などの複雑な操作を実行し、一連の簡単な手順に分割することができます。 プロセスの各時点で、必要な内容の説明を入力し、ユーザーが選択を行い、テキストを入力できるようにするコントロールを表示できます。
特定の種類のマルチステップ タスクは、ウィザード フォームに役立ちます。 たとえば、Windows では、複数のウィザードに接続機能 (インターネットまたは企業ネットワーク、またはプリンターや FAX マシンなどの周辺機器) が含まれます。
ネットワークへの接続は、ウィザードに適した Windows の一般的なタスクです。
ここでは、ウィザードの機能は、既知の安定したもの (すぐに使用できるオペレーティング システム) と不明で可変なもの (電話会社またはインターネット サービス プロバイダーとの接続の取り決め) を仲介することです。 コンピューティング エコシステムの複雑さは、ウィザードを使用してその複雑さを軽減するのに本当に役立つようになったので、十分に重要です。
Windows ウィザードと同様に機能するその他の種類のタスクには、ハイエンド機能 (音声や手書き認識など) やリッチ メディア エクスペリエンス (ムービーの作成と公開のオプションの構成など) があります。 ウィザードは、トラブルシューティングなど、より基本的なマルチステップ タスク用に展開することもできます。 つまり、さまざまなユーザーが広く異なる方法でプログラムを体験する必要がある場合は、ウィザードの必要性と、複数のユーザー入力ポイントの容量を示すことができます。
プログラムでは、ウィザードが提供している関数と、その関数が実際にウィザードを展開するレベルに上がっているかどうかを判断するには、少し前もって設計する価値があります。
デザインの質問は、ページとオプションの数とorganizationに関して自然に発生します。 次に例を示します。
Microsoft は、3 ページ以下のウィザードを単純なウィザードとして設計し、4 ページ以上のウィザードでは高度なウィザード設計を使用することを推奨しました (1999 年の Windows ユーザー エクスペリエンス ガイドラインを参照)。 しかし、現在のウィザードの設計標準では、単純なフォームと高度なフォーム (Welcome ページと Congratulations ページの使用) の主な違いの 1 つであったものが含まれているため、これらのカテゴリは不十分に感じられ、デザインの選択を決定するページ数は任意のように見えます。
ウィザードは、タスクに必要な長さまたは短い値にする必要があります。長さの固定ガイドラインはありません。 1 ページのウィザードは実際にはダイアログ ボックスとして表示される必要があるため、2 つのページがウィザードで可能な限り最も狭い形式である可能性があります。
正確:
このタスクには非常に少ないオプションがあるため、ウィザードとして表示すると無駄になります。 ダイアログ ボックスは、このユーザー インターフェイスに適したフォームです。
スペクトルのもう一方の端で、複数の決定ポイントと分岐を含むウィザードがあり、ユーザーがナビゲーション パスの追跡を失う可能性が高い場合は、実際の制限を超え、ウィザードの長さを短くする必要があります。 または、ウィザードを複数の異なるタスクに分割することもできます。
ウィザードの最も適切な長さを決定するときは、ターゲット ユーザーに特に注意してください。 家庭の消費者やオフィス ワーカーなどのエンド ユーザー向けのプログラムでは、ウィザードを使用して複雑さを隠す傾向があります。ウィザードはできるだけ短く、クリーン、シンプルなページ デザイン、および可能な限り多くのオプションに対して事前に選択された既定値を使用します。 対照的に、IT プロフェッショナル向けのサーバー ウィザードまたはプログラムは、より長く複雑になる傾向があります。 ターゲット ユーザーのこのグループは、構成の決定に対する許容度がはるかに高く、複雑さが隠されすぎると、実際には疑わしくなる可能性があります。
ウィザードが本質的に複雑なタスクを簡略化する場合は、技術的に洗練された対象ユーザーに対しては比較的最小限に、初心者のユーザーベースでは比較的積極的に行う必要があります。
正確:
このウィザード ページはエンド ユーザー向けに適切に設計されています。これは、複雑になる可能性があるサブジェクトを、単純な論理バイナリの選択 (インストールまたはアンインストール) に減らすためです。
正確:
Microsoft SQL Server 2008 のセットアップ ウィザードでは、ページデザインは複雑であり、多くの選択肢でさらに検討が必要になりますが、対象ユーザーは、機能の選択を厳密に制御するデータベース管理者です。
最後に、特定のタスクを実行する頻度に注意してください。 頻度の低いタスクでは、より長いウィザードが展開される場合があります。一方、頻繁なタスクは簡潔さを優先する必要があります。
より長いウィザードでは、"アップストリーム" に指定されたユーザー入力に応じて、一連のページが異なる可能性があるタスク フローのブランチを作成する必要がある場合があります。分岐は本質的にユーザーに対して割り当て解除されるため、安定性を伝えるためにユーザー エクスペリエンスを設計する必要があります。 ウィザード全体で分岐を引き起こす決定ポイントは 2 つ以下にすることをお勧めします。また、1 つのブランチ内に入れ子になったブランチは 1 つ以下にすることをお勧めします。
分岐ウィザード内での安定したユーザー エクスペリエンスの作成に関するガイドラインについては、この記事の「ガイドライン」セクションの 「分岐 」を参照してください。
ナビゲーション ガイドは、タスクに多くの手順があり、ユーザーが順番に自分の位置を失う可能性がある場合や、完了にどれくらいの時間がかかるかを知りたい場合に便利です。
ナビゲーション ガイドは、多くの場合、ウィザードのページまたはセクションの一覧として表示され、目次のように、各ページの左側の列またはペインに表示されます。 リストはウィザード全体で保持されますが (各ページに同じページの一覧が表示されます)、ユーザーが現在シーケンス内の場所を示す視覚的な手段がいくつかあります (たとえば、太字を使用してアクティブなページまたはセクションを区別します)。
ナビゲーション ガイドは、シーケンシャルでも非シーケンシャルでもかまいません。 シーケンシャル型は、過去のページと既知の将来のページを示します。 ステップが既知で、ページが依存している場合は、ページではなくステップの観点から将来を提示できます。 その後、ページが認識されると動的にページを設定できます。 ナビゲーション シーケンスは固定されているため、ナビゲーション ガイドは対話型ではありません。
シーケンシャルでないナビゲーション ガイドは対話型であるため、ユーザーは以前に表示したページを直接見直すことができます。 また、省略可能に設計されたページのナビゲーション シーケンスの前にスキップすることもできます。 省略可能なページには、ほとんどの状況で許容される既定値が必要です。 この種類のガイドでは、次の操作を行います。
このシナリオでは、[戻る] ボタンの意味についてユーザーが混乱する可能性があります。 [戻る] をクリックすると、ナビゲーション ガイドの前のページまたはセクション、または最後に表示されたページまたはセクションが表示されますか? Windows ウィザードでは、他のコミット ボタンと共に右下隅ではなく、ウィザード ページの左上隅に [戻る] ボタンが配置されるようになったため、ユーザーは Back 機能を Web 上と見なします。 そのため、最適な解決策は、[戻る] ボタンに Web ナビゲーションの意味を与え ([戻る] をクリックすると、最後のページまたはセクションが表示されます)、ウィザードのナビゲーション ガイドを使用して順次ナビゲーションを行います。
ウィザードの設計には、ナビゲーションや分岐エクスペリエンスの処理方法など、タスク フロー全体に関する決定だけでなく、ウィザードを構成する個々のページに関連する決定も含まれます。 優れたウィザード ページを設計するための最も重要な原則は、整合性の原則です。ページの内容は一緒に属している必要があります。
ウィザード ページは、それぞれが概念的にハングアップし、タスク全体の 1 つの側面のみを処理する場合に、はるかに使い勝手が高くなります。 メイン命令は、これを実現するための主な手段です。 ユーザーにページの目標または目的を明確に特定します。 補足命令とページ上のコントロールはすべて、メイン命令に直接関係します。 ウィザード ページでは、何らかの考え方が必要なオプションをユーザーに提示する必要がありますが、ページ自体の整合性に重点を置いているため、その作業はうまくいきません。
残念ながら、ウィザードのデザイナーは、ページの使いやすさ、シンプルさ、整合性を示す証拠として、ユーザーの [次へ] ボタンの急速なクリックを間違えることがよくあります。 究極のウィザード エクスペリエンスは、[次へ]、[次へ]、[次へ]、[完了] ではありません。 このようなエクスペリエンスは、既定値が適切に選択されたことを示唆していますが、すべての選択肢が省略可能であるため、ウィザードが本当に必要ではなかったことも示唆しています。
ビジュアルとテキストの観点から、これらの要素をベアの要点に置き留めます。 1 つのページ ("ブリトー ウィザード") に複数のサブタスクをまとめるか、複雑な入力要件を提示するためのタブに頼る必要があります。 1 つのページには、ウィザードのタスク全体の 1 つのサブタスクが含まれている必要があります。
正しくない:
非常に密度の高いユーザー入力の 3 つのタブが必要な場合、このウィザード ページでは実行が多すぎます。
ほとんどの場合、ウィザード全体で各ページのサイズを維持して、一貫した外観を実現します。 Windows ウィザードでは、ページのサイズがコンテンツの量と一致するようにサイズ変更可能なページを使用できますが、このオプションを使用するのはごくわずかです。
最後に、各ウィザード ページの構造要素をシーケンスを通じて保持します。 たとえば、左上隅の [戻る] ボタンを 1 つまたは 2 つのページのコミット ボタン領域に移動しないでください。 このレベルのレイアウトの一貫性は、ユーザーがウィザード内で安定した感じを得るのに役立ちます。 これは、ページの視覚的整合性のベースラインと考えてください。
ユーザーは、画面上で大きなテキスト ブロックを読み取るための許容度が低く、タスクを迅速に移動することを目的とする UI サーフェイス内では、それほど許容されません。
ウィザードには、過剰に通信する傾向があります。 彼らは画面に多くのスペースを占有し、ドライブがスペースを埋めるように促しているようです。 これは、パーキンソンの法則のバリエーションのようなものです。UI テキストは、使用可能な領域を埋めるために拡張されます。
この過剰な原因の 1 つは冗長性です。 ウィザードの初期設計で使用されるテンプレートのため、タイトル バー、見出し、本文テキスト、コントロール ラベルなど、ページ上の複数の場所に同じ言語が表示される場合があります。
ウィザードのテキストを無情に排除するには、プロのエディターを雇う価値があります。 個々のページで不要な質問やオプションを削除し、ウィザード全体 (たとえば、従来の [ようこそ] ページと [おめでとう] ページ) からページ全体を削除します。 ユーザーまたはチームが内部的に使用するテクノロジや機能の専門用語ではなく、ターゲットユーザーがタスクを説明するために使用する言語を使用して、簡潔に記述されたメイン命令を使用して、ページのポイントにアクセスします。 このユーザー中心のアプローチは、プログラムのウィザードの通信を改善するために不可欠です。
ウィザードのトーンに特別な注意を払う:時にはプログラムの最も永続的な印象は、あなたが言うことではなく、どのように言うかの結果です! ウィザードでは、ユーザーは、プログラムが入力を求めるときに 2 人称代名詞 ("you") を自由に使用して、わかりやすい会話のトーンに慣れている。 ガイドラインの詳細については、「 スタイルとトーン」を参照してください。
ウィザード ページの文字数を減らすことは一般的に評価できますが、行き過ぎないように注意してください。 タスクが重要であり、ウィザードを保証する場合、ユーザーは賢明な選択をするのに十分な情報を持っていることに感謝します。 次の例は、意味を損なうことなくウィザードのテキストを圧縮する方法を示しています。
前:
後:
このウィザード ページの編集バージョンでは、タスク指向のメイン命令が提供され、メイン命令の下にある不要な説明の段落が削除され、チェック ボックスの目的を明確にするためにチェック ボックス ラベルが修正されます。
3 つの操作のみを行う場合...
実行しようとしているタスクを適切な UI でマップし、ジョブを実行します。ユーザーから多くの入力を収集する必要があると思う場合は、単にウィザードを既定値にしないでください。
ウィザードの長さと構造について慎重に検討してください。ユーザーが自分の主要なタスクやプログラムへの関心に戻ることができるように、短い分岐しないウィザードを使用して、エクスペリエンスを可能な限りシンプルに保つ必要があります。
ウィザードの各ページの整合性を確認します。ページの内容は明確に一緒に属している必要があります。
最初に、ダイアログ ボックス、作業ウィンドウ、単一ページなどの軽量の代替手段を検討してください。 ウィザードを使用する必要はありません。任意の UI で役立つ情報と支援を提供できます。
複数ステップのタスクにウィザードを使用します。 フィードバックを含むシングルステップ タスクには、複数ページのダイアログ ボックスを使用します。 ガイドラインの詳細については、「 ダイアログ ボックス」を参照してください。
正確:
この例では、Windows ネットワーク診断は進行状況ページと結果ページで構成されています。 タスクは 1 つのステップだけなので、ユーザーがウィザードで必要とするナビゲーション ボタンは必要ありません。 これは、実質的に複数ページのダイアログ ボックスとして表示されます。
垂直または水平のページ スクロールなしですべてのウィザード ページを表示できるウィンドウ サイズを選択します。 ページ上のコントロールにはスクロールが必要な場合があります。ウィザード ページ自体はスクロールできません。
ウィンドウのサイズを、タスクを快適に実行するのに十分な大きさにします。 ページ レイアウトを狭くしたり、ユーザーに過度にスクロールやサイズ変更を要求したりしないでください。
ただし、ウィンドウを過度に大きくしないでください。 ウィンドウを大きくすると、タスクはより複雑になり、対話のために追加の移動が必要になります。
サイズ変更可能なウィンドウは、より多くの画面領域からメリットを得られるが、不要なウィザードに使用します。 適切な最小サイズを割り当てます。 サイズ変更可能なウィンドウは、ページが大きなリスト ビューなどのサイズ変更可能なコンテンツを操作する必要がある場合に役立ちます。
正確:
より適切な例:
この例では、ウィンドウのサイズを変更すると、ユーザーは完全な一覧を表示できます。
コンテンツの必要に応じてページ サイズが変更される動的サイズのウィザードを使用することを検討してください。 これにより、ウィザードは、さまざまなコンテンツを含むページ レイアウトに対応できます。
ユーザーがウィザードのエクスペリエンスの安定性の欠如として変更を認識する可能性がある場合は、動的よりも静的なサイズ設定を優先します。 視覚的な安定性は、多くの場合、コンテンツの宿泊施設を切り捨てる。 ほとんどのウィザードでは、標準の静的ウィンドウ サイズを採用し、特別なケース用に動的サイズ設定を予約する必要があります。
分岐よりも非分岐ウィザードの設計を優先します。 分岐しないウィザードは、より単純で短く、簡単に移動できる傾向があります。 分岐ウィザードを使用すると、ユーザーはタスク内のステップの数と順序の場所を判断することが困難になります。
分岐する必要がある場合は、次のいずれかの方法を使用して、ユーザーの方向を設定できるようにします。
ページを列挙します。 一般的な手法は、各ページのシーケンス内のユーザーの位置を示す方法です。たとえば、手順 X は Y です。エンドポイント (Y) が安定していることを確認します。 値を変更すると、ユーザーの信頼度が損なわれます。
サブステップ ( 手順 2a/6 など) の概念を含めます。
各ステップに複数のページが含まれる場合があるページに関係なくステップを作成します。 たとえば、旅行サービスでは、業界向けの確立された e コマース規則に基づいてウィザード organizationを使用する場合があります。
正確:
論理ラベルを使用すると、分岐ウィザードのユーザーに適切な方向を提供できます。
列挙シーケンスでは、省略可能なステップを永続的として扱います。 たとえば、ブランチが省略可能な手順をいくつかスキップしているだけの場合は、番号を付け直すのではなく、フィードバックの手順もスキップするだけです。 したがって、ユーザーがページ 2 で選択を行い、ページ 3 と 4 を省略可能にする場合は、手順 1、2、5、および 6/6 を示します。 手順 5 と 6 の番号を付け直さないでください。
ウィザードで 1 つのブランチが使用されていて、その分岐がタスクの早い段階で行われる場合は、その時点でシーケンスを開始してから、分岐しない方法を使用します。 つまり、分岐の時点から、分岐の最後まで順番に進行します。
分岐する必要がある場合は、1 つのウィザード内でブランチの数を 1 つまたは 2 つに制限します。 ブランチ内に複数のブランチ ("入れ子になった" ブランチ) を含めてはいけません。
効率的な意思決定に重点を置く。 要点に焦点を当てるページの数を減らします。 関連ページを統合し、オプションのページをメインフローから除外します。 ウィザードを使用してユーザーが [次へ] を完全にクリックすると、最初は適切なエクスペリエンスのように見えるかもしれませんが、ユーザーが既定値を変更する必要がない場合は、ページが不要になる可能性があります。
各ページを 1 つの目的と視覚的な一貫性を持つよう設計します。 詳細については、「ページの 整合性」を参照してください。
ウェルカム ページを使用しないでください。最初のページは可能な限り機能します。 省略可能なはじめに ページは、次の場合にのみ使用します。
正しくない:
最新のウィザードでは、機能する最初のページを選択します。 ここでは何もする必要はありませんが、[次へ] をクリックします。 ユーザーが貴重な時間にこのトークン税を支払うことを強制する理由
ユーザーが選択を求められるページでは、最も可能性の高いケースに合わせて最適化します。 これらの種類のページは、指示だけでなく、実際の選択肢を提示する必要があります。
[コミット] ページを使用して、ユーザーがタスクにコミットするタイミングを明確にします。 通常、[コミット] ページは選択肢の最後のページであり、[次へ] ボタンはコミット中のタスクを示すようにラベルが付け直されます。
[進行状況] ページを使用して、長い操作の状態を表示します。 正常に完了すると、進行状況ページは自動的に次の手順に進みます。 ユーザーに表示する必要がある問題がある場合にのみ、進行状況ページに残る必要があります。 [進行状況ページに戻る] をクリックしても、副作用はありません。
ウィザードを終了する以外に何も行わない [おめでとう] ページは使用しないでください。 ウィザードの結果がユーザーに明らかな場合は、最後のコミット ボタンでウィザードを閉じます。
[概要] ページは、入力が複雑で、ユーザーが確認する必要がある場合、タスクに重大なリスク (財務上の切り替えなど) が含まれている場合、または(透明性を通じて信頼を築くために) 明確ではないユーザー入力に基づいてウィザードがアクションを実行する場合にのみ使用します。 多くの場合、概要ページはこの関連性バーを満たせず、省略できます。
回復できない問題が原因でウィザードを完了できない場合は、エラー ページを使用します。 このページでは、技術的な専門用語のユーザーが理解できない、明確な言語で問題が何であるかを説明します。 また、ユーザーが問題を解決するために実行できる実用的な手順を提供します。 その他のガイドラインについては、「 エラー メッセージ」を参照してください。
[戻る] ボタンにテキストを含めないでください。 代わりに、ラベル付けされていない矢印グリフを使用します。
[次へ] ボタンにテキストを含めます。 "次へ" という単語に加えてグリフ (や >>など>) を使用しないでください。
独自に意味があり、メイン命令への応答である特定のコミット ボタン ラベルを使用します。 ラベルを理解するために、ユーザーが他の情報を読む必要がないのが理想的です。 ユーザーは、静的テキストよりもコマンド ボタン ラベルを読み取る可能性がはるかに高くなります。
可能であれば、コミット ボタン ラベルに "Finish" という単語を使用しないでください。通常は、より具体的で具体的なコミット ボタンがあるためです。
ボタンをクリックするとタスクにコミットする場合 (タスクがまだ実行されていない場合)、メイン命令への応答である動詞で始まる特定のラベルを使用します (例: Print、Connect、Start)。
タスクがウィザード内で既に実行されている場合は、代わりに [閉じる] を使用します。
例外:
動詞を使用してコミット ボタンラベルを開始します。 例外は[OK]、[はい]、[いいえ] です。
末尾に句点を付けません。
トレーニング
ラーニング パス
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization