遊戲手把與遙控器的互動

許多互動體驗在手把、遙控器和鍵盤之間共享

在 Windows 應用程式中建立互動體驗，確保你的應用程式能透過傳統的 PC、筆電和平板（滑鼠、鍵盤、觸控等）輸入方式，以及電視和 Xbox 10 英尺 常見的輸入方式（如手把和遙控器）都能使用且易於使用。

請參閱 Xbox 與電視設計 ，了解 Windows 應用程式在 10 英尺 體驗中的一般設計指引。

概觀

在本主題中，我們將討論你在互動設計中應該考慮的事項（或如果平台會幫你處理，你不該考慮的事項），並提供指引、建議與建議，幫助你打造無論裝置、輸入類型或使用者能力與偏好如何，都能愉快使用起來的 Windows 應用程式。

總之，你的應用程式在 2英尺 環境下應該和 10英尺 環境一樣直覺且易於使用（反之亦然）。 支援使用者偏好的裝置，讓使用者介面焦點清晰且明確，安排內容使導覽一致且可預測，並提供使用者最短的路徑達到他們想做的事。

同時優化 2 英尺與 10 英尺的體驗

至少，我們建議你測試你的應用程式，確保它們在 2 英尺和 10 英尺的情境下都能正常運作，並且所有功能都能被 Xbox 手把和遙控器發現並存取。

以下是一些其他方法，可以讓你的應用程式同時適用於 2 英尺和 10 英尺的體驗，以及所有輸入裝置（每個都連結到本主題中對應的章節）。

遊戲手把與遙控器

就像鍵盤和滑鼠是 PC 用的，觸控是手機和平板用的，遊戲手把和遙控器是 10 英尺體驗的主要輸入裝置。 本節介紹硬體按鈕是什麼以及它們的功能。 在 XY 專注導航與互動 以及 滑鼠模式中，你將學會如何優化使用這些輸入裝置時的應用程式。

您在未經自訂設置的情況下所得到的遊戲手把與遠端操控行為的品質，取決於您應用程式中對鍵盤支援的程度。 確保你的應用程式能在 PC 上與鍵盤搭配良好運作的好方法，是先確認它能在 PC 上與鍵盤相容，然後用手把或遙控器測試，找出介面上的弱點。

硬體按鈕

在本文中，按鈕將以下圖所示名稱來稱呼。

如圖所示，有些按鍵在手把上支援，遙控器不支援，反之亦然。 雖然你可以使用只支援單一輸入裝置的按鈕來加快介面操作速度，但要注意，若用於關鍵互動，可能會讓使用者無法與某些介面部分互動。

下表列出 Windows 應用程式支援的所有硬體按鈕，以及支援這些按鈕的輸入裝置。

內建按鈕支援

UWP 會自動將現有鍵盤輸入行為映射到手把和遙控器輸入。 下表列出這些內建映射。

*當 App 無法處理 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。

加速器支援

加速按鈕是用來加快使用者介面導航速度的按鈕。 不過，這些按鈕可能只限於特定輸入裝置，因此請注意並非所有使用者都能使用這些功能。 事實上，目前遊戲手把是唯一支援 Xbox One 上 Windows 應用程式加速功能的輸入裝置。

下表列出了 UWP 內建的加速器支援，以及你可以自行實作的部分。 在自訂使用者介面中運用這些行為，提供一致且友善的使用者體驗。

XY 焦點導航與互動

如果你的應用程式支援鍵盤的焦點導航，這將能很好地應用於控制器和遙控器上。 方向鍵的導航對應到 方向鍵 （以及手把上的 左搖桿 ），與 UI 元素的互動則對應在 Enter/Select 鍵（參見 手把與遙控器）。

許多事件和屬性被鍵盤和手把共用——它們都會觸發KeyDown和KeyUp事件，而且只會導向具有IsTabStop="True"和Visibility="Visible"屬性的控制項。 關於鍵盤設計指引，請參見 鍵盤互動。

如果鍵盤支援能妥善實作，你的應用程式會相當順利地運作;不過，可能需要額外工作來支援每個情境。 思考你的應用程式具體需求，以提供最佳使用者體驗。

除錯焦點問題

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 導航可能無法如你預期運作，有三個常見原因：

• IsTabStop 或 Visibility 屬性設定錯誤。
• 控制鍵的焦點其實比你想像的還要大——XY 導航會看控制器的總大小（實際寬度 和 實際高度），而不只是控制中讓某些東西變得有趣的部分。
• 一個可對焦的控制鍵疊加在另一個上方——XY 導航不支援重疊的控制。

如果修正這些問題後 XY 導航仍不如預期，你可以手動指向你想要聚焦的元素，使用 覆寫預設導航中描述的方法。

如果 XY 導航正常運作但沒有顯示對焦視覺，以下其中一個問題可能是原因：

• 你重新設計了控制項模板，但沒有包含焦點指示視覺效果。 手動設定 UseSystemFocusVisuals="True" 或新增視覺焦點。
• 你透過呼叫 Focus(FocusState.Pointer)轉移焦點。 FocusState 參數控制焦點視覺的變化。 一般來說，你應該把這個設定設為 FocusState.Programmatic，這樣如果焦點之前可見，就能保持視覺可見;如果之前隱藏過，則是隱藏。

本節其餘部分將詳細說明使用 XY 導航時常見的設計挑戰，並提供多種解決方法。

無法存取的使用者介面

由於 XY 焦點導航限制使用者只能上下左右移動，可能會遇到介面部分無法存取的情況。 以下圖示展示了 XY 焦點導航不支援的 UI 配置範例。 請注意，中間的元素無法用遊戲控制器或遙控器操作，因為垂直和水平的導覽會被優先處理，中間的元素永遠不會被賦予足夠的焦點優先順序。

如果因某些原因無法重新排列介面，請使用下一節討論的技術來覆蓋預設的焦點行為。

覆寫預設導航

雖然通用 Windows 平台試圖確保方向鍵/左搖桿的操作對使用者來說是合理的，但它無法保證行為會根據你的應用程式的意圖進行最佳化。 確保導航為你的應用程式優化的最佳方式，是用遊戲手把測試，確認每個使用者都能以符合應用情境的方式存取每個 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 二，使用者向右移動，最佳焦點候選是 Button 四;然而，焦點會被移至 Button 三，因為 UserControl 父節點會在它離開視覺樹時強制它移動到三。

最少點擊路徑

盡量讓使用者能在最少點擊次數內完成最常見的任務。 在以下範例中， TextBlock 被放置在 播放 鍵（最初會被聚焦）與常用元素之間，以便在優先任務之間放置不必要的元素。

以下範例中， TextBlock 被放置在 播放 按鈕上方。 只要重新排列介面，避免在優先任務之間放置不必要的元素，就能大幅提升應用程式的可用性。

命令列與環境快捷選單

使用 指令列時，請記得在長 捲動列表/網格後出現的問題：UI 元素問題中提到的問題。 下圖顯示了 UI 佈局，其中 CommandBar 位於清單/格子的底部。 使用者必須一路往下滑到清單/網格，才能找到 CommandBar。

如果你把CommandBar的表格放到清單/格子裡呢？ 當使用者往下滑清單或網格時，必須往上捲回才能找到CommandBar，但這樣的導航操作比之前的配置稍微少一些。 請注意，這是假設你的應用程式初始焦點放在 CommandBar;如果初始焦點在列表/網格下方，這種方法就不太適用。 如果這些 CommandBar 項目是全域動作項目，不需要經常存取（例如 同步 按鈕），那麼將它們放在清單或格子上方可能還可以接受。

雖然你無法將CommandBar的物品垂直堆疊，但如果這對你的 UI 佈局有效，你可以考慮將其放置在與捲動方向相反的位置（例如，放在垂直捲動列表的左邊或右邊，或橫向捲動列表的頂部或底部）。

如果你的應用程式有具有需要使用者隨時存取的項目 CommandBar，你可以考慮將這些項目放入 ContextFlyout，並從 CommandBar 中移除。 ContextFlyout 是 UIElement 的一個屬性，並且是與該元素相關的 上下文選單 。 在 PC 上，當你右鍵點擊元素 ContextFlyout 時，那個右鍵選單會跳出來。 在 Xbox One 上，當你的焦點已放在該元素上並按下 選單 鍵時，這種情況會發生。

使用者介面佈局挑戰

由於 XY 焦點導航的特性，有些 UI 佈局更具挑戰性，應逐案評估。 雖然沒有唯一的「正確」方式，選擇哪種方案取決於應用程式的具體需求，但你可以運用一些技巧來打造出色的電視體驗。

為了更好地理解這點，讓我們來看看一個想像中的應用程式，說明這些問題以及克服它們的技巧。

以下是一個虛構的房地產應用程式，會顯示待售房屋清單、地圖、房產描述及其他資訊。 這款應用程式帶來三個挑戰，你可以透過以下技巧克服：

• 使用者介面重新排列
• 專注互動
• 滑鼠模式

問題：UI 元素在長時間滾動的清單/格子後才出現

下圖所示的 ListView 是一個非常長的捲動清單。 如果在ListView不需要參與，當使用者導航到清單時，焦點會放在清單中的第一個項目。 使用者若要進入 「上一 頁」或 「下一 頁」按鈕，必須逐一瀏覽清單中的所有項目。 在這種情況下，如果使用者必須瀏覽整個清單而感到痛苦——也就是說，清單太長使得此體驗令人難以接受——你可能需要考慮其他選項。

Solutions

使用者介面重新排列

除非你最初的重點放在頁面底部，否則放在長長滾動清單上方的 UI 元素通常比放在下方更容易存取。 如果這種新版面能適用於其他裝置，改變所有裝置系列的版面配置，而不是只為 Xbox One 做特別的介面調整，可能會是成本較低的做法。 此外，將 UI 元素放置在與捲動方向相反的位置（例如，將元素橫向放置在垂直捲動的列表中，或垂直放置在橫向捲動的列表中），將會提升無障礙性。

專注互動

當 需要交戰時，整體 ListView 成為單一焦點。 使用者可以跳過清單內容，直接進入下一個可聚焦的元素。 閱讀更多關於支持參與的控制措施，以及如何在 Focus 參與中運用它們。

問題：ScrollViewer 中沒有任何可聚焦的元素

由於 XY 焦點導航依賴一次只瀏覽一個可聚焦的 UI 元素，若 ScrollViewer 不包含任何可聚焦元素（例如僅有文字的範例），可能會導致使用者無法完整瀏覽所有內容 ScrollViewer。 關於此及其他相關情境的解決方案，請參見 「聚焦參與」。

問題：自由捲動的介面

當你的應用程式需要自由捲動的使用者介面，例如繪圖表面或像這個例子中的地圖時，XY 焦點導航根本無法運作。 在這種情況下，你可以開啟 滑鼠模式 ，讓使用者能自由地在 UI 元素中移動。

滑鼠模式

如 XY 焦點導航與互動中所述，Xbox One 使用 XY 導航系統進行焦點切換，使用者可透過上下左右移動來將焦點從一個控制轉移到另一個控制。 然而，有些控制項，如 WebView 和 MapControl，需要類似滑鼠的互動，使用者可以自由移動指標在控制項的邊界內。 有些應用程式很適合讓使用者能在整個頁面上移動指標，提供用手把或遙控器操作時類似於電腦上使用滑鼠的體驗。

對於這些情況，你應該請求一個指標（滑鼠模式）來覆蓋整個頁面，或是頁面內的控制項。 舉例來說，你的應用程式可以有一個頁面，在 WebView 控制項內只使用滑鼠操作模式，而其餘地方則使用 XY 焦點導覽。 要請求指標，你可以指定是在 控制項或頁面啟用 時使用，還是頁面 有焦點時使用。

對於在 Xbox One 上運行的 XAML 和託管網頁應用程式，整個應用程式預設都會開啟滑鼠模式。 強烈建議你關閉這個功能，並優化你的應用程式以符合 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。

啟動控制器上的滑鼠模式

當使用者按下控制 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物件中，都設為 RequiresPointer="WhenFocused"。
3. 全螢幕 Page時，設定 RequiresPointer="Never"為 。

這樣一來，游標在顯示全螢幕內容時就不會出現。

視覺焦點

焦點視覺化是指目前聚焦的 UI 元素周圍的邊框。 這有助於使用者調整方向，讓他們能輕鬆瀏覽使用者介面而不迷路。

透過視覺更新及新增多種專注視覺自訂選項，開發者可以放心，單一專注視覺效果能在 PC 和 Xbox One 以及其他支援鍵盤和/或手把/遙控器的 Windows 裝置上運作良好。

雖然相同的焦點視覺可以在不同平台上使用，但使用者在 10 英尺的體驗中遇到的情境略有不同。 你應該假設使用者並未完全專注於整個電視螢幕，因此必須讓目前聚焦的元素始終清晰可見，以避免尋找視覺效果時的挫折感。

同時也要注意，使用手把或遙控器時預設會顯示對焦視覺，但 鍵盤則不會 。 因此，即使你沒有實作，當你在 Xbox One 上執行應用程式時，它仍會顯示出來。

初始對焦視覺位置

啟動應用程式或瀏覽頁面時，將焦點放在使用者第一個會採取行動的 UI 元素上。 例如，照片應用程式可能會將焦點放在相簿中的第一個項目上，而音樂應用程式若能瀏覽到歌曲的詳細視圖，可能會將焦點放在播放按鈕上，方便播放音樂。

試著將初始焦點放在應用程式的左上角區域（或針對從右到左閱讀順序的介面，將焦點放在右上角）。 大多數用戶傾向先專注於那個角落，因為應用程式內容通常從那裡開始。

讓焦點清晰可見

螢幕上應該始終可見一個焦點視覺，讓使用者可以從中斷的地方繼續，而不必尋找焦點。 同樣地，螢幕上應該隨時都有可聚焦的項目——例如，不要使用只有文字、沒有可聚焦元素的彈出視窗。

此規則的例外情況是全螢幕體驗，如觀看影片或查看圖片，此時不宜顯示焦點指示。

顯示焦點

顯示焦點是一種光影效果，當使用者將遊戲手把或鍵盤焦點移動到可聚焦元素（如按鈕）時，會自動呈現出可聚焦元素的邊界。 透過在聚焦元素邊界周圍動畫化發光，Reveal 焦點讓使用者更清楚焦點所在與焦點的方向。

預設顯示焦點為關閉狀態。 對於 10 英尺的體驗，你應該選擇在應用程式建構器中設定 Application.FocusVisualKind 屬性 來顯示焦點。

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

更多資訊請參閱揭露焦點的指南。

自訂焦點視覺

如果你想自訂焦點視覺化，可以透過修改每個控制項與焦點視覺相關的屬性來達成。 有幾個這樣的屬性可以用來個人化你的應用程式。

你甚至可以選擇不使用系統提供的焦點視覺，透過使用視覺狀態自行繪製。 欲了解更多，請參閱 VisualState。

光線解散覆蓋

為了提醒使用者注意他們目前正在用遊戲控制器或遙控器操作的 UI 元素，UWP 會在應用程式在 Xbox One 上運行時，自動新增一個「煙霧」層，覆蓋彈出視窗外的區域。 這不需要額外工作，但設計介面時要注意。 你可以在任何LightDismissOverlayModeFlyoutBase設定上啟用或停用煙霧層;預設是 Auto，表示 Xbox 上是啟用，其他地方則是關閉。 更多資訊請參見 模態與輕解散。

專注參與

聚焦互動旨在讓使用遊戲手把或遙控器更容易與應用程式交互。

當 IsFocusEngagementEnabled 物件上的屬性設定為 True時，該控制項標記為需要焦點參與。 這表示使用者必須按下 A/Select 按鈕才能「啟動」控制鍵並與之互動。 完成操作後，他們可以按下 B/Back 鍵來解除控制並離開。

焦點陷阱

焦點陷阱是指使用者嘗試在應用程式的介面中導航，卻被「困住」在某個控制區，導致難以甚至無法離開該控制範圍。

以下範例展示了產生焦點捕捉的介面。

如果使用者想從左鍵切換到右鍵，合理推測他們只要在方向鍵/左搖桿上按兩次右鍵即可。 然而，如果滑動條不需要啟動，會發生以下行為：使用者第一次向右按時，焦點會移到Slider，當再次按下右方向鍵時，Slider的握把會向右移動。 使用者會一直往右移動把手，卻無法觸及按鈕。

有幾種方法可以解決這個問題。 一種方法是設計不同的版面配置，類似 於 XY 專注導航與互動 中的不動產應用程式範例，其中我們將 「上一頁」 和 「下一頁」 按鈕移至 ListView 之上。 將控制鍵垂直堆疊，而非如下圖所示的水平排列，可以解決這個問題。

現在使用者可以透過在方向鍵/左搖桿上按上下來切換每個控制鍵，當 Slider 對焦完成後，可以按左和右來移動 Slider 把手，這是預期的。

另一種解決此問題的方法是要求在 Slider 上進行互動。 如果你設定 IsFocusEngagementEnabled="True"，則會出現以下行為。

當需要 Slider 鎖定焦點時，使用者只需在方向鍵或左搖桿上向右按兩次即可到達右側按鈕。 這個解決方案很棒，因為它不需要介面調整，能產生預期的行為。

項目控制項

除了 Slider 控制項之外，還有其他控制項可能需要互動，例如：

• 名單盒
• ListView
• GridView
• 翻頁檢視

與 Slider 控件不同，這些控件不會把焦點設置於內部，但是當它們包含大量資料時，可能會導致可用性問題。 以下是一個包含大量資料的例子 ListView 。

類似於範例 Slider，我們試著用控制器從上方按鈕移動到下方按鈕。 從對焦按鈕開始，按下方向鍵/搖桿會將焦點放在第一個項目（ ListView 「項目1」）上。 當使用者再次按下去時，列表中的下一個項目會被聚焦，而不是底部的按鈕。 要找到按鈕，使用者必須瀏覽第一個按鈕 ListView 中的每一項。 如果 裡面 ListView 有大量資料，這可能會造成不便，也不是最佳的使用者體驗。

為了解決這個問題，將屬性設定 IsFocusEngagementEnabled="True" 為 ListView 要求對其進行參與。 這樣使用者就能透過簡單按下來快速跳過ListView。 不過，他們無法在清單中捲動或選擇項目，除非先在對焦狀態下按下 A/Select 鍵來啟動，然後再按 B/Back 鍵來解除。

滾動查看器

與這些控制稍有不同的是 ScrollViewer，它有自己的小特色需要考慮。 如果你有 ScrollViewer 可聚焦的內容，預設情況下， ScrollViewer 導航會讓你瀏覽其可聚焦的元素。 就像在ListView中，你必須逐個捲動每個項目才能在ScrollViewer外進行導航。

如果 ScrollViewer 沒有可聚焦的內容，例如只有文字，您可以設定IsFocusEngagementEnabled="True"，讓使用者透過 A/Select 按鈕來啟動 ScrollViewer。 交戰後，他們可以用 方向鍵/左搖桿滑動文字，完成後按 B/Back 鍵解除。

另一種方法是設定IsTabStop="True"在ScrollViewer上，讓使用者不必啟動控制鍵，只要將焦點放在其上，當ScrollViewer中沒有可聚焦元素時，然後即可用方向鍵或左搖桿滾動。

專注互動預設值

有些控制項會頻繁造成對焦陷阱，預設設定必須啟用對焦，而有些則預設關閉，但開啟後會受益。 下表列出這些控制項及其預設的焦點互動行為。

所有其他 Windows 控制項在 IsFocusEngagementEnabled="True" 時，行為或視覺上都不會有任何改變。

總結

你可以為特定裝置或體驗優化設計 Windows 應用程式，但通用 Windows 平台也讓你能打造可跨裝置成功運行的應用程式，不論是在兩英尺或十英尺可接觸距離的情境中，且不論輸入裝置或使用者能力如何。 使用本文的建議，可以確保你的應用程式在電視和電腦上都能達到最佳狀態。

相關文章

• 針對 Xbox 和電視進行設計
• Windows 應用程式的裝置入門指南