게임 패드 및 원격 제어 상호 작용

키보드 및 게임 패드 이미지

게임 패드, 원격 제어 및 키보드 간에 많은 상호 작용 환경이 공유됩니다.

기존의 PC, 노트북 및 태블릿(마우스, 키보드, 터치 등)의 전통적인 입력 유형뿐만 아니라 게임 패드 및 리모컨과 같은 TV 및 Xbox 10피트 경험의 일반적인 입력 유형을 통해 앱을 사용하고 접근할 수 있도록 Windows 애플리케이션에서 상호작용 환경을 구축하세요.

10피트 환경의 Windows 애플리케이션에 대한 일반적인 디자인 지침은 Xbox 및 TV용 디자인을 참조하세요.

개요

이 항목에서는 상호 작용 디자인에서 고려해야 할 사항(또는 플랫폼이 사용자를 돌보는 경우 그렇지 않은 것)에 대해 설명하고 디바이스, 입력 유형 또는 사용자 기능 및 기본 설정에 관계없이 사용하기에 즐거운 Windows 애플리케이션을 빌드하기 위한 지침, 권장 사항 및 제안을 제공합니다.

결론적으로, 애플리케이션은 10피트 환경과 마찬가지로 2피트 환경에서 직관적이고 쉽게 사용할 수 있어야 합니다(그 반대의 경우도 마찬가지임). 사용자가 선호하는 디바이스를 지원하고, UI 포커스를 명확하고 명확하게 만들고, 탐색이 일관되고 예측 가능하도록 콘텐츠를 정렬하고, 사용자에게 원하는 작업에 가능한 가장 짧은 경로를 제공합니다.

비고

이 항목의 코드 조각은 대부분 XAML/C#에 있습니다. 그러나 원칙과 개념은 모든 Windows 앱에 적용됩니다. Xbox용 HTML/JavaScript Windows 앱을 개발하는 경우 GitHub에서 우수한 TVHelpers 라이브러리를 확인하세요.

2피트 및 10피트 환경 모두에 최적화

최소한 애플리케이션을 테스트하여 2피트 및 10피트 시나리오 모두에서 제대로 작동하는지 확인하고 모든 기능을 Xbox 게임 패드 및 원격 제어에서 검색하고 액세스할 수 있도록 하는 것이 좋습니다.

다음은 2피트 및 10피트 환경과 모든 입력 디바이스(이 항목의 적절한 섹션에 대한 각 링크)에서 사용할 수 있도록 앱을 최적화할 수 있는 몇 가지 다른 방법입니다.

비고

Xbox 게임 패드 및 원격 컨트롤은 많은 Windows 키보드 동작과 환경을 지원하므로 이러한 권장 사항은 두 입력 유형 모두에 적합합니다. 자세한 키보드 정보는 키보드 상호 작용 을 참조하세요.

특징	Description
XY 포커스 탐색 및 상호 작용	XY 포커스 탐색 을 사용하면 사용자가 앱의 UI를 탐색할 수 있습니다. 그러나 이렇게 하면 사용자가 위쪽, 아래쪽, 왼쪽 및 오른쪽으로만 탐색할 수 있습니다. 이 문제 및 기타 고려 사항을 처리하기 위한 권장 사항은 이 섹션에 설명되어 있습니다.
마우스 모드	맵 또는 그리기 및 그리기 앱과 같은 일부 유형의 애플리케이션에서는 XY 포커스 탐색이 실용적이지 않거나 가능하지도 않습니다. 이러한 경우 마우스 모드 를 사용하면 사용자가 PC의 마우스처럼 게임 패드 또는 리모컨으로 자유롭게 탐색할 수 있습니다.
포커스 시각 요소	포커스 시각적 개체는 현재 포커스가 있는 UI 요소를 강조 표시하는 테두리입니다. 이렇게 하면 사용자가 탐색하거나 상호 작용하는 UI를 빠르게 식별할 수 있습니다.
집중 참여	포커스 참여를 사용하려면 사용자가 UI 요소와 상호 작용하기 위해 포커스가 있을 때 게임 패드 또는 리모컨에서 A/Select 단추를 눌러야 합니다.
하드웨어 단추	게임 패드 및 리모컨은 매우 다른 단추와 구성을 제공합니다.

게임 패드 및 원격 제어

키보드와 마우스가 PC용인 것처럼 터치는 휴대폰과 태블릿용이고, 게임 패드와 리모컨은 10피트 환경의 주요 입력 장치입니다. 이 섹션에서는 하드웨어 단추의 기능과 수행하는 작업을 소개합니다. XY 포커스 탐색 및 상호 작용 및 마우스 모드에서는 이러한 입력 디바이스를 사용할 때 앱을 최적화하는 방법을 알아봅니다.

바로 사용할 수 있는 게임 패드 및 원격 동작의 품질은 앱에서 키보드가 얼마나 잘 지원되는지에 따라 달라집니다. 앱이 게임 패드/리모컨과 잘 작동하도록 하는 좋은 방법은 PC에서 키보드와 잘 작동하는지 확인한 다음 게임 패드/원격으로 테스트하여 UI에서 약점을 찾는 것입니다.

하드웨어 단추

이 문서 전체에서 단추는 다음 다이어그램에 제공된 이름으로 참조됩니다.

게임 패드 및 원격 단추 다이어그램

다이어그램에서 볼 수 있듯이, 원격 제어에서 지원되지 않는 게임 패드에서 지원되는 일부 단추가 있으며 그 반대의 경우도 마찬가지입니다. 하나의 입력 디바이스에서만 지원되는 단추를 사용하여 UI를 더 빠르게 탐색할 수 있지만 중요한 상호 작용에 단추를 사용하면 사용자가 UI의 특정 부분과 상호 작용할 수 없는 상황이 발생할 수 있습니다.

다음 표에서는 Windows 앱에서 지원하는 모든 하드웨어 단추와 이를 지원하는 입력 디바이스를 나열합니다.

단추	게임 패드	원격 조종
A/선택 단추	Yes	Yes
B/뒤로 버튼	Yes	Yes
방향 패드(D 패드)	Yes	Yes
메뉴 단추	Yes	Yes
보기 버튼	Yes	Yes
X 및 Y 단추	Yes	아니오
왼쪽 스틱	Yes	아니오
오른쪽 스틱	Yes	아니오
왼쪽 및 오른쪽 트리거	Yes	아니오
왼쪽 및 오른쪽 범퍼	Yes	아니오
OneGuide 단추	아니오	Yes
볼륨 단추	아니오	Yes
채널 단추	아니오	Yes
미디어 컨트롤 단추	아니오	Yes
음소거 단추	아니오	Yes

기본 제공 단추 지원

UWP는 기존 키보드 입력 동작을 게임 패드 및 원격 제어 입력에 자동으로 매핑합니다. 다음 표에서는 이러한 기본 제공 매핑을 나열합니다.

Keyboard	게임 패드/원격
화살표 키	D 패드(게임 패드에도 왼쪽 스틱)
스페이스바	A/선택 단추
입력하세요	A/선택 단추
탈출	B/뒤로 버튼*

*앱에서 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;
}

비고

B 단추를 사용하여 돌아가면 UI에 뒤로 단추를 표시하지 않습니다. 탐색 보기를 사용하는 경우 뒤로 단추가 자동으로 숨겨집니다. 뒤로 탐색에 대한 자세한 내용은 Windows 앱의 탐색 기록 및 뒤로 탐색을 참조하세요.

Xbox One의 Windows 앱은 메뉴 단추를 눌러 상황에 맞는 메뉴를 열 수도 있습니다. 자세한 내용은 CommandBar 및 ContextFlyout을 참조하세요.

액셀러레이터 지원

액셀러레이터 단추는 UI를 통해 탐색 속도를 높이기 위해 사용할 수 있는 단추입니다. 그러나 이러한 단추는 특정 입력 장치에 고유할 수 있으므로 모든 사용자가 이러한 함수를 사용할 수 있는 것은 아닙니다. 실제로 게임 패드는 현재 Xbox One에서 Windows 앱용 가속기 기능을 지원하는 유일한 입력 장치입니다.

다음 표에서는 UWP에 기본 제공되는 가속기 지원과 직접 구현할 수 있는 가속기를 나열합니다. 사용자 지정 UI에서 이러한 동작을 활용하여 일관되고 친숙한 사용자 환경을 제공합니다.

상호 작용	키보드/마우스	게임 패드	기본 제공 기능:	권장 대상:
페이지 위쪽/아래쪽	페이지 위쪽/아래쪽	왼쪽/오른쪽 트리거	CalendarView, ListBox, ListViewBase, ListView, `ScrollViewer`, Selector, LoopingSelector, ComboBox, FlipView	세로 스크롤을 지원하는 보기
페이지 왼쪽/오른쪽	None	왼쪽/오른쪽 범퍼	ListBox, ListViewBase, ListView, `ScrollViewer`, Selector, LoopingSelector, FlipView	가로 스크롤을 지원하는 보기
확대/축소	Ctrl +/-	왼쪽/오른쪽 트리거	None	`ScrollViewer`, 확대/축소를 지원하는 뷰
탐색 창 열기/닫기	None	보기	None	탐색 창
Search	None	Y 버튼	None	앱의 기본 검색 함수 바로 가기
상황에 맞는 메뉴 열기	그런 다음	메뉴 단추	ContextFlyout	상황에 맞는 메뉴

앱에서 키보드에 대한 적절한 포커스 탐색을 지원하는 경우 게임 패드 및 리모컨으로 잘 변환됩니다. 화살표 키를 사용한 탐색은 D 패드 (게임 패드의 왼쪽 스틱 )에 매핑되고 UI 요소와의 상호 작용은 Enter/Select 키( 게임 패드 및 원격 제어 참조)에 매핑됩니다.

많은 이벤트와 속성은 키보드와 게임 패드 모두에 의해 사용되며, 둘 다 KeyDown 및 KeyUp 이벤트를 발생시킵니다. 또한, 두 기기는 모두 속성 IsTabStop="True"와 Visibility="Visible"가 있는 컨트롤로만 탐색할 수 있습니다. 키보드 디자인 지침은 키보드 조작을 참조하세요.

키보드 지원이 제대로 구현되면 앱이 제대로 작동합니다. 그러나 모든 시나리오를 지원하는 데 몇 가지 추가 작업이 필요할 수 있습니다. 가능한 최상의 사용자 환경을 제공해야 하는 앱의 특정 요구 사항을 생각해 보세요.

중요합니다

마우스 모드는 Xbox One에서 실행되는 Windows 앱에 대해 기본적으로 사용하도록 설정됩니다. 마우스 모드를 사용하지 않도록 설정하고 XY 포커스 탐색을 사용하도록 설정하려면 .Application.RequiresPointerMode=WhenRequested

포커스 문제 디버깅

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 탐색은 컨트롤의 전체 크기(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 4입니다. 그러나 포커스는 시각적 트리 밖에 있을 때 부모가 UserControl 강제로 이동시켜 Button 3으로 이동됩니다.

최소 클릭 경로

사용자가 최소 클릭 수로 가장 일반적인 작업을 수행할 수 있도록 합니다. 다음 예제에서는 TextBlock 이 재생 버튼(처음에는 포커스를 받는)과 일반적으로 사용되는 요소 사이에 위치하여, 중요 요소 사이에 불필요한 요소가 배치됩니다.

탐색 모범 사례는 최소 클릭으로 경로를 제공합니다.

다음 예제에서는 TextBlock 이 대신 재생 단추 위에 배치됩니다. 우선 순위 작업 사이에 불필요한 요소가 배치되지 않도록 UI를 다시 정렬하면 앱의 유용성이 크게 향상됩니다.

TextBlock이 더 이상 우선 순위 작업 사이에 있지 않도록 재생 단추 위로 이동

CommandBar 및 ContextFlyout

CommandBar를 사용하는 경우 문제: 긴 스크롤 목록/그리드 후에 있는 UI 요소에 설명된 대로 목록을 스크롤하는 문제를 염두에 두어야 합니다. 다음 이미지는 목록/그리드의 맨 아래에 있는 CommandBar UI 레이아웃을 보여줍니다. 사용자는 목록/그리드의 맨 끝까지 아래로 스크롤하여 CommandBar에 도달해야 합니다.

목록/표 맨 아래에 있는 CommandBar

CommandBar목록/그리드 위에 배치하면 어떻게 될까요? 목록/그리드를 아래로 스크롤한 사용자는 CommandBar에 도달하기 위해 다시 위로 스크롤해야 하지만, 이전 구성보다 탐색이 약간 적습니다. 이는 앱의 초기 포커스가 CommandBar 옆이나 위에 놓여 있다고 가정한 것입니다. 초기 포커스가 목록/표 아래에 있으면 이 방법은 효과적이지 않습니다. 이러한 CommandBar 항목이 자주 액세스할 필요가 없는 전역 작업 항목인 경우(예: 동기화 단추) 목록/표 위에 해당 항목을 두는 것이 허용될 수 있습니다.

CommandBar의 항목을 세로로 쌓을 수는 없지만, 스크롤 방향의 반대 방향(예: 세로 스크롤 목록의 왼쪽 또는 오른쪽, 가로 스크롤 목록의 위쪽 또는 아래쪽)으로 배치하는 것은 UI 레이아웃에 적합한지 고려해 볼 수 있는 또 다른 옵션입니다.

사용자가 항목에 쉽게 액세스할 수 있어야 하는 앱 CommandBar 이 있는 경우 이러한 항목을 ContextFlyout 내에 배치하고 해당 항목에서 CommandBar제거하는 것이 좋습니다. ContextFlyout 는 UIElement 의 속성이며 해당 요소와 연결된 상황에 맞는 메뉴 입니다. PC에서 요소를 마우스 오른쪽 단추로 클릭하면 ContextFlyout컨텍스트 메뉴가 나타납니다. Xbox One에서는 포커스가 이러한 요소에 있는 동안 메뉴 단추를 누를 때 발생합니다.

UI 레이아웃 문제

일부 UI 레이아웃은 XY 포커스 탐색의 특성으로 인해 더 어려울 수 있으며 사례별로 평가해야 합니다. 단일 "올바른" 방법은 없으며 선택한 솔루션은 앱의 특정 요구 사항에 부합하지만 훌륭한 TV 환경을 만들기 위해 사용할 수 있는 몇 가지 기술이 있습니다.

이를 더 잘 이해하기 위해 이러한 문제 및 이를 극복하기 위한 몇 가지 기술을 보여 주는 가상 앱을 살펴보겠습니다.

비고

이 가짜 앱은 UI 문제 및 잠재적 해결 방법을 설명하기 위한 것이며 특정 앱에 가장 적합한 사용자 환경을 표시하기 위한 것이 아닙니다.

다음은 판매 가능한 주택 목록, 지도, 부동산에 대한 설명 및 기타 정보를 보여주는 가상의 부동산 앱입니다. 이 앱은 다음 기술을 사용하여 해결할 수 있는 세 가지 과제를 제기합니다.

UI 다시 정렬
집중 참여
마우스 모드

가짜 부동산 앱

문제: 긴 스크롤 목록/그리드 후에 있는 UI 요소

다음 이미지에 표시된 속성의 ListView 는 매우 긴 스크롤 목록입니다. 사용자가 목록으로 이동할 때 참여가 필요하지 ListView 경우 목록의 첫 번째 항목에 포커스가 배치됩니다. 사용자가 이전 또는 다음 단추에 도달하려면 목록의 모든 항목을 통과해야 합니다. 사용자가 목록 전체를 탐색하도록 요구하는 경우(즉, 목록이 너무 길어서 사용자가 이를 전체적으로 탐색하는 것이 비효율적인 경우) 다른 옵션을 고려하는 것이 좋습니다.

부동산 앱: 50개 항목이 있는 목록은 51번의 클릭으로 아래 단추에 도달합니다.

Solutions

UI 다시 정렬

페이지 맨 아래에 초기 포커스가 배치되지 않는 한 긴 스크롤 목록 위에 배치된 UI 요소는 일반적으로 아래에 배치된 경우보다 쉽게 액세스할 수 있습니다. 이 새로운 레이아웃이 다른 장치에서 작동하는 경우 Xbox One에 대해 특별한 UI 변경을 수행하는 대신 모든 장치 패밀리의 레이아웃을 변경하는 것이 비용이 적게 드는 방법일 수 있습니다. 스크롤의 반대 방향으로(즉, 세로로 스크롤되는 목록에는 가로로, 가로로 스크롤되는 목록에는 세로로) UI 요소를 배치하면 접근성이 더 좋아집니다.

부동산 앱: 긴 스크롤 목록 위에 단추 배치

포커스 참여

참여가 필요한 경우 전체 ListView 는 단일 포커스 대상이 됩니다. 사용자는 목록의 내용을 바이패스하여 다음 포커스 가능한 요소로 가져올 수 있습니다. 참여를 지원하는 컨트롤과 포커스 참여에서 컨트롤을 사용하는 방법에 대해 자세히 알아보세요.

부동산 앱: 이전/다음 단추에 도달하기 위해 클릭 1회만 수행하도록 참여를 필수로 설정

문제: 포커스 가능한 요소가 없는 ScrollViewer

XY 포커스 탐색은 한 번에 하나의 포커스 가능한 UI 요소로 이동하는 데 의존하기 때문에 포커스 가능한 요소가 없는 ScrollViewer (예: 이 예제와 같이 텍스트만 있는 요소)는 사용자가 모든 콘텐츠를 ScrollViewer볼 수 없는 시나리오를 일으킬 수 있습니다. 이 시나리오 및 기타 관련 시나리오에 대한 해결 방법은 포커스 참여를 참조하세요.

부동산 앱: 텍스트만 있는 ScrollViewer

문제: 자유 스크롤 UI

앱에 드로잉 화면과 같은 자유롭게 스크롤되는 UI가 필요한 경우 또는 이 예제에서는 맵에서 XY 포커스 탐색이 작동하지 않습니다. 이러한 경우 마우스 모드 를 설정하여 사용자가 UI 요소 내에서 자유롭게 탐색할 수 있도록 할 수 있습니다.

마우스 모드를 사용하여 UI 요소 매핑

마우스 모드.

XY 포커스 탐색 및 상호 작용에 설명된 대로 Xbox One에서는 XY 탐색 시스템을 사용하여 포커스가 이동되므로 사용자가 위쪽, 아래쪽, 왼쪽 및 오른쪽으로 이동하여 컨트롤에서 컨트롤로 포커스를 이동할 수 있습니다. 그러나 WebView 및 MapControl과 같은 일부 컨트롤에는 사용자가 컨트롤 경계 내에서 포인터를 자유롭게 이동할 수 있는 마우스와 유사한 상호 작용이 필요합니다. 사용자가 게임패드나 리모컨을 통해 포인터를 전체 페이지로 이동할 수 있게 하는 것이 PC에서 마우스를 사용하는 것과 유사한 환경을 제공하며, 이런 기능이 합리적인 일부 앱도 있습니다.

이러한 시나리오의 경우 전체 페이지 또는 페이지 내의 컨트롤에 대한 포인터(마우스 모드)를 요청해야 합니다. 예를 들어, 앱에는 특정 컨트롤 내부에서만 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에 대한 샘플 코드를 비롯한 자세한 내용은 마우스 모드를 사용하지 않도록 설정하는 방법을 참조하세요.

다음 다이어그램에서는 마우스 모드에서 게임 패드/원격에 대한 단추 매핑을 보여 줍니다.

마우스 모드에서 게임 패드/원격에 대한 단추 매핑

비고

마우스 모드는 게임 패드/원격이 있는 Xbox One에서만 지원됩니다. 다른 디바이스 패밀리 및 입력 형식에서는 자동으로 무시됩니다.

컨트롤 또는 페이지에서 RequiresPointer 속성을 사용하여 마우스 모드를 활성화합니다. 이 속성에는 세 가지 가능한 값이 있습니다: Never (기본값), WhenEngaged, 및 WhenFocused.

컨트롤에서 마우스 모드 활성화

사용자가 RequiresPointer="WhenEngaged" 컨트롤을 작동시키면, 해당 컨트롤에서 사용자가 해제할 때까지 마우스 모드가 활성화됩니다. 다음 코드 조각은 참여할 때 마우스 모드를 활성화하는 간단한 MapControl 방법을 보여 줍니다.

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

비고

컨트롤이 활성화할 때 마우스 모드를 켜는 경우, 반드시 IsEngagementRequired="true"과 함께 작동해야 합니다. 그렇지 않으면 마우스 모드가 결코 활성화되지 않을 것입니다.

컨트롤이 마우스 모드인 경우 중첩된 컨트롤도 마우스 모드에 있습니다. 자식의 요청된 모드는 무시됩니다. 부모가 마우스 모드에 있으면 자식도 동일한 모드에 있어야 하며, 그렇지 않으면 불가능합니다.

또한 컨트롤의 요청된 모드는 포커스가 있을 때만 검사되므로 포커스가 있는 동안에는 모드가 동적으로 변경되지 않습니다.

페이지에서 마우스 모드 활성화

페이지에 속성 RequiresPointer="WhenFocused"이 있으면 포커스가 되면 전체 페이지에 대해 마우스 모드가 활성화됩니다. 다음 코드 조각은 이 속성을 페이지에 제공하는 방법을 보여 줍니다.

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

비고

이 값은 WhenFocusedPage 개체에서만 지원됩니다. 컨트롤에서 이 값을 설정하려고 하면 예외가 발생합니다.

전체 화면 콘텐츠에 마우스 모드를 사용하지 않도록 설정

일반적으로 비디오 또는 다른 형식의 콘텐츠를 전체 화면에 표시할 때 커서를 숨기면 사용자의 방해가 될 수 있습니다. 이 시나리오는 나머지 앱에서 마우스 모드를 사용하지만 전체 화면 콘텐츠를 표시할 때 해제하려는 경우에 발생합니다. 이렇게 하려면 전체 화면 콘텐츠를 별도의 Page에 배치하고, 아래 단계를 따르세요.

개체에서 App을/를 설정하세요 RequiresPointerMode="WhenRequested".
전체 화면을 Page제외한 모든 Page 개체에서 .RequiresPointer="WhenFocused"
전체 화면Page을 위해 RequiresPointer="Never"을 설정하십시오.

이렇게 하면 전체 화면 콘텐츠를 표시할 때 커서가 표시되지 않습니다.

포커스 시각적 표시

포커스 시각적 개체는 현재 포커스가 있는 UI 요소 주위의 테두리입니다. 이렇게 하면 사용자가 길을 잃지 않고 UI를 쉽게 탐색할 수 있도록 사용자를 지향할 수 있습니다.

시각적 업데이트와 포커스 시각적 개체에 추가된 수많은 사용자 지정 옵션을 통해 개발자는 단일 포커스 시각적 개체가 PC 및 Xbox One뿐만 아니라 키보드 및/또는 게임 패드/원격을 지원하는 다른 Windows 장치에서도 잘 작동한다고 신뢰할 수 있습니다.

동일한 포커스 비주얼을 여러 플랫폼에서 사용할 수 있지만 사용자가 접하는 컨텍스트는 10피트 환경에서는 약간 다릅니다. 사용자가 전체 TV 화면에 주의를 기울이지 않는다고 가정해야 하므로 시각적 개체 검색의 좌절을 피하기 위해 현재 포커스가 있는 요소가 항상 사용자에게 명확하게 표시되는 것이 중요합니다.

게임 패드 또는 리모컨을 사용할 때는 포커스 비주얼이 기본적으로 표시되지만, 키보드를 사용할 때는 아닙니다. 따라서 구현하지 않더라도 Xbox One에서 앱을 실행할 때 표시됩니다.

초기 중점 시각적 배치

앱을 시작하거나 페이지로 이동할 때 사용자가 작업을 수행할 첫 번째 요소로 적합한 UI 요소에 포커스를 놓습니다. 예를 들어 사진 앱은 갤러리의 첫 번째 항목에 포커스를 배치할 수 있으며, 노래의 상세 보기로 이동한 음악 앱은 음악 재생의 용이성을 위해 재생 단추에 포커스를 배치할 수 있습니다.

앱의 왼쪽 위 영역(또는 오른쪽에서 왼쪽 흐름의 경우 오른쪽 위)에 초기 포커스를 배치해 봅니다. 대부분의 사용자는 앱 콘텐츠 흐름이 일반적으로 시작되는 위치이기 때문에 먼저 해당 코너에 집중하는 경향이 있습니다.

포커스를 명확하게 표시

사용자가 포커스를 검색하지 않고 중단한 위치를 선택할 수 있도록 화면에 항상 하나의 포커스 시각적 개체가 표시되어야 합니다. 마찬가지로 항상 화면에 포커스가 있는 항목이 있어야 합니다. 예를 들어 텍스트와 포커스 가능한 요소만 있는 팝업을 사용하지 마세요.

이 규칙의 예외는 비디오 시청 또는 이미지 보기와 같은 전체 화면 환경에 대한 것이며, 이 경우 포커스 시각적 개체를 표시하는 것이 적절하지 않습니다.

포커스 표시

포커스 표시는 사용자가 게임 패드 또는 키보드 포커스를 이동할 때 단추와 같은 포커스 가능한 요소의 테두리에 애니메이션 효과를 주는 조명 효과입니다. 포커스가 있는 요소의 테두리에 애니메이션 효과로 빛을 주면, 포커스를 드러냄으로써 사용자에게 현재 포커스의 위치와 앞으로의 포커스 위치에 대한 이해를 높여줍니다.

포커스 표시는 기본적으로 꺼져 있습니다. 10피트 환경의 경우 앱 생성자에서 Application.FocusVisualKind 속성을 설정하여 포커스를 표시하도록 옵트인해야 합니다.

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

자세한 내용은 포커스 표시에 대한 지침을 참조하세요.

포커스 시각 효과 사용자 지정

포커스 시각적 개체를 사용자 지정하려는 경우 각 컨트롤의 포커스 시각적 개체와 관련된 속성을 수정하여 이 작업을 수행할 수 있습니다. 앱을 개인 설정하기 위해 활용할 수 있는 몇 가지 속성이 있습니다.

시각적 상태를 사용하여 사용자 정의 포커스 비주얼을 그려서 시스템에서 제공하는 포커스 비주얼을 비활성화할 수도 있습니다. 자세한 내용은 VisualState를 참조하세요.

라이트 디스미스 오버레이

사용자가 현재 게임 컨트롤러 또는 원격 제어를 사용하여 조작하고 있는 UI 요소에 대한 사용자의 주의를 끌기 위해 UWP는 Xbox One에서 앱이 실행 중일 때 팝업 UI 외부 영역을 포함하는 "스모크" 계층을 자동으로 추가합니다. 이렇게 하면 추가 작업이 필요하지 않지만 UI를 디자인할 때 유의해야 할 사항입니다. 스모크 계층을 활성화하거나 비활성화하려면 LightDismissOverlayMode 속성을 FlyoutBase에 설정할 수 있습니다. 기본값은 Auto로, Xbox에서는 활성화되고 다른 곳에서는 비활성화됩니다. 자세한 내용은 모달 및 라이트 해제를 참조하세요.

집중적 참여

포커스 참여는 게임 패드 또는 원격을 더 쉽게 사용하여 앱과 상호 작용할 수 있도록 하기 위한 것입니다.

비고

포커스 참여를 설정해도 키보드 또는 다른 입력 장치에는 영향을 주지 않습니다.

FrameworkElement 개체의 속성 이 로 설정되면, 해당 컨트롤은 포커스 참여가 필요한 것으로 표시됩니다. 즉, 사용자가 A/선택 단추를 눌러 컨트롤을 "연결"하고 상호 작용해야 합니다. 작업이 완료되면 B/뒤로 단추를 눌러 컨트롤을 해제하고 밖으로 이동할 수 있습니다.

비고

IsFocusEngagementEnabled 는 새 API이며 아직 문서화되지 않았습니다.

포커스 갇힘 방지

포커스 트래핑은 사용자가 앱의 UI를 탐색하려고 하지만 컨트롤 내에서 "트래핑"되어 해당 컨트롤 외부로 이동하기 어렵거나 불가능할 때 발생합니다.

다음 예제에서는 포커스 트래핑을 만드는 UI를 보여줍니다.

가로 슬라이더의 왼쪽과 오른쪽 단추

사용자가 왼쪽 단추에서 오른쪽 단추로 이동하려는 경우 D 패드/왼쪽 스틱을 두 번 누르기만 하면 된다고 가정하는 것이 논리적입니다. 그러나 슬라이더에 참여가 필요하지 않은 경우, 다음과 같은 동작이 발생합니다. 사용자가 오른쪽을 처음 누르면 포커스가 Slider로 이동하고, 다시 오른쪽을 누르면 Slider의 핸들이 오른쪽으로 이동합니다. 사용자는 핸들을 오른쪽으로 계속 이동하고 단추에 연결할 수 없습니다.

이 문제를 해결하는 방법에는 여러 가지가 있습니다. 하나는 XY 포커스 탐색 및 상호 작용 의 부동산 앱 예제와 유사하게 다른 레이아웃을 디자인하는 것입니다. 여기서 이전 및 다음 단추를 위의 ListView위치로 이동했습니다. 다음 이미지와 같이 컨트롤을 가로 대신 세로로 쌓으면 문제가 해결됩니다.

가로 슬라이더 위와 아래 단추

이제 사용자는 D 패드/왼쪽 스틱에서 위아래로 눌러 각 컨트롤로 이동할 수 있으며 포커스가 있는 경우 Slider 왼쪽과 오른쪽을 눌러 예상대로 핸들을 이동할 Slider 수 있습니다.

이 문제를 해결하는 또 다른 방법은 Slider에서의 참여를 요구하는 것입니다. IsFocusEngagementEnabled="True" 설정하면 다음과 같이 동작합니다.

사용자가 오른쪽의 단추로 이동할 수 있도록 슬라이더에 포커스 참여 필요

Slider에 포커스가 필요할 때, 사용자는 D 패드/왼쪽 스틱에서 오른쪽을 두 번 눌러 간단하게 오른쪽의 버튼으로 이동할 수 있습니다. 이 솔루션은 UI 조정이 필요하지 않고 예상 동작을 생성하기 때문에 유용합니다.

아이템 제어

슬라이더 컨트롤 외에도 다음과 같이 참여를 요구할 수 있는 다른 컨트롤이 있습니다.

컨트롤과 Slider 달리 이러한 컨트롤은 자체 내에서 포커스를 트래핑하지 않지만 많은 양의 데이터를 포함할 때 유용성 문제를 일으킬 수 있습니다. 다음은 많은 양의 데이터를 포함하는 예제 ListView 입니다.

위와 아래에 많은 양의 데이터와 단추가 있는 ListView

예제와 Slider 마찬가지로 맨 위에 있는 단추에서 게임 패드/리모컨을 사용하여 맨 아래의 단추로 이동해 보겠습니다. 위쪽 단추의 포커스부터 D 패드/스틱을 눌러 포커스를 첫 번째 항목("항목 ListView 1")에 배치합니다. 사용자가 다시 누를 때 목록의 다음 항목은 아래쪽에 있는 단추가 아니라 포커스를 가져옵니다. 단추로 이동하려면 사용자가 첫 번째 항목의 ListView 모든 항목을 탐색해야 합니다. ListView 많은 양의 데이터가 포함된 경우 이는 불편할 수 있으며 최적의 사용자 환경이 아닐 수 있습니다.

이 문제를 해결하려면 ListView에 속성 IsFocusEngagementEnabled="True"을 설정하여 참여를 요구하도록 합니다. 이렇게 하면 사용자가 특정 버튼을 눌러 ListView를 빠르게 넘길 수 있습니다. 그러나 포커스가 있을 때 A/Select 단추를 누른 다음 B/뒤로 단추를 눌러 연결을 해제하지 않으면 목록을 스크롤하거나 항목을 선택할 수 없습니다.

참여가 필요한 ListView

스크롤뷰어 (ScrollViewer)

이러한 컨트롤과 약간 다른 것은 고려해야 할 고유한 단점이 있는 ScrollViewer입니다. 포커스가 가능한 콘텐츠가 ScrollViewer에 있는 경우 기본적으로 ScrollViewer로 이동하면 포커스 가능한 요소를 통해 이동할 수 있습니다. 와 ListView같이 각 항목을 스크롤하여 바깥 ScrollViewer쪽을 탐색해야 합니다.

ScrollViewer 포커스 가능한 콘텐츠가 없는 경우(예: 텍스트만 포함된 경우), 사용자가 ScrollViewer에 IsFocusEngagementEnabled="True" 버튼을 이용하여 참여할 수 있도록 을 설정할 수 있습니다. 작업이 완료되면 D 패드/왼쪽 스틱을 사용하여 텍스트를 스크롤한 다음 B/뒤로 단추를 눌러 작업이 완료되면 해제할 수 있습니다.

또 다른 방법은 ScrollViewer에 IsTabStop="True"을 설정하여 사용자가 컨트롤을 작동할 필요 없이, 그냥 포커스를 맞추기만 하고 포커스 가능한 요소가 ScrollViewer 안에 없을 때 D 패드/왼쪽 스틱으로 스크롤할 수 있도록 하는 것입니다.

포커스 참여 기본값

일부 컨트롤은 포커스 트래핑을 발생시켜 포커스 참여를 요구하는 기본 설정을 보증하는 반면, 다른 컨트롤은 기본적으로 포커스 참여를 해제하지만 켜는 것이 도움이 될 수 있습니다. 다음 표에서는 이러한 컨트롤과 기본 포커스 참여 동작을 나열합니다.

제어	포커스 참여 기본값
캘린더 날짜 선택기	설정
FlipView	끄기
그리드뷰	끄기
ListBox	끄기
리스트뷰 (ListView)	끄기
스크롤뷰어 (ScrollViewer)	끄기
SemanticZoom	끄기
슬라이더	설정

다른 모든 Windows 컨트롤에서는 IsFocusEngagementEnabled="True" 시 동작이나 시각적인 변경이 발생하지 않습니다.

요약

특정 디바이스 또는 환경에 최적화된 Windows 애플리케이션을 빌드할 수 있지만 유니버설 Windows 플랫폼을 사용하면 입력 장치 또는 사용자 기능에 관계없이 2피트 및 10피트 환경 모두에서 디바이스 간에 성공적으로 사용할 수 있는 앱을 빌드할 수 있습니다. 이 문서의 권장 사항을 사용하면 앱이 TV와 PC 모두에 있을 수 있는 만큼 좋은지 확인할 수 있습니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2025-12-02