トレーニング
ラーニング パス
Power Apps のキャンバス アプリで UI とコントロールを使用する - Training
多くの場合、アプリのユーザー エクスペリエンスがアプリの成功を左右します。 このラーニング パスでは、最良のアプリ ナビゲーションを作成する方法と、テーマ、アイコン、画像、パーソナル化、さまざまなフォーム ファクター、およびコントロールを使用して最良の UI を構築方法に焦点を当てます。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
注意
この設計ガイドは Windows 7 用に作成されたものであり、新しいバージョンの Windows 用には更新されていません。 ガイダンスの多くは引き続き原則として適用されますが、プレゼンテーションと例には現在の設計ガイダンスは反映されていません。
すべての Microsoft Windows アプリケーションには、優れたタッチ エクスペリエンスが必要です。 そして、そのようなエクスペリエンスを作り出すことは、想像よりも簡単です。
タッチとは、1 本以上の指を使用してデバイスのディスプレイを介して入力を行い、Windows やアプリと対話することを指します。 タッチに最適化されたアプリには、より大きく、精度の低いタッチの接触領域、タッチ デバイスのさまざまなフォーム ファクター、ユーザーがタッチ デバイスを使用するときに考えられる多くの姿勢と持ち方に対応するように設計された UI と対話式操作モデルが備わっています。
各入力デバイスにはそれぞれの長所があります。 キーボードはテキストを入力したり、最小限の手の動きでコマンドを入力したりするのに最適です。 マウスは、効率的で正確なポインティングに最適です。 タッチは、オブジェクトの操作や簡単なコマンドの入力に最適です。 ペンは、手書きや描画と同様に、自由形式の表現に最適です。
Windows 8.1 は、従来の入力方法 (マウス、ペン、キーボードなど) を完全にサポートしながらも、タッチの応答性、精度、使いやすさに最適化されています。 従来の入力モードで提供される速度、精度、触覚的フィードバックは、多くのユーザーにとってなじみがあり、魅力的であり、特定の対話式操作を行うシナリオに対してより適している可能性があります。
マウス、ペン、アクセシビリティに関連するガイドラインについては、別のトピックに分けて説明しています。
アプリの対話式操作エクスペリエンスについて考えるときには:
UI がマウスに対して適切に動作していても、それがタッチに対して適切に動作するとは考えないでください。 優れたマウスのサポートは開始点であり、優れたタッチ エクスペリエンスにはいくつかの追加要件があります。
UI が指に対して適切に動作している場合は、ペンに対しても適切に動作すると考えます。 アプリをタッチ可能にすることは、優れたペンのサポートを提供するのにも役立ちます。 主な違いは、指の先端は丸いため、より大きなターゲットが必要になることです。
タッチを使用すると、オブジェクトと UI を直接操作できるため、よりすばやく、自然で魅力的なエクスペリエンスを実現できます。
ユーザーがタッチ入力を使用して、重大かつ重要なタスクを効率的に実行できるようにする必要があります。 ただし、テキストやピクセル操作などの特定のアプリ機能はタッチに適していない場合があり、最適な入力デバイス用に予約できます。
タッチ アプリの開発経験があまりない場合は、実践して学習することをお勧めします。 タッチ対応のコンピューターを入手し、マウスとキーボードを横に置き、指のみを使用してアプリを操作します。 タブレットをお持ちの場合は、膝の上で持ったり、テーブルの上に平らに置いたり、立っている時に腕に抱えたりなど、さまざまな姿勢でタブレットを持つ実験を行います。 縦向きと横向きで使用してみてください。
タッチによる対話式操作で最適に動作する、タッチに最適化されたアプリは通常、次のようなものです。
タッチでは、自然で、現実世界のような対話式操作が提供されます。 この印象は、直接操作とアニメーションによって完成されます。これは、オブジェクトに現実的で動的なモーションとフィードバックを与えることで行われます。 たとえば、カード ゲームについて考えてみましょう。 指を使ってカードをドラッグすることは便利で簡単なだけではなく、物理的なデッキで行うのと同じように、カードを出したり、滑らせたり、回したりするときの魅力的な現実世界の感覚を体験できます。 また、動かせないカードを動かそうとするときには、アクションは認識されたが実行できないことを明確に示すために、カードの動きを防ぐのではなく抵抗させて、所定の位置に戻らせる方がより優れたエクスペリエンスになります。
さいわい、アプリが既に適切に設計されている場合には、優れたタッチ エクスペリエンスを提供するのは簡単です。 そのためには、適切に設計されたプログラムは次のようになります。
タッチを使用すると、Windows アプリは物理的なジェスチャを使用して、UI 要素の直接操作をエミュレートできます。
タッチ対応アプリの設計時には、こちらのベスト プラクティスを考慮してください。
応答性は、直接的で魅力的なタッチ エクスペリエンスを作り出すために不可欠です。 直接的な感覚を得るには、ジェスチャがすぐに有効になる必要があり、オブジェクトのコンタクト ポイントはジェスチャ全体を通してユーザーの指の下にスムーズに留まる必要があります。 タッチ入力の効果はユーザーのモーションに直接マップする必要があるため、たとえば、ユーザーが指を 90 度回転させる場合、オブジェクトも 90 度回転する必要があります。 ラグ、不安定な応答、コンタクトの損失、不正確な結果はすべて、直接操作の認識と品質の認識を損なうものです。
一貫性は、自然で直感的に感じるタッチ エクスペリエンスを作り出すために不可欠です。 標準的なジェスチャを覚えたユーザーは、そのジェスチャがすべてのアプリで同じ効果を持つことを期待します。 混乱やフラストレーションを避けるために、標準的なジェスチャに標準以外の意味を割り当てないでください。 代わりに、プログラムに固有の操作に対してカスタム ジェスチャを使用します。
次は Windows タッチ言語について説明しますが、先に進む前に、基本的なタッチ入力用語の簡単な一覧を次に示します。
ジェスチャ
ジェスチャとは、入力デバイス (1本の指、複数の指、ペン/スタイラス、マウスなど) 上で、またはそれによって実行される物理的な動作です。 たとえば、コマンドを起動、アクティブ化、または呼び出すには、タッチまたはタッチパッド デバイスに対して 1 本の指によるタップを使用します (マウスによる左クリック、ペンによるタップ、キーボードの Enter に相当します)。
操作
操作とは、オブジェクトまたは UI がジェスチャに対して行う即時のリアルタイムの反応または応答です。 たとえば、通常、スライド ジェスチャとスワイプ ジェスチャの両方を行うと、要素または UI は何らかの方法で移動します。
操作の最終結果 (その結果が画面上および UI 上のオブジェクトによって表される方法) は、対話式操作です。
操作
対話式操作は、操作の解釈方法と、操作の結果に基づいたコマンドまたはアクションによって異なります。 たとえば、スライド ジェスチャとスワイプ ジェスチャの両方を使用してオブジェクトを移動させることができますが、結果は距離のしきい値を超えているかどうかによって異なります。 スライドは、オブジェクトをドラッグしたり、ビューをパンしたりするために使れますが、スワイプは、項目を選択したり、アプリ バーを表示したりするために使われます。
Windows には、システム全体で使用されるタッチ操作の簡潔なセットが用意されています。 このタッチ言語を一貫して適用すると、ユーザーが既に知っていることに対してアプリが親しみやすくなります。 これにより、アプリが覚えやすく、使いやすくなり、ユーザーの信頼度が高くなります。 タッチ言語の実装に関する詳細については、「ジェスチャ、操作、対話式操作」に関するページを参照してください。
長押しして学習する
長押しジェスチャでは、アクションやコマンドにコミットすることなく、詳細情報や教育ビジュアル (ヒントやコンテキスト メニューなど) が表示されます。 ビジュアルが表示されている間にスライド ジェスチャが開始された場合でも、パンは可能です。
重要
水平パンと垂直パンの両方が有効になっている場合は、長押しを使用して選択できます。
入力状態: 画面に接触している 1 本または 2 本の指。
モーション: モーションなし。
終了状態: 最後の指が離れるとジェスチャが終了します。
効果: 詳細情報を表示します。
長押しジェスチャ。
ホバーする
ホバーは、ユーザーがアクションを開始する前にヒントを通じて追加情報を取得できるようになるため、便利な対話式操作です。 これらのヒントを確認することで、ユーザーはより自信を持てるようになり、エラーを減らすことができます。
残念ながら、ホバーはタッチ テクノロジではサポートされていないため、ユーザーは指を使うときにホバーできません。 この問題の簡単な解決策は、ホバーを最大限に活用することですが、アクションの実行を必要としない方法でのみとなります。 実際には、これは通常、クリックすることでもアクションを実行できることを意味しますが、必ずしもまったく同じ方法ではありません。
この例では、ユーザーはホバーまたはクリックのいずれかによって今日の日付を表示できます。
タップして主要なアクションを行う
要素をタップすると、アプリの起動やコマンドの実行など、主要なアクションが呼び出されます。
入力状態: 1 本の指を画面またはタッチパッドに接触させ、長押し操作の時間のしきい値が発生する前に離す。
モーション: モーションなし。
終了状態: 指が離れるとジェスチャが終了します。
効果: アプリを起動するか、コマンドを実行します。
タップ ジェスチャ。
スライドしてパンする
スライドは主にパン操作に使用されますが、移動 (パンが 1 方向に制限されている場合)、描画、または書き込みにも使用できます。 スライドを使用して、スクラブ (ラジオ ボタンなどの関連するオブジェクトの上に指をスライドさせること) によって、密にパックされた小さな要素をターゲットにすることもできます。
入力状態: 画面に接触している 1 本または 2 本の指。
モーション: 追加の指を、互いを基準として同じ位置に保ちながらドラッグします。
終了状態: 最後の指が離れるとジェスチャが終了します。
効果: 指の動きに伴って、基になるオブジェクトを即時に、直接的に移動させます。 ジェスチャ全体で、指の下のコンタクト ポイントを必ず維持してください。
パン ジェスチャ。
スワイプして選択、コマンド実行、移動する
パンの方向 (パンが 1 方向に制限されている場合) に、短い距離で垂直に指をスライドさせると、リストまたはグリッド内のオブジェクトが選択されます。 オブジェクトが選択されている場合は、関連するコマンドを含むアプリ バーが表示されます。
入力状態: 1 本以上の指で画面にタッチします。
モーション: 移動操作の距離のしきい値が発生する前に、短い距離をドラッグして離します。
終了状態: 最後の指が離れるとジェスチャが終了します。
効果: 基になるオブジェクトが選択されるか、移動されるか、アプリ バーが表示されます。 ジェスチャ全体で、指の下のコンタクト ポイントを必ず維持してください。
スワイプ ジェスチャ。
ピンチとストレッチによるズーム
ピンチとストレッチの各ジェスチャは、光学式ズーム、サイズ変更、セマンティック ズームの 3 種類の操作に使用されます。
光学式ズームは、コンテンツ領域全体の拡大レベルを調整して、コンテンツをより詳細に表示します。 これに対し、サイズ変更は、コンテンツ領域に合わせてビューを変更せずに、コンテンツ領域内の 1 つ以上のオブジェクトの相対サイズを調整する手法です。
セマンティック ズームは、パン、スクロール、またはツリー ビュー コントロールを必要としない、構造化されたデータまたはコンテンツを 1 つのビュー (コンピューターのフォルダー構造、ドキュメントのライブラリ、フォト アルバムなど) 内で表示および移動するための、タッチに最適化された手法です。 セマンティック ズームでは、ズームイン時には詳細を表示し、ズームアウト時には一部を表示することにより、同じコンテンツの 2 つの異なるビューが提供されます。
入力状態: 2 本の指を同時に画面に接触させます。
モーション: 指を軸に沿って離すように移動 (ストレッチ) するか、近づけるように移動 (ピンチ) します。
終了状態: いずれかの指が離れるとジェスチャが終了します。
効果: 指が軸を基準に離れるか、近づくのに伴って、基になるオブジェクトが即時に、直接的に拡大または縮小されます。 ジェスチャ全体で、指の下のコンタクト ポイントを必ず維持してください。
ズーム ジェスチャ。
回転する
2 本以上の指を回転させると、オブジェクトが回転します。 画面全体を回転させるには、デバイス自体を回転させます。
入力状態: 2 本の指を同時に画面に接触させます。
モーション: 片方または両方の指を、他方を中心に回転させ、それらの間の直線に垂直に移動させます。
終了状態: いずれかの指が離れるとジェスチャが終了します。
効果: 指が回転したのと同じ量だけ、基になるオブジェクトを回転させます。 ジェスチャ全体で、指の下のコンタクト ポイントを必ず維持してください。
回転ジェスチャ。
回転は特定の種類のオブジェクトにのみ有効なため、システムの Windows 操作にはマップされません。
回転は、多くの場合、さまざまな人によって異なる方法で行われます。 軸となる指の周りに 1 本の指を回転させることを好む人もいれば、両方の指を円形の動きで回転させることを好む人もいます。 ほとんどの人は、1 本の指を他の指よりも動かす、2 本の組み合わせを使用しています。 任意の角度への滑らかな回転が最適な操作ですが、写真の表示などの多くのコンテキストでは、ユーザーが動きを開始したら、最も近い 90 度の回転に収めることをお勧めします。 写真の編集では、写真をまっすぐにするのに小さな回転を使用できます。
端からスワイプしてアプリ コマンドを表示する
画面の下端または上端から指を短い距離でスワイプすると、アプリ バーにアプリ コマンドが表示されます。
入力状態: 1 本以上の指でベゼルにタッチします。
モーション: 画面で短い距離をドラッグして離します。
終了状態: 最後の指が離れるとジェスチャが終了します。
効果: アプリ バーが表示されます。
端からスワイプ ジェスチャ。
開発者: 詳細については、DIRECTMANIPULATION_CONFIGURATION 列挙型に関するページを参照してください。
ここでは、タッチの使用方法のコントロールを最適化するためのガイドラインをいくつか示します。
指先の面積が大きいため、距離が近すぎる小さなコントロールを正確にターゲットにすることが難しい場合があります。
一般的なルールとして、23 x 23 ピクセル (13 x 13 DLU) のコントロール サイズが、あらゆる入力デバイスに適した最小の対話型コントロール サイズです。 これに対し、15 x 11 ピクセルのスピン コントロールは小さすぎて、タッチでは効果的に使用できません。
最小サイズは実際の物理領域に基づいており、ピクセルや DLU などのレイアウト メトリックには基づいていないことに注意してください。 調査では、指を使用した効率的で正確な対話式操作のための最小ターゲット領域は 6 x 6 ミリメートル (mm) であることが示されています。 この領域は、次のようなレイアウト メトリックに変換されます。
フォント | ミリメートル | 相対ピクセル | DLU |
---|---|---|---|
9 ポイントの Segoe UI | 6 x 6 | 23 x 23 | 13 x 13 |
8 ポイントの Tahoma | 6 x 6 | 23 x 23 | 15 x 14 |
さらに、調査によると、最小サイズが 10 x 10 mm (約 40 x 40 ピクセル) の場合、速度と精度が向上し、ユーザーがより快適に感じられることが示されています。 実際の場合には、最も重要であるか、最も頻繁に使用されるコマンドに使用するコマンド ボタンに、この大きなサイズを使用します。
目的は、巨大なコントロールを持つことではなく、タッチで簡単に使用できるコントロールを持つことです。
この例では、Microsoft Word の最も重要なコマンドに対して 10 x 10 mm よりも大きいボタンが使用されています。
このバージョンの電卓では、最も頻繁に使用されるコマンドに 10 x 10 mm よりも大きいボタンが使用されています。
タッチ ターゲットに最適なサイズはありません。 さまざまなサイズが、さまざまな状況で機能します。 重大な結果を伴うアクション (削除や閉じるなど) や頻繁に使用されるアクションでは、大きなタッチ ターゲットを使用する必要があります。 重要度の低い結果を伴う、使用頻度の低いアクションでは、小さなターゲットが使用されることがあります。
カスタム コントロール用のターゲット サイズのガイドライン
サイズのガイドライン | 説明 |
---|---|
7 x 7 mm: 推奨される最小サイズ 7x7 mm は、間違ったターゲットにタッチした場合に 1 つまたは 2 つのジェスチャーで、または 5 秒以内に修正できる適切な最小サイズです。 ターゲット間のパディングは、ターゲット サイズと同じくらい重要です。 |
|
精度が重要な場合 重大な結果を伴う、閉じる、削除する、およびその他の操作では、誤ったタップは許容できません。 間違ったターゲットを修正するために 2 つ以上のジェスチャ、5 秒、または主要なコンテキストの変更が必要な場合は、9 x 9 mm のターゲットを使用します。 |
|
単純に合わないとき 間違ったターゲットをタッチしても 1 つのジェスチャで修正できる限り、5 x 5 mm のターゲットを使用しても問題ありません。 この場合、ターゲット間に 2 mm のパディングを使用することが非常に重要です。 |
一般的なコントロール用のターゲット サイズのガイドライン
一般的なコントロールの場合は、推奨されるコントロール サイズを使用します。 推奨されるコントロールのサイズ設定は、チェック ボックスとラジオ ボタン (テキストの幅がやや補正される)、スピン コントロール (タッチでは使用不可だが重複している)、スプリッターを除き、23 x 23 ピクセル (13 x 13 DLU) の最小サイズ以上となります。
推奨されるコントロール サイズは簡単にタッチできます。
最も重要なコマンドまたは頻繁に使用されるコマンドに使用されるコマンド ボタンの場合、実用のときには常に最小で 40 x 40 ピクセル (23 x 22 DLU) のサイズを使用します。 これにより、速度と精度が向上し、ユーザーもより快適に感じらるようになります。
実用のときには常に、重要なコマンドや頻繁に使用されるコマンドに大きなコマンド ボタンを使用します。
その他のコントロールの場合:
より大きなクリック ターゲットを使用します。 小さいコントロールの場合は、静的に表示される UI 要素よりもターゲット サイズを大きくします。 たとえば、16 x 16 ピクセルのアイコン ボタンには 23 x 23 ピクセルのクリック ターゲット ボタンを持たせることができます。テキスト要素には、テキストより 8 ピクセル広い、高さ 23 ピクセルの四角形の選択を持たせることができます。
正解です:
誤った例:
正解です:
正しい例では、クリック ターゲットは静的に表示される UI 要素よりも大きくなります。
重複しているクリック ターゲットを使用します。 コントロールに重複している機能がある場合、クリック ターゲットが最小サイズよりも小さくなることが許容されます。
たとえば、ツリー ビュー コントロールで使用されるプログレッシブ開閉用の三角形は 6 x 9 ピクセルのみですが、その機能は関連する項目ラベルと重複しています。
ツリー ビューの三角形は小さすぎて簡単にタッチできませんが、より大きな関連するラベルを使用することで機能的に重複するようになります。
システム メトリックを尊重しましょう。 サイズをハードコーディングしないでください。 必要に応じて、ユーザーはシステム メトリックまたは dpi を自分のニーズに合うように変更できます。 ただし、通常、UI を使用可能にするためにユーザーがシステム設定を調整する必要はないため、これは最後の手段として扱ってください。
この例では、メニューの高さのシステム メトリックが変更されました。
テキストの編集
テキストの編集は、指を使用する場合に最も困難な操作のうちの 1 つです。 制約付きコントロール、適切な既定値、オートコンプリートを使用すると、テキストを入力する必要がなくなるか、軽減されます。 ただし、アプリでテキストの編集が必要な場合は、タッチの使用時に入力 UI を既定で最大 150% まで自動的にズームすることで、ユーザーの生産性を高めることができます。
たとえば、電子メール プログラムでは通常のタッチ可能なサイズで UI が表示されますが、入力 UI を 150% に拡大してメッセージを作成できます。
この例では、入力 UI は 150% にズームされます。
コントロール間の間隔は、コントロールを簡単にタッチできるようにするための重要な要素です。 指をポインティング デバイスとして使用する場合、ターゲット設定の速度は速くなりますが、精度が低下するため、ユーザーは意図したターゲットの外側をタップする頻度が高くなります。 対話型コントロールが非常に近い距離で配置されているが、実際には触れ合っていない場合、ユーザーはコントロール間の非アクティブな領域をクリックする可能性があります。 非アクティブな領域をクリックしても結果や視覚的なフィードバックがないため、ユーザーは多くの場合、何が間違っていたのか分かりません。
使用する入力デバイスに基づいて間隔を動的に調整します。 これは、メニューやポップアップなどの一時的な UI で特に便利です。
対話型コントロールのターゲット領域の間に、少なくとも 5 ピクセル (3 DLU) の領域を指定します。 小さなコントロールの間隔が狭すぎる場合、ユーザーは間違ったオブジェクトをタップしないように正確にタップする必要があります。
グループ内のコントロールを区別しやすくするには、コントロール間に、推奨されているものよりも大きい垂直方向の間隔を使用します。 たとえば、高さ 19 ピクセルのラジオ ボタンは、推奨される最小サイズの 23 ピクセルよりも小さくなります。 垂直方向のスペースを使用できる場合は、標準の 7 ピクセルに 4 ピクセルの領域を追加することで、推奨されるサイズ設定とほぼ同じ効果を実現できます。
正解です:
より適切な例:
より良い例では、ラジオ ボタン間の追加の間隔により、区別しやすくなっています。
タッチを使用する場合には追加の間隔があれば望ましいが、マウスやキーボードを使用する場合はそうではないことがあります。 このような場合は、タッチを使用してアクションを開始する場合にのみ、より間隔の広い設計を使用します。
使用される可能性が最も高い場所の近くにコントロールを配置するレイアウトを選択します。 可能な限りタスクの対話式操作を小さな領域内に保持し、使用される可能性が最も高い場所の近くにコントロールを配置します。 特に一般的なタスクやドラッグの場合には、長い距離の手の動きを避けるようにします。
現在のポインターの位置がターゲットに最も近いため、取得が簡単であることを考慮してください。 したがって、コンテキスト メニューは、Microsoft Office で使用されるミニ ツール バーと同様に、Fitts の法則を最大限に活用します。
小さなコントロールをアプリやディスプレイの端の近くに配置しないようにします。 端の近くにある小さなターゲットは、タッチするのが難しい場合があります (ディスプレイのベゼルがエッジ ジェスチャに干渉する可能性があります)。 ウィンドウが最大化されたときにコントロールを簡単にターゲットにするには、少なくとも 23 x 23 ピクセル (13 x 13 DLU) にするか、ウィンドウの端から離して配置します。
推奨される間隔を使用します。 推奨される間隔はタッチに対応しています。 ただし、サイズと間隔を大きくすることでアプリにメリットがある場合は、必要に応じて推奨されるサイズ設定と間隔を最小値にすることを検討してください。
対話型コントロール間に少なくとも 5 ピクセル (3 DLU) の領域を指定します。 そうすることで、ユーザーが目的のターゲットの外側をタップしたときの混乱を防ぐことができます。
コマンド リンク、チェック ボックス、ラジオ ボタンなど、コントロールのグループ内やグループ間に、推奨されているものよりも大きい垂直方向の領域を追加することを検討してください。 そうすることで、区別しやすくなります。
タッチを使用してアクションを開始する場合は、推奨されているものよりも大きい垂直方向の領域を動的に追加することを検討してください。 そうすることで、オブジェクトを区別しやすくなりますが、キーボードやマウスを使用する際に追加の領域を取ることはありません。 通常のサイズの 3 分の 1 または少なくとも 8 ピクセルの領域を増やします。
この例では、Windows 7 タスク バーのジャンプ リストは、タッチを使用して表示すると、より間隔が広くなります。
正しいコントロールを使用することは、タッチに最適化されたアプリを作る過程の一部にすぎません。これらのコントロールでサポートされる全体的な対話式操作のモデルも考慮する必要があります。 これを行うのに役立ついくつかのガイドラインを次に示します。
ホバーを冗長にします。 ホバーはほとんどのタッチ テクノロジではサポートされていないため、このようなタッチスクリーンを使用しているユーザーはホバーを必要とするタスクを実行できません。
テキスト入力が必要なアプリの場合は、次の方法でタッチ キーボード機能を完全に統合します。
注意
開発者: タッチ キーボードの統合の詳細については、ITextInputPanelに関するページを参照してください。
プログラムにテキストの編集を必要とするタスクがある場合に、ユーザーがコンテンツ UI をズームできるようにします。 タッチを使用する場合は、自動的に 150% にズームすることを検討してください。
必要に応じて、スムーズで応答性の高いパンとズームを提供します。 応答性を維持するため、パンまたはズーム後にすばやく再描画します。 これを行うことは、直接操作を真に直接的に感じさせるために必要です。
パンまたはズーム中は、ジェスチャ全体を通して、コンタクト ポイントが指の下に留まるようにします。 そうしない場合、パンまたはズームの制御が難しくなります。
ジェスチャは記憶されるため、アプリ間で一貫性のある意味を割り当てます。 固定されたセマンティクスを持つジェスチャには異なる意味を与えないようにしてください。 代わりに、適切なアプリ固有のジェスチャを使用してください。
直接操作により、タッチが自然で表現力豊かになり、効率的で魅力的になります。 ただし、直接操作を行う場合、誤った操作が発生する可能性があるため、寛容性が必要になります。
寛容性とは、望ましくない行動を簡単に取り消したり、修正したりする能力です。 元に戻す、分かりやすい視覚的なフィードバックを提供する、頻繁に使用されるコマンドと破壊的なコマンドを明確に物理的に分離する、およびユーザーが間違いを簡単に修正できるようにすることで、タッチ エクスペリエンスに寛容性を持たせます。 寛容性に関連付けられているのは、望ましくないアクションが最初に発生するのを防ぐことです。これは、意図しない結果を招く可能性のあるリスクの高いアクションやコマンドに対して制約付きコントロールと確認を使用して行うことができます。
元に戻すコマンドを提供します。 すべてのコマンドを元に戻すための簡単な方法を提供することをお勧めしますが、アプリには、元に戻すことができないコマンドが含まれる場合があります。
実用の場合は常に、指を下げた時に適切なフィードバックを提供しますが、指を上げるまではアクションを実行しないようにします。 これにより、間違った操作を行う前に、それを修正することができます。
実用の場合は常に、ユーザーが簡単に間違いを修正できるようにします。 指を上げたときにアクションが有効になる場合は、指を下げたままスライドさせることでユーザーが間違いを修正できるようにします。
実用の場合は常に、動きに抵抗することにより、直接操作を実行できないことを示します。 動かすことはできるようにしますが、放されたときにオブジェクトを所定の位置に戻して、アクションが認識されたが実行できないことを明確に示します。
頻繁に使用されるコマンドと破壊的コマンドを明確に物理的に分離します。 そうしない場合、ユーザーが破壊的なコマンドに誤ってタッチする可能性があります。 コマンドは、その効果が広範囲に及び、簡単に元に戻すことができないか、効果がすぐに気が付くものではない場合、破壊的と見なされます。
意図しない結果を招く可能性のあるリスクの高いアクションまたはコマンドの場合、コマンドを確認するようにします。 この目的のため、確認のダイアログ ボックスを使用します。
ユーザーがタッチを使用するときに誤って実行する傾向があり、気付かないままになるか、元に戻すことが困難なその他のアクションについても確認することを検討してください。 通常、これらはルーチン確認と呼ばれ、ユーザーがマウスやキーボードで誤ってこのようなコマンドを発行することはめったにないという前提に基づき、推奨されません。 不要な確認を防ぐには、コマンドがタッチを使用して開始された場合にのみ、これらの確認を表示するようにします。
ルーチン確認は、ユーザーがタッチを使用して誤って行うことが多い対話式操作に対して使用できます。
開発者: INPUT_MESSAGE_SOURCE API を使用して、マウス イベントとタッチ イベントを区別することができます。
トレーニング
ラーニング パス
Power Apps のキャンバス アプリで UI とコントロールを使用する - Training
多くの場合、アプリのユーザー エクスペリエンスがアプリの成功を左右します。 このラーニング パスでは、最良のアプリ ナビゲーションを作成する方法と、テーマ、アイコン、画像、パーソナル化、さまざまなフォーム ファクター、およびコントロールを使用して最良の UI を構築方法に焦点を当てます。