ゲームパッドとリモコンの操作

"多くの対話式操作エクスペリエンスは、ゲームパッド、リモコン、キーボード間で共有される"

PC、ノート PC、タブレットの従来の入力の種類 (マウス、キーボード、タッチなど) と、テレビや Xbox の "10 フィート" エクスペリエンスの一般的な入力の種類 (ゲームパッドやリモコンなど) の両方で、アプリの使いやすさとアクセシビリティを実現する対話式操作エクスペリエンスを Windows アプリケーションで構築します。

"10 フィート" エクスペリエンスでの Windows アプリケーションの一般的な設計ガイダンスについては、「Xbox およびテレビ向け設計」を参照してください。

概要

このトピックでは、対話式操作の設計における考慮事項 (プラットフォームが代わりに対応する場合は、考慮しなくてよいこと) について説明します。また、デバイス、入力の種類、ユーザーの能力や好みに関係なく、使いやすい Windows アプリケーションを構築するためのガイダンス、推奨事項、提案を示します。

要するに、アプリケーションは、"10 フィート" 環境と同様に "2 フィート" 環境でも直感的で使いやすいものである必要があります (逆の場合も同様です)。 ユーザーの優先デバイスをサポートし、UI フォーカスを明確で間違えようのないものにします。また、ナビゲーションに一貫性があり、予測可能であるようにコンテンツを配置し、ユーザーが目的の操作を最短で実行できるようにします。

2 フィート エクスペリエンスと 10 フィート エクスペリエンスの両方に最適化する

少なくとも、アプリケーションをテストして、2 フィートと 10 フィートの両方のシナリオで適切に動作すること、およびすべての機能が Xbox ゲームパッドとリモコンで検出可能かつアクセス可能であることを確認することをお勧めします。

すべての入力デバイスに対応し、2 フィート エクスペリエンスと 10 フィート エクスペリエンスの両方で使用できるようにアプリを最適化する他の方法を次に示します (それぞれ、このトピックの該当セクションにリンクしています)。

機能	説明
XY フォーカス ナビゲーションとインタラクション	XY フォーカス ナビゲーションにより、ユーザーはアプリの UI 内を移動できるようになります。 ただし、これにより、ユーザーは上下左右に移動することが制限されます。 このセクションでは、これに対処するための推奨事項とその他の考慮事項について説明します。
[マウス モード]	マップ、描画アプリ、ペイント アプリなど、アプリケーションの種類によっては、XY フォーカス ナビゲーションが実用的ではなかったり、不可能である場合もあります。 このような場合、マウス モードを使用すると、ユーザーは PC のマウスと同様に、ゲームパッドまたはリモコンを使って自由に移動できます。
フォーカスビジュアル	フォーカスの視覚効果は、現在フォーカスがある UI 要素を強調表示する境界線です。 これにより、ユーザーは移動中または操作中の UI をすばやく識別できます。
フォーカス エンゲージメント	フォーカス エンゲージメントでは、ユーザーは UI 要素を操作するために、その要素にフォーカスがあるときに、ゲームパッドまたはリモコンの A/[選択] ボタンを押す必要があります。
ハードウェア ボタン	ゲームパッドとリモコンでは、ボタンと構成が大きく異なります。

ゲームパッドとリモコン

キーボードとマウスが PC 用と同じように、タッチは電話とタブレット用であり、ゲームパッドとリモコンは 10 フィート エクスペリエンスの主要な入力デバイスです。 このセクションでは、ハードウェア ボタンの概要と実行内容について説明します。 XY フォーカス ナビゲーションと操作と Mouse モードでは、これらの入力デバイスを使用するときにアプリを最適化する方法について説明します。

すぐに使えるゲームパッドとリモート動作の品質は、アプリでキーボードがどの程度サポートされているかによって異なります。 アプリがゲームパッド/リモートで適切に動作することを確認する良い方法は、PC 上のキーボードで適切に動作することを確認してから、ゲームパッド/リモートでテストして UI の弱点を見つけることです。

ハードウェア ボタン

このドキュメント全体を通して、ボタンは次の図に示す名前で参照されます。

図からわかるように、ゲームパッドでサポートされているボタンの中には、リモート コントロールではサポートされていないボタンと、その逆のボタンがあります。 1 つの入力デバイスでのみサポートされているボタンを使用して UI の移動を高速化できますが、重要な操作にボタンを使用すると、ユーザーが UI の特定の部分と対話できない場合があることに注意してください。

次の表に、Windows アプリでサポートされているすべてのハードウェア ボタンと、それらがサポートされている入力デバイスを示します。

Button	Gamepad	リモコン
A/Select ボタン	はい	はい
[B/戻る] ボタン	はい	はい
方向パッド (D パッド)	はい	はい
Menu ボタン	はい	はい
View ボタン	はい	はい
X ボタンと Y ボタン	はい	いいえ
左のスティック	はい	いいえ
右のスティック	はい	いいえ
左トリガーと右トリガー	はい	いいえ
左右のバンパー	はい	いいえ
OneGuide ボタン	いいえ	はい
[ボリューム] ボタン	いいえ	はい
チャネル ボタン	いいえ	はい
メディア コントロール ボタン	いいえ	はい
ミュート ボタン	いいえ	はい

組み込みボタンのサポート

UWP では、既存のキーボード入力動作がゲームパッドとリモコンの入力に自動的にマップされます。 次の表に、これらの組み込みマッピングを示します。

[キーボード]	ゲームパッド/リモート
方向キー	D パッド (ゲームパッドの左スティックも)
Space キー	A/Select ボタン
Enter	A/Select ボタン
エスケープ特殊文字	B/Back ボタン*

*B ボタンの KeyDown イベントと KeyUp イベントのどちらもアプリで処理されない場合、SystemNavigationManager.BackRequested イベントが発生し、アプリ内で "戻る" ナビゲーションが発生します。 ただし、次のコード スニペットのように、これを自分で実装する必要があります。

// This code goes in the MainPage class

public MainPage()
{
    this.InitializeComponent();

    // Handling Page Back navigation behaviors
    SystemNavigationManager.GetForCurrentView().BackRequested +=
        SystemNavigationManager_BackRequested;
}

private void SystemNavigationManager_BackRequested(
    object sender,
    BackRequestedEventArgs e)
{
    if (!e.Handled)
    {
        e.Handled = this.BackRequested();
    }
}

public Frame AppFrame { get { return this.Frame; } }

private bool BackRequested()
{
    // Get a hold of the current frame so that we can inspect the app back stack
    if (this.AppFrame == null)
        return false;

    // Check to see if this is the top-most page on the app back stack
    if (this.AppFrame.CanGoBack)
    {
        // If not, set the event to handled and go back to the previous page in the
        // app.
        this.AppFrame.GoBack();
        return true;
    }
    return false;
}

Xbox One の Windows アプリでは、メニュー ボタンを押してコンテキスト メニューを開く操作もサポートされています。 詳細については、「 CommandBar と ContextFlyoutを参照してください。

アクセラレータのサポート

アクセラレータ ボタンは、UI を介してナビゲーションを高速化するために使用できるボタンです。 ただし、これらのボタンは特定の入力デバイスに固有の場合があるため、すべてのユーザーがこれらの機能を使用できるわけではないことに注意してください。 実際、Xbox One で Windows アプリのアクセラレータ機能をサポートしている入力デバイスは、現時点ではゲームパッドだけです。

次の表に、UWP に組み込まれているアクセラレータのサポートと、独自に実装できるアクセラレータのサポートを示します。 カスタム UI でこれらの動作を利用して、一貫性のあるわかりやすいユーザー エクスペリエンスを提供します。

相互作用	キーボード/マウス	Gamepad	組み込み対象:	推薦対象:
ページアップ/ダウン	ページアップ/ダウン	左/右トリガー	CalendarView、 ListBox、 ListViewBase、 ListView、 ScrollViewer、 Selector、 LoopingSelector、 ComboBox、 FlipView	垂直スクロールをサポートするビュー
ページの左/右	なし	左/右バンパー	ListBox、ListViewBase、ListView、ScrollViewer、Selector、LoopingSelector、FlipView	水平スクロールをサポートするビュー
拡大/縮小	Ctrl +/-	左/右トリガー	なし	ScrollViewer、拡大/縮小をサポートするビュー
ナビゲーション ウィンドウを開く/閉じる	なし	表示	なし	ナビゲーション ウィンドウ
検索する	なし	Y ボタン	なし	アプリのメイン検索機能へのショートカット
コンテキスト メニューを開く	右ボタンのクリック	Menu ボタン	ContextFlyout	コンテキスト メニュー

XY フォーカス ナビゲーションとインタラクション

アプリがキーボードの適切なフォーカス ナビゲーションをサポートしている場合、これはゲームパッドとリモート コントロールに適切に変換されます。 方向キーを使用したナビゲーションは、 D-pad (ゲームパッドの 左スティック ) にマップされ、UI 要素との対話は Enter/Select キーにマップされます ( Gamepad とリモート コントロールを参照)。

多くのイベントやプロパティがキーボードとゲームパッドの両方で使用されます。これらはどちらも KeyDown イベントと KeyUp イベントを発生させ、IsTabStop="True" プロパティと Visibility="Visible" プロパティがあるコントロール間のみを移動します。 キーボードの設計ガイダンスについては、「 Keyboard の操作」を参照してください。

キーボードのサポートが適切に実装されている場合、アプリは適切に動作します。ただし、すべてのシナリオをサポートするために追加の作業が必要になる場合があります。 可能な限り最適なユーザー エクスペリエンスを提供するために、アプリの特定のニーズについて考えてください。

フォーカスに関する問題のデバッグ

FocusManager.GetFocusedElement メソッドは、現在フォーカスがある要素を示します。 これは、フォーカス ビジュアルの場所が明らかでない場合に役立ちます。 この情報は、次のように Visual Studio の出力ウィンドウに記録できます。

page.GotFocus += (object sender, RoutedEventArgs e) =>
{
    FrameworkElement focus = FocusManager.GetFocusedElement() as FrameworkElement;
    if (focus != null)
    {
        Debug.WriteLine("got focus: " + focus.Name + " (" +
            focus.GetType().ToString() + ")");
    }
};

XY ナビゲーションが期待した方法で動作しない場合、次の 3 つの一般的な理由があります。

• IsTabStop プロパティまたは Visibility プロパティが正しく設定されていません。
• フォーカスを取得するコントロールが、実際には想定以上の大きさです。XY ナビゲーションでは、対象となるものをレンダリングするコントロールの部分だけが考慮されるのではなく、コントロールの合計サイズ (ActualWidth と ActualHeight) が考慮されます。
• フォーカス対応コントロールが別のコントロールの上に配置されています。XY ナビゲーションでは、重なり合ったコントロールはサポートされません。

これらの問題を解決しても XY ナビゲーションが期待どおり動作しない場合は、「 既定のナビゲーションの適用」で説明されている方法を使用して、フォーカスを取得する要素を手動でポイントできます。

XY ナビゲーションが意図したとおりに動作していても、フォーカスビジュアルが表示されない場合は、次のいずれかの問題が原因である可能性があります。

• コントロールを再テンプレート化し、フォーカス ビジュアルを含めませんでした。 UseSystemFocusVisuals="True"設定するか、フォーカス ビジュアルを手動で追加します。
• Focus(FocusState.Pointer)を呼び出してフォーカスを移動しました。 FocusState パラメーターは、フォーカス ビジュアルの動作を制御します。 通常、これを FocusState.Programmatic に設定する必要があります。これにより、前に表示されていた場合はフォーカスの視覚効果が表示され、前に非表示になっていた場合は非表示になります。

このセクションの残りの部分では、XY ナビゲーションを使用するときの一般的な設計上の課題について詳しく説明し、それらを解決するいくつかの方法を提供します。

アクセスできない UI

XY フォーカス ナビゲーションではユーザーの上下左右の移動が制限されるため、UI の一部にアクセスできないシナリオが発生する可能性があります。 次の図は、XY フォーカス ナビゲーションでサポートされていない UI レイアウトの種類の例を示しています。 垂直方向と水平方向のナビゲーションが優先され、中央の要素がフォーカスを取得するのに十分な優先順位になることがないため、中央の要素にはゲームパッド/リモートを使用してアクセスできないことに注意してください。

何らかの理由で UI を再配置できない場合は、次のセクションで説明するいずれかの手法を使用して、既定のフォーカス動作をオーバーライドします。

既定のナビゲーションのオーバーライド

ユニバーサル Windows プラットフォームは、D パッド/左スティック ナビゲーションがユーザーにとって理にかなっていることを確認しようとしますが、アプリの意図に合わせて最適化された動作を保証することはできません。 ナビゲーションがアプリ用に最適化されていることを確認する最善の方法は、ゲームパッドでテストし、アプリのシナリオに適した方法ですべての UI 要素にユーザーがアクセスできることを確認することです。 アプリのシナリオで、提供される XY フォーカス ナビゲーションによって実現されない動作が必要な場合は、次のセクションの推奨事項に従うか、動作をオーバーライドして論理項目にフォーカスを配置することを検討してください。

次のコード スニペットは、XY フォーカス ナビゲーションの動作をオーバーライドする方法を示しています。

<StackPanel>
    <Button x:Name="MyBtnLeft"
            Content="Search" />
    <Button x:Name="MyBtnRight"
            Content="Delete"/>
    <Button x:Name="MyBtnTop"
            Content="Update" />
    <Button x:Name="MyBtnDown"
            Content="Undo" />
    <Button Content="Home"  
            XYFocusLeft="{x:Bind MyBtnLeft}"
            XYFocusRight="{x:Bind MyBtnRight}"
            XYFocusDown="{x:Bind MyBtnDown}"
            XYFocusUp="{x:Bind MyBtnTop}" />
</StackPanel>

この場合、フォーカスが Home ボタン上にあり、ユーザーが左に移動すると、フォーカスは MyBtnLeft ボタンに移動します。ユーザーが右に移動すると、フォーカスは MyBtnRight ボタンに移動します。などです。

フォーカスがコントロールから特定の方向に移動しないようにするには、 XYFocus* プロパティを使用して、同じコントロールをポイントします。

<Button Name="HomeButton"  
        Content="Home"  
        XYFocusLeft ="{x:Bind HomeButton}" />

これらの XYFocus プロパティを使用すると、フォーカスを持つ子が同じ XYFocus プロパティを使用しない限り、次のフォーカス候補がビジュアル ツリーから外れたときに、コントロールの親が子のナビゲーションを強制することもできます。

<StackPanel Orientation="Horizontal" Margin="300,300">
    <UserControl XYFocusRight="{x:Bind ButtonThree}">
        <StackPanel>
            <Button Content="One"/>
            <Button Content="Two"/>
        </StackPanel>
    </UserControl>
    <StackPanel>
        <Button x:Name="ButtonThree" Content="Three"/>
        <Button Content="Four"/>
    </StackPanel>
</StackPanel>

上のサンプルでは、フォーカスが Button Two で、ユーザーが右に移動した場合、最適なフォーカス候補は Button Four です。ただし、親UserControlがビジュアル ツリーの外にあるときに強制的に移動するため、フォーカスは Button Three に移動されます。

最小クリック数のパス

ユーザーが最も一般的なタスクを最小限のクリック回数で実行できるようにしてください。 次の例では、 TextBlock は、 Play ボタン (最初はフォーカスを取得) と一般的に使用される要素の間に配置され、優先度の高いタスクの間に不要な要素が配置されます。

次の例では、代わりに TextBlock を Play ボタンの上に配置します。 優先度の高いタスクの間に不要な要素が配置されないように UI を再配置するだけで、アプリの使いやすさが大幅に向上します。

CommandBar と ContextFlyout

CommandBarを使用する場合は、「Problem: 長いスクロール リスト/グリッドの後にある UI 要素で説明されているように、リストをスクロールする問題に注意してください。 次の図は、リスト/グリッドの下部に CommandBar を含む UI レイアウトを示しています。 ユーザーが CommandBarに到達するには、リスト/グリッドをスクロールダウンする必要があります。

CommandBar をリスト/グリッド上に配置した場合はどうしますか? リスト/グリッドを下にスクロールしたユーザーは、 CommandBarに到達するために上にスクロールする必要があります。以前の構成よりもナビゲーションが少し少なくなります。 これは、アプリの初期フォーカスが CommandBarの横または上に配置されていることを前提としています。初期フォーカスがリスト/グリッドの下にある場合、このアプローチは機能しません。 これらの CommandBar 項目が、頻繁にアクセスする必要のないグローバル アクション 項目 ( Sync ボタンなど) である場合は、リスト/グリッドの上に配置してもかまいません。

CommandBarの項目を垂直方向にスタックすることはできませんが、スクロール方向 (垂直スクロール リストの左または右、水平方向のスクロール リストの上下など) に配置することも、UI レイアウトに適しているかどうかを検討する必要がある別のオプションです。

ユーザーがアイテムに簡単にアクセスできるようにする必要があるCommandBarがアプリにある場合は、これらの項目を ContextFlyout 内に配置しCommandBarから削除することを検討してください。 ContextFlyout は、UIElement のプロパティであり、その要素に関連づけられたコンテキスト メニューです。 PC では、 ContextFlyoutを持つ要素を右クリックすると、そのコンテキスト メニューがポップアップ表示されます。 Xbox One では、フォーカスがそのような要素にあるときに Menu ボタンを押すと発生します。

UI レイアウトの課題

一部の UI レイアウトは、XY フォーカス ナビゲーションの性質上、より困難であり、ケース バイ ケースで評価する必要があります。 単一の "正しい" 方法はなく、どのソリューションを選択するかはアプリの特定のニーズに応じて異なりますが、優れたテレビエクスペリエンスを実現するために使用できる手法がいくつかあります。

これをよりよく理解するために、これらの問題とそれらを克服する手法の一部を示す架空のアプリを見てみましょう。

以下は、販売可能な住宅のリスト、地図、プロパティの説明、およびその他の情報を示す架空の不動産アプリです。 このアプリでは、次の手法を使用して克服できる 3 つの課題があります。

• UI の再配置
• フォーカス エンゲージメント
• [マウス モード]

問題: 長いスクロール リスト/グリッドの後に配置された UI 要素

次の図に示すプロパティの ListView は、非常に長いスクロール リストです。 操作がListViewで必要、ユーザーがリストに移動すると、リストの最初の項目にフォーカスが置かれます。 ユーザーが Previous または Next ボタンに到達するには、リスト内のすべての項目を表示する必要があります。 このように、リスト全体を移動することをユーザーに要求するのが望ましくない場合 (つまり、リストがこのエクスペリエンスを許容できる長さではない場合) は、他のオプションを検討することをお勧めします。

ソリューション

UI の並べ替え

最初のフォーカスがページの下部に配置されていない限り、長いスクロール リストの上に配置された UI 要素は、通常、下に配置する場合よりも簡単にアクセスできます。 この新しいレイアウトが他のデバイスで機能する場合は、Xbox One のためだけに特別な UI 変更を行う代わりに、すべてのデバイス ファミリのレイアウトを変更すると、コストの低いアプローチになる可能性があります。 さらに、UI 要素をスクロール方向に対して配置すると (つまり、水平方向にスクロール リストに対して、または水平方向にスクロール リストに対して)、アクセシビリティがさらに向上します。

フォーカス エンゲージメント

エンゲージメントが取得されるとListView全体が 1 つのフォーカス ターゲットになります。 ユーザーはリストの内容をバイパスして、次のフォーカス可能な要素に移動できます。 エンゲージメントをサポートするコントロールと、 Focus エンゲージメントで使用する方法の詳細。

問題: フォーカス可能な要素がない ScrollViewer

XY フォーカス ナビゲーションは一度に 1 つのフォーカス可能な UI 要素への移動に依存するため、フォーカス可能な要素 (この例のようにテキストのみを含む要素など) を含まない ScrollViewer は、ユーザーが ScrollViewer内のすべてのコンテンツを表示できないシナリオを引き起こす可能性があります。 このシナリオおよびその他の関連するシナリオの解決策については、「 Focus engagement」を参照してください。

問題: 自由スクロール UI

アプリで描画サーフェイスなどの自由にスクロールする UI が必要な場合、またはこの例では、XY フォーカス ナビゲーションは機能しません。 このような場合は、 モードを有効にして ユーザーが UI 要素内を自由に移動できるようにします。

[マウス モード]

「 XY フォーカス ナビゲーションと操作」で説明されているように Xbox One では XY ナビゲーション システムを使用してフォーカスが移動され、ユーザーは上下左右に移動して、フォーカスをコントロールから制御に移動できます。 ただし、 WebView や MapControl などの一部のコントロールでは、ユーザーがコントロールの境界内でポインターを自由に移動できる、マウスのような操作が必要です。 また、ユーザーがページ全体にポインターを移動でき、ユーザーがマウスを使って PC で見つけることができるようなゲームパッド/リモートのエクスペリエンスを持つことも理にかなっているアプリもあります。

このようなシナリオでは、ページ全体またはページ内のコントロールにポインター (マウス モード) を要求する必要があります。 たとえば、アプリには、コントロール内でのみマウス モードを使用する WebView コントロールを持つページや、他のすべての場所で XY フォーカス ナビゲーションを行うことができます。 ポインターを要求するには、コントロールまたはページ エンゲージする場合 ページにフォーカスがある場合 するかどうかを指定できます。

Xbox One で実行されている XAML アプリとホスト型 Web アプリの両方で、アプリ全体に対してマウス モードが既定で有効になっています。 これをオフにし、XY ナビゲーション用にアプリを最適化することを強くお勧めします。 これを行うには、 Application.RequiresPointerMode プロパティを WhenRequested に設定して、コントロールまたはページが呼び出すときにのみマウス モードを有効にします。

XAML アプリでこれを行うには、 App クラスで次のコードを使用します。

public App()
{
    this.InitializeComponent();
    this.RequiresPointerMode =
        Windows.UI.Xaml.ApplicationRequiresPointerMode.WhenRequested;
    this.Suspending += OnSuspending;
}

HTML/JavaScript のサンプル コードを含む詳細については、「 マウス モードを無効にする方法を参照してください。

次の図は、マウス モードでのゲームパッド/リモートのボタン マッピングを示しています。

コントロールまたはページの RequiresPointer プロパティを使用して、マウス モードをアクティブにします。 このプロパティには、 Never (既定値)、 WhenEngaged、 WhenFocusedの 3 つの値があります。

コントロールでのマウス モードのアクティブ化

ユーザーが RequiresPointer="WhenEngaged"を使用してコントロールを操作すると、ユーザーがコントロールを外すまで、コントロールでマウス モードがアクティブになります。 次のコード スニペットは、マウス モードをアクティブ化する単純な MapControl を示しています。

<Page>
    <Grid>
        <MapControl IsEngagementRequired="true"
                    RequiresPointer="WhenEngaged"/>
    </Grid>
</Page>

コントロールがマウス モードの場合、入れ子になったコントロールもマウス モードになります。 子の要求モードは無視されます。親をマウス モードにし、子はマウス モードにしないということはできません。

さらに、コントロールの要求されたモードはフォーカスを取得したときにのみ検査されるため、フォーカスがある間モードは動的に変更されません。

ページでのマウス モードのアクティブ化

ページにプロパティ RequiresPointer="WhenFocused"がある場合、フォーカスが取得されると、ページ全体に対してマウス モードがアクティブになります。 次のコード スニペットは、ページにこのプロパティを指定する方法を示しています。

<Page RequiresPointer="WhenFocused">
    ...
</Page>

全画面表示コンテンツのマウス モードを無効にする

通常、ビデオやその他の種類のコンテンツを全画面表示で表示する場合は、カーソルがユーザーの注意を妨ける可能性があるため、カーソルを非表示にする必要があります。 このシナリオは、アプリの残りの部分でマウス モードを使用しているが、全画面表示コンテンツを表示するときに無効にする場合に発生します。 これを実現するには、全画面表示コンテンツを独自の Pageに配置し、次の手順に従います。

1. App オブジェクトで、RequiresPointerMode="WhenRequested"を設定します。
2. 全画面表示PageのすべてのPageオブジェクト exceptで、RequiresPointer="WhenFocused"を設定します。
3. 全画面表示の Pageでは、 RequiresPointer="Never"を設定します。

この方法では、全画面表示のコンテンツを表示するときにカーソルが表示されることはありません。

フォーカスビジュアル

フォーカス ビジュアルは、現在フォーカスがある UI 要素の周囲の境界線です。 これにより、ユーザーが迷子にならずに UI を簡単に移動できるように、ユーザーの方向を設定できます。

ビジュアルの更新と、フォーカス ビジュアルに多数のカスタマイズ オプションが追加されたので、開発者は、1 つのフォーカス ビジュアルが PC や Xbox One だけでなく、キーボードやゲームパッド/リモートをサポートするその他の Windows デバイスでも適切に動作することを信頼できます。

同じフォーカス ビジュアルを異なるプラットフォームで使用できますが、ユーザーが見いだすコンテキストは、10 フィート エクスペリエンスでは若干異なります。 ユーザーがテレビ画面全体に十分な注意を払っていないと想定する必要があります。したがって、ビジュアルを検索するフラストレーションを回避するために、現在フォーカスされている要素が常にユーザーに明確に表示されていることが重要です。

また、ゲームパッドまたはリモート コントロールを使用する場合はフォーカス ビジュアルが既定で表示されますが、キーボード 表示されない 点にも注意してください。 したがって、実装していない場合でも、Xbox One でアプリを実行すると表示されます。

最初のフォーカスの視覚配置

アプリを起動するとき、またはページに移動するときは、ユーザーがアクションを実行する最初の要素として理にかなっている UI 要素にフォーカスを置きます。 たとえば、写真アプリはギャラリー内の最初の項目にフォーカスを置き、曲の詳細ビューに移動した音楽アプリは、音楽の再生を容易にするために再生ボタンにフォーカスを置く場合があります。

アプリの左上の領域 (または右から左へのフローの場合は右上) に初期フォーカスを設定してみてください。 ほとんどのユーザーは、アプリコンテンツフローが一般的に開始されるため、まずそのコーナーに集中する傾向があります。

フォーカスを明確に表示する

ユーザーがフォーカスを検索せずに中断した場所を選択できるように、常に 1 つのフォーカス ビジュアルを画面に表示する必要があります。 同様に、フォーカス可能な項目が常に画面上に存在する必要があります。たとえば、フォーカス可能な要素がない、テキストのみのポップアップを使わないでください。

このルールの例外は、ビデオの視聴や画像の表示などの全画面表示のエクスペリエンスの場合です。その場合、フォーカスの視覚効果を表示することは適切ではありません。

表示フォーカス

表示フォーカスは、ユーザーがゲームパッドやキーボード フォーカスを移動したときに、ボタンなどのフォーカス可能な要素の境界線をアニメーション化する照明効果です。 フォーカスのある要素の境界線の周りの光彩をアニメーション化することで、フォーカスがどこにあり、どこにフォーカスが向いているかをユーザーがよりよく理解できるようになります。

表示フォーカスは既定ではオフになっています。 10 フィート エクスペリエンスでは、アプリ コンストラクターで Application.FocusVisualKind プロパティ を設定してフォーカスを表示するようにオプトインする必要があります。

    if(AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Xbox")
    {
        this.FocusVisualKind = FocusVisualKind.Reveal;
    }

詳細については、 Reveal focus のガイダンスを参照してください。

フォーカス ビジュアルのカスタマイズ

フォーカス ビジュアルをカスタマイズする場合は、各コントロールのフォーカス ビジュアルに関連するプロパティを変更します。 アプリをカスタマイズするために利用できるプロパティがいくつかあります。

表示状態を使用して独自に描画することで、システム提供のフォーカス ビジュアルをオプトアウトすることもできます。 詳細については、 VisualState を参照してください。

ライト 閉じるオーバーレイ

ユーザーがゲーム コントローラーまたはリモコンで現在操作している UI 要素にユーザーの注意を促すために、UWP では、アプリが Xbox One で実行されているときに、ポップアップ UI 以外の領域をカバーする "スモーク" レイヤーが自動的に追加されます。 これには追加の作業は必要ありませんが、UI を設計する際には注意が必要です。 任意のFlyoutBaseで LightDismissOverlayMode プロパティを設定して、スモーク レイヤーを有効または無効にすることができます。既定では Auto に設定されます。これは、Xbox で有効になっており、他の場所で無効になっていることを意味します。 詳細については、「 Modal と light dismissを参照してください。

フォーカス エンゲージメント

フォーカス エンゲージメントは、ゲームパッドやリモートを使用してアプリを操作しやすくするためのものです。

FrameworkElement オブジェクトのプロパティIsFocusEngagementEnabledがTrueに設定されている場合、コントロールはフォーカス の関与を必要とするようにマークされます。 つまり、ユーザーは A/Select ボタンを押して、コントロールを "エンゲージ" して操作する必要があります。 完了したら、 B/戻る ボタンを押してコントロールを解除し、コントロールから移動できます。

フォーカス トラッピング

フォーカス トラップは、ユーザーがアプリの UI 内を移動しようとしたが、コントロール内で "トラップ" され、そのコントロールの外に移動するのが困難または不可能になった場合に発生します。

次の例は、フォーカス トラップを作成する UI を示しています。

ユーザーが左側のボタンから右ボタンに移動する場合は、D パッド/左スティックを 2 回右に押す必要があると仮定するのが論理的です。 ただし、 Slider がエンゲージメントを必要としない場合、次の動作が発生します。ユーザーが最初に右に押すと、フォーカスが Sliderに移動し、再び右に押すと、 Sliderのハンドルが右に移動します。 ユーザーはハンドルを右に移動し続け、ボタンにアクセスできなくなります。

この問題を回避するには、いくつかの方法があります。 1 つは、XY フォーカス ナビゲーションと相互作用の不動産アプリの例と同様に、別のレイアウトを設計することです。ここでListViewの上に Previous と Next ボタンを再配置しました。 次の図のように、コントロールを水平方向ではなく垂直方向に積み重ねると、問題が解決します。

これで、ユーザーは D パッド/左スティックを上下に押して各コントロールに移動できるようになりました。 Slider にフォーカスがある場合は、左と右を押して、 Slider ハンドルを想定どおりに移動できます。

この問題を解決するためのもう 1 つのアプローチは、 Sliderへの関与を要求することです。 IsFocusEngagementEnabled="True"設定すると、次の動作が発生します。

Sliderがフォーカス エンゲージメントを必要とする場合、ユーザーは D パッド/左スティックを 2 回右に押すだけで、右側のボタンに移動できます。 このソリューションは、UI の調整を必要とせず、予期される動作を生成するため、優れたソリューションです。

アイテム コントロール

Slider コントロールとは別に、次のようなエンゲージメントを必要とする可能性があるその他のコントロールがあります。

• ListBox
• ListView
• GridView
• FlipView

Slider コントロールとは異なり、これらのコントロールは自身の中にフォーカスをトラップしません。ただし、大量のデータが含まれていると、使いやすさの問題が発生する可能性があります。 大量のデータを含む ListView の例を次に示します。

Sliderの例と同様に、ゲームパッド/リモートを使用して、上部にあるボタンから下部にあるボタンに移動してみましょう。 上部ボタンのフォーカスから始めて、D パッド/スティックを下に押すと、 ListView の最初の項目 ("Item 1") にフォーカスが移動します。 ユーザーがもう一度下に押すと、一覧の次の項目は、下部のボタンではなくフォーカスを取得します。 ボタンに移動するには、ユーザーが最初に ListView 内のすべての項目間を移動する必要があります。 ListViewに大量のデータが含まれている場合、これは不便であり、最適なユーザー エクスペリエンスではない可能性があります。

この問題を解決するには、ListViewのプロパティ IsFocusEngagementEnabled="True"を設定して、それにエンゲージメントを要求します。 これにより、ユーザーは下に押すだけで、 ListView をすばやくスキップできます。 ただし、フォーカスがあるときに A/Select ボタンを押し、 B/戻る ボタンを押して操作を解除しない限り、リストをスクロールしたり、リストから項目を選択したりすることはできません。

ScrollViewer

これらのコントロールとは少し異なるのは、考慮すべき独自の風変わりな ScrollViewerです。 フォーカス可能なコンテンツを含む ScrollViewer がある場合、既定で ScrollViewer に移動すると、フォーカス可能な要素間を移動できます。 ListViewと同様に、各項目をスクロールしてScrollViewerの外部を移動する必要があります。

ScrollViewer にフォーカス可能なコンテンツが "ない" 場合は (テキストのみが含まれる場合など)、ユーザーが A/[選択] ボタンを使って ScrollViewer にエンゲージメントを設定できるように、IsFocusEngagementEnabled="True" を設定できます。 エンゲージした後は、D パッド/左スティックを使用してテキストをスクロールしB/戻る ボタンを押して、完了したら終了します。

別の方法として、ユーザーがコントロールにエンゲージメントを設定しなくてすむように ScrollViewer で IsTabStop="True" を設定します。ScrollViewer 内にフォーカス可能な要素がない場合、D パッド/左スティックを使って、単にフォーカスしてからスクロールできます。

フォーカス エンゲージメントの既定値

一部のコントロールでは、既定の設定でフォーカス エンゲージメントを要求するのに十分なフォーカス トラップが一般的に発生しますが、フォーカス エンゲージメントが既定でオフになっているコントロールもありますが、オンにするとメリットがあります。 次の表に、これらのコントロールとその既定のフォーカス エンゲージメント動作を示します。

コントロール	フォーカス エンゲージメントの既定値
CalendarDatePicker	オン
FlipView	"オフ"
GridView	"オフ"
ListBox	"オフ"
ListView	"オフ"
ScrollViewer	"オフ"
SemanticZoom	"オフ"
Slider	オン

他のすべての Windows コントロールでは、IsFocusEngagementEnabled="True" のときに、動作の変更や視覚的な変更はありません。

まとめ

特定のデバイスやエクスペリエンスに最適化された Windows アプリケーションを構築できますが、ユニバーサル Windows プラットフォームを使用すると、入力デバイスやユーザーの能力に関係なく、2 フィート エクスペリエンスと 10 フィート エクスペリエンスの両方で、どのデバイスでも問題なく使用できるアプリを構築することもできます。 この記事の推奨事項を使用すると、テレビと PC のどちらにおいても優れたアプリにすることができます。

関連記事

• Xbox およびテレビ向け設計
• Windows アプリ用のデバイスの基本情報