Interacciones de controlador para juegos y control remoto

Muchas experiencias de interacción se comparten entre el controlador para juegos, el control remoto y el teclado

Crea experiencias de interacción en las aplicaciones de Windows que garantizan que tu aplicación sea utilizable y accesible a través de los tipos de entrada tradicionales de equipos, portátiles y tabletas (mouse, teclado, táctil, etc.), así como los tipos de entrada típicos de la experiencia de TV y Xbox 10 pies , como el controlador para juegos y el control remoto.

Consulta Diseño para Xbox y TV para obtener orientación general sobre el diseño de aplicaciones de Windows en la experiencia de 10 pies.

Información general

En este tema, hablamos sobre lo que debería considerar en su diseño de interacción (o lo que no necesita considerar, si la plataforma lo gestiona por usted), y proporcionamos orientación, recomendaciones y sugerencias para crear aplicaciones de Windows que sean agradables de usar, independientemente del dispositivo, el tipo de entrada, o las capacidades y preferencias del usuario.

En resumen, la aplicación debe ser tan intuitiva y fácil de usar en el entorno de 2 pies como lo es en el entorno de 10 pies (y viceversa). Admita los dispositivos preferidos del usuario, haga que el foco de la interfaz de usuario sea claro e inconfundible, organice el contenido para que la navegación sea coherente y predecible, y proporcione a los usuarios la ruta más corta posible para lo que quieren hacer.

Optimizar las experiencias de visualización para pantallas de 2 y 10 pies

Como mínimo, te recomendamos que pruebes tus aplicaciones para asegurarte de que funcionan bien en escenarios de 2 pies y 10 pies, y que todas las funciones son reconocibles y accesibles para el controlador para juegos de Xbox y el control remoto.

Estas son algunas otras maneras de optimizar tu aplicación para su uso tanto en experiencias de 2 pies como de 10 pies y con todos los dispositivos de entrada (cada uno enlaza a la sección adecuada en este tema).

Controlador para juegos y control remoto

Al igual que el teclado y el ratón son para PC, y la función táctil es para teléfono y tableta, el mando y el control remoto son los dispositivos de entrada principales para la experiencia de 10 pies (aproximadamente 3 metros). En esta sección se presenta lo que son los botones de hardware y lo que hacen. En la navegación del foco XY y la interacción y en el modo mouse, aprenderá a optimizar su aplicación al usar estos dispositivos de entrada.

La calidad del controlador para juegos y el comportamiento remoto que obtienes de serie depende de la compatibilidad con el teclado en tu aplicación. Una buena manera de asegurarse de que la aplicación funcione bien con el controlador para juegos o remoto es asegurarse de que funciona bien con el teclado en pc y luego probar con controlador para juegos o remoto para encontrar puntos débiles en la interfaz de usuario.

Botones de hardware

A lo largo de este documento, los nombres indicados en el diagrama siguiente harán referencia a los botones.

Como puedes ver en el diagrama, hay algunos botones compatibles con el controlador para juegos que no son compatibles con el control remoto y viceversa. Aunque puede usar botones que solo se admiten en un dispositivo de entrada para acelerar la navegación por la interfaz de usuario, tenga en cuenta que usarlos para interacciones críticas puede crear una situación en la que el usuario no pueda interactuar con determinadas partes de la interfaz de usuario.

En la tabla siguiente se enumeran todos los botones de hardware compatibles con las aplicaciones de Windows y qué dispositivo de entrada los admite.

Compatibilidad con botones integrados

UWP asigna automáticamente el comportamiento de entrada de teclado existente al controlador para juegos y a la entrada de control remoto. En la siguiente tabla se enumeran estos mapeos predefinidos.

*Cuando la aplicación no maneje los eventos KeyDown ni KeyUp para el botón B, se activará el evento SystemNavigationManager.BackRequested, lo que debería dar lugar a la navegación hacia atrás dentro de la aplicación. Sin embargo, tiene que implementar esto usted mismo, como en el siguiente fragmento de código:

// 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;
}

Las aplicaciones de Windows en Xbox One también admiten presionar el botón Menú para abrir menús contextuales. Para obtener más información, vea CommandBar y ContextFlyout.

Compatibilidad con aceleradores

Los botones de acelerador son botones que se pueden usar para acelerar la navegación a través de una interfaz de usuario. Sin embargo, estos botones pueden ser únicos para un determinado dispositivo de entrada, por lo que tenga en cuenta que no todos los usuarios podrán usar estas funciones. De hecho, el controlador para juegos es actualmente el único dispositivo de entrada que admite funciones de aceleración para aplicaciones de Windows en Xbox One.

En la tabla siguiente se muestra la compatibilidad del acelerador integrada en UWP, así como la que puedes implementar por tu cuenta. Utilice estos comportamientos en la interfaz de usuario personalizada para proporcionar una experiencia de usuario coherente y fácil.

Navegación e interacción con enfoque XY

Si la aplicación admite la navegación con foco adecuada para el teclado, esto se traducirá bien en el controlador para juegos y el control remoto. La navegación con las teclas de dirección se asigna al panel D (así como el stick izquierdo en el controlador para juegos) y la interacción con los elementos de la interfaz de usuario se asigna a la tecla Entrar/Seleccionar (consulta Controlador para juegos y control remoto).

Tanto el teclado como el controlador de videojuegos usan muchos eventos y propiedades; ambos disparan eventos KeyDown y KeyUp y solo navegarán a los controles que tienen las propiedades IsTabStop="True" y Visibility="Visible". Para obtener instrucciones de diseño de teclado, consulte Interacciones de teclado.

Si la compatibilidad con teclado se implementa correctamente, la aplicación funcionará razonablemente bien; sin embargo, puede haber algún trabajo adicional necesario para admitir todos los escenarios. Piense en las necesidades específicas de la aplicación para proporcionar la mejor experiencia de usuario posible.

Problemas de enfoque de depuración

El método FocusManager.GetFocusedElement le indicará qué elemento tiene actualmente el foco. Esto es útil para situaciones en las que la ubicación del objeto visual de foco puede no ser obvia. Puede registrar esta información en la ventana de salida de Visual Studio de la siguiente manera:

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

Hay tres razones comunes por las que es posible que la navegación XY no funcione de la manera esperada:

• La propiedad IsTabStop o Visibility está establecida de forma incorrecta.
• El control que obtiene el enfoque es realmente más grande de lo que crees: la navegación en el eje XY considera el tamaño total del control (ActualWidth y ActualHeight), no solo la parte del control que renderiza algo interesante.
• Un control centrado está encima de otro: la navegación XY no admite controles superpuestos.

Si la navegación XY sigue sin funcionar de la manera esperada después de corregir estos problemas, puede apuntar manualmente al elemento que desea obtener el foco mediante el método descrito en Invalidación de la navegación predeterminada.

Si la navegación XY funciona según lo previsto, pero no se muestra ningún objeto visual de foco, uno de los siguientes problemas puede ser la causa:

• Reconfiguraste la plantilla del control y no incluiste un visual de enfoque. Establezca UseSystemFocusVisuals="True" o agregue manualmente un objeto visual de foco.
• Ha movido el foco llamando a Focus(FocusState.Pointer). El parámetro FocusState controla lo que sucede con el objeto visual de foco. Por lo general, debe establecer esto en FocusState.Programmatic, que mantiene visible el indicador visual del foco si era visible antes, y lo oculta si estaba oculto.

En el resto de esta sección se detallan los desafíos de diseño comunes al usar la navegación XY y se ofrecen varias maneras de resolverlos.

Interfaz de usuario inaccesible

Dado que la navegación con foco XY limita al usuario a desplazarse hacia arriba, abajo, izquierda y derecha, puede terminar con escenarios en los que las partes de la interfaz de usuario no son accesibles. En el diagrama siguiente se muestra un ejemplo del tipo de diseño de interfaz de usuario que la navegación con foco XY no admite. Tenga en cuenta que el elemento en el centro no es accesible mediante el mando de juegos o control remoto, ya que la navegación vertical y horizontal tendrá prioridad y el elemento central nunca será lo suficientemente alto como para obtener el foco.

Si por algún motivo no es posible reorganizar la interfaz de usuario, use una de las técnicas que se describen en la sección siguiente para invalidar el comportamiento de foco predeterminado.

Invalidación de la navegación predeterminada

Aunque la Plataforma universal de Windows intenta asegurarse de que la navegación del panel D/stick izquierdo tenga sentido para el usuario, no puede garantizar el comportamiento optimizado para las intenciones de la aplicación. La mejor manera de asegurarse de que la navegación está optimizada para la aplicación es probarla con un controlador para juegos y confirmar que el usuario puede acceder a todos los elementos de la interfaz de usuario de una manera que tenga sentido para los escenarios de la aplicación. En caso de que los escenarios de la aplicación llamen a un comportamiento no logrado a través de la navegación de foco XY proporcionada, considere la posibilidad de seguir las recomendaciones de las secciones siguientes o invalidar el comportamiento para colocar el foco en un elemento lógico.

El siguiente fragmento de código muestra cómo podría invalidar el comportamiento de navegación de foco 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>

En este caso, cuando el foco está en el botón Home y el usuario navega a la izquierda, el foco se moverá al botón MyBtnLeft; si el usuario navega a la derecha, el foco se moverá al botón MyBtnRight; y así sucesivamente.

Para evitar que el foco se mueva de un control en una dirección determinada, use la XYFocus* propiedad para apuntarlo al mismo control:

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

Con estas XYFocus propiedades, un control primario también puede forzar la navegación de sus hijos cuando el siguiente candidato de enfoque está fuera de su árbol visual, a menos que el hijo que tiene el enfoque use la misma XYFocus propiedad.

<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>

En el ejemplo anterior, si el foco está en Button Dos y el usuario navega a la derecha, el mejor candidato de enfoque es Button Cuatro; sin embargo, el foco se mueve a Button Tres porque el elemento primario UserControl lo obliga a navegar allí cuando está fuera de su árbol visual.

Ruta de menor número de clics

Intente permitir que el usuario realice las tareas más comunes en el menor número de clics. En el ejemplo siguiente, textBlock se coloca entre el botón Reproducir (que inicialmente obtiene el foco) y un elemento usado habitualmente, de modo que un elemento innecesario se coloca entre las tareas prioritarias.

En el ejemplo siguiente, textBlock se coloca encima del botón Reproducir en su lugar. Simplemente reorganizar la interfaz de usuario para que los elementos innecesarios no se coloquen entre tareas prioritarias mejorará considerablemente la facilidad de uso de la aplicación.

CommandBar y ContextFlyout

Al usar una barra de comandos, tenga en cuenta el problema de desplazarse por una lista como se mencionó en Problema: elementos de la interfaz de usuario ubicados después de una lista o cuadrícula de desplazamiento largo. En la imagen siguiente se muestra un diseño de interfaz de usuario con el CommandBar en la parte inferior de una lista o cuadrícula. El usuario tendría que desplazarse hasta el final de la lista o cuadrícula para llegar a CommandBar.

¿Qué ocurre si coloca el CommandBarencima de la lista/cuadrícula? Mientras que un usuario que se desplazaba hacia abajo en la lista o cuadrícula tendría que desplazarse hacia arriba para llegar al CommandBar, esta opción requiere ligeramente menos navegación que la configuración anterior. Tenga en cuenta que esto supone que el foco inicial de la aplicación se coloca junto a o encima del CommandBar; este enfoque no funcionará también si el enfoque inicial está por debajo de la lista o cuadrícula. Si estos CommandBar elementos son elementos de acción globales a los que no es necesario tener acceso muy a menudo (por ejemplo, un botón Sincronizar ), puede que sea aceptable tenerlos encima de la lista o cuadrícula.

Aunque no se pueden apilar verticalmente los elementos de CommandBar, colocarlos en contra de la dirección del desplazamiento (por ejemplo, a la izquierda o derecha de una lista de desplazamiento vertical, o en la parte superior o inferior de una lista de desplazamiento horizontal) es otra opción que puede considerar si funciona bien para el diseño de la interfaz de usuario.

Si la aplicación tiene un CommandBar cuyos elementos deben ser accesibles fácilmente por los usuarios, es posible que quiera considerar la posibilidad de colocar estos elementos dentro de ContextFlyout y quitarlos de CommandBar. ContextFlyout es una propiedad de UIElement y es el menú contextual asociado a ese elemento. En el PC, cuando haga clic con el botón derecho en un elemento con un ContextFlyout, aparecerá ese menú contextual. En Xbox One, esto ocurrirá cuando presionas el botón Menú mientras el foco está en este tipo de elemento.

Desafíos de diseño de la interfaz de usuario

Algunos diseños de UI son más desafiantes debido a la naturaleza de la navegación con foco XY y deben evaluarse individualmente. Aunque no hay una única forma "correcta" y qué solución que elijas es para las necesidades específicas de tu aplicación, hay algunas técnicas que puedes emplear para crear una excelente experiencia de TV.

Para entender esto mejor, echemos un vistazo a una aplicación imaginaria que ilustra algunos de estos problemas y técnicas para superarlos.

A continuación se muestra una aplicación inmobiliaria imaginaria que muestra una lista de casas disponibles para la venta, un mapa, una descripción de una propiedad y otra información. Esta aplicación plantea tres desafíos que puedes superar mediante las técnicas siguientes:

• Reorganización de la interfaz de usuario
• Enfoque en la participación
• Modo ratón

Problema: elementos de la interfaz de usuario ubicados después de una lista o cuadrícula de desplazamiento largo

El ListView de propiedades que se muestra en la imagen siguiente es una lista de desplazamiento muy larga. Si la interacciónno es necesaria en ListView, cuando el usuario navega a la lista, el cursor se situará en el primer elemento de la lista. Para que el usuario llegue al botón Anterior o Siguiente , debe pasar por todos los elementos de la lista. En los casos como este en los que requerir que el usuario recorra toda la lista es doloroso, es decir, cuando la lista no es lo suficientemente corta como para que esta experiencia sea aceptable, es posible que desee considerar otras opciones.

Solutions

Reorganización de la interfaz de usuario

A menos que el foco inicial se coloque en la parte inferior de la página, los elementos de la interfaz de usuario colocados encima de una lista de desplazamiento largo suelen ser más fácilmente accesibles que si se colocan a continuación. Si este nuevo diseño funciona para otros dispositivos, cambiar el diseño de todas las familias de dispositivos en lugar de realizar cambios especiales en la interfaz de usuario solo para Xbox One podría ser un enfoque menos costoso. Además, colocar los elementos de la interfaz de usuario contra la dirección de desplazamiento (es decir, horizontalmente a una lista que se desplaza verticalmente o verticalmente a una lista que se desplaza horizontalmente) mejorará aún más la accesibilidad.

Compromiso enfocado

Cuando se requiere la participación, todo ListView se convierte en un único objetivo de enfoque. El usuario podrá omitir el contenido de la lista para llegar al siguiente elemento enfocado. Obtenga más información sobre qué controles admiten la participación y cómo usarlos en Enfoque de participación.

Problema: ScrollViewer sin elementos enfocados

Dado que la navegación con foco XY se basa en navegar a un elemento de interfaz de usuario que se puede centrar a la vez, un ScrollViewer que no contiene ningún elemento enfocado (por ejemplo, uno con solo texto, como en este ejemplo) puede provocar un escenario en el que el usuario no pueda ver todo el contenido en ScrollViewer. Para obtener soluciones a este y otros escenarios relacionados, consulte Compromiso del enfoque.

Problema: interfaz de usuario de desplazamiento libre

Cuando tu aplicación requiere una interfaz de usuario de desplazamiento libre, como una superficie de dibujo o, en este caso, un mapa, la navegación con enfoque en el eje XY simplemente no funciona. En tales casos, puede activar el modo de mouse para permitir al usuario navegar libremente dentro de un elemento de la interfaz de usuario.

Modo del mouse

Como se describe en navegación e interacción con el foco XY, en Xbox One, el foco se mueve mediante un sistema de navegación XY, lo que permite al usuario cambiar el foco de un control a otro moviéndolo en las direcciones de arriba, abajo, izquierda y derecha. Sin embargo, algunos controles, como WebView y MapControl, requieren una interacción similar al mouse donde los usuarios pueden mover libremente el puntero dentro de los límites del control. También hay algunas aplicaciones en las que tiene sentido que el usuario pueda mover el puntero a través de toda la página, teniendo una experiencia con controlador para juegos o remoto similar a lo que los usuarios pueden encontrar en un equipo con un mouse.

En estos escenarios, debe solicitar un puntero (modo ratón) para toda la página o en un control dentro de una página. Por ejemplo, la aplicación podría tener una página que tenga un WebView control que use el modo de mouse solo mientras está dentro del control y la navegación con foco XY en cualquier otra parte. Para solicitar un puntero, puede especificar si quiere que se active un control o una página o cuando una página tenga el foco.

En el caso de las aplicaciones web XAML y hospedadas que se ejecutan en Xbox One, el modo de mouse está activado de forma predeterminada para toda la aplicación. Se recomienda encarecidamente desactivarlo y optimizar la aplicación para la navegación XY. Para ello, establezca la propiedad Application.RequiresPointerMode en WhenRequested de modo que solo se habilite el modo ratón cuando un control o una página lo requieran.

Para hacerlo en una aplicación XAML, usa el código siguiente en tu App clase:

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

Para obtener más información, incluido el código de ejemplo para HTML/JavaScript, vea Cómo deshabilitar el modo de mouse.

En el diagrama siguiente se muestran las asignaciones de botones para el controlador para juegos o el control remoto en modo de mouse.

Use la propiedad RequirePointer en un control o página para activar el modo de mouse en él. Esta propiedad tiene tres valores posibles: Never (el valor predeterminado), WhenEngagedy WhenFocused.

Activación del modo de mouse en un control

Cuando el usuario interactúa con un control con RequiresPointer="WhenEngaged", el modo del mouse se activa en el control hasta que el usuario lo desconecta. El siguiente fragmento de código muestra un sencillo MapControl que activa el modo de mouse cuando se activa:

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

Cuando un control está en modo de ratón, sus controles anidados también estarán en el modo de ratón. El modo solicitado de sus hijos se omitirá; es imposible que un padre esté en modo mouse pero su hijo no lo esté.

Además, el modo solicitado de un control solo se inspecciona cuando obtiene el foco, por lo que el modo no cambiará dinámicamente mientras tiene el foco.

Activación del modo de mouse en una página

Cuando una página tiene la propiedad RequiresPointer="WhenFocused", el modo del mouse se activará para toda la página cuando reciba el foco. El siguiente fragmento de código demuestra cómo asignar a una página esta propiedad.

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

Deshabilitación del modo de mouse para contenido de pantalla completa

Normalmente, al mostrar vídeo u otros tipos de contenido en pantalla completa, querrá ocultar el cursor porque puede distraer al usuario. Este escenario se produce cuando el resto de la aplicación usa el modo de mouse, pero quiere desactivarlo al mostrar contenido de pantalla completa. Para ello, coloque el contenido de pantalla completa por separado Page, y siga los pasos que se indican a continuación.

1. En el App objeto , establezca RequiresPointerMode="WhenRequested".
2. En todos los Page objetos excepto para la pantalla Page completa, establezca RequiresPointer="WhenFocused".
3. Para la pantalla completa Page, configure RequiresPointer="Never".

De este modo, el cursor nunca aparecerá al mostrar contenido de pantalla completa.

Indicador visual de foco

El objeto visual de foco es el borde alrededor del elemento de interfaz de usuario que actualmente tiene el foco. Esto ayuda a orientar al usuario para que pueda navegar fácilmente por la interfaz de usuario sin perderse.

Con una actualización visual y numerosas opciones de personalización añadidas al enfoque visual, los desarrolladores pueden confiar en que un único enfoque visual funcionará bien en PC y Xbox One, así como en cualquier otro dispositivo Windows que admita teclado y/o mando.

Aunque el mismo objeto visual de foco se puede usar en distintas plataformas, el contexto en el que el usuario lo encuentra es ligeramente diferente para la experiencia de 10 pies. Debe suponer que el usuario no presta atención completa a toda la pantalla del televisor y, por lo tanto, es importante que el elemento enfocado actualmente sea claramente visible para el usuario en todo momento para evitar la frustración de buscar el elemento visual.

También es importante tener en cuenta que el objeto visual de foco se muestra de forma predeterminada cuando se usa un controlador para juegos o un control remoto, pero no un teclado. Por lo tanto, aunque no lo implementes, aparecerá cuando ejecutes la aplicación en Xbox One.

Ubicación del foco inicial visual

Al iniciar una aplicación o navegar a una página, coloque el foco en un elemento de interfaz de usuario que tenga sentido como el primer elemento en el que el usuario tomaría medidas. Por ejemplo, una aplicación de fotos puede centrarse en el primer elemento de la galería y una aplicación de música navega a una vista detallada de una canción podría centrarse en el botón de reproducción para facilitar la reproducción de música.

Intenta colocar el foco inicial en la región superior izquierda de la aplicación (o superior derecha para un flujo de derecha a izquierda). La mayoría de los usuarios tienden a centrarse primero en esa esquina, ya que es donde comienza generalmente el flujo de contenido de la aplicación.

Hacer que el foco sea claramente visible

Un objeto visual de enfoque siempre debe estar visible en la pantalla para que el usuario pueda retomar desde donde lo dejó sin tener que buscar el punto de enfoque. Del mismo modo, debe haber un elemento enfocado en pantalla en todo momento; por ejemplo, no use elementos emergentes con solo texto y sin elementos enfocados.

Una excepción a esta regla sería para experiencias de pantalla completa, como ver vídeos o ver imágenes, en cuyo caso no sería adecuado mostrar el objeto visual de foco.

Mostrar foco

El foco Reveal es un efecto de iluminación que anima el borde de los elementos enfocados, como un botón, cuando el usuario mueve el controlador para juegos o el foco del teclado a ellos. Al animar el resplandor alrededor del borde de los elementos centrados, reveal focus proporciona a los usuarios una mejor comprensión de dónde está y dónde va el foco.

Reveal focus está desactivado de forma predeterminada. Para experiencias de 10 pies, debes optar por mostrar el foco estableciendo la propiedad Application.FocusVisualKind en el constructor de la aplicación.

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

Para obtener más información, consulte las instrucciones para Mostrar el foco.

Personalización del objeto visual de foco

Si desea personalizar el objeto visual de foco, puede hacerlo modificando las propiedades relacionadas con el objeto visual de foco para cada control. Hay varias propiedades de este tipo que puedes aprovechar para personalizar la aplicación.

Incluso puede optar por no usar los visuales de enfoque proporcionados por el sistema creando sus propios estados visuales. Para más información, consulte VisualState.

Superposición de cierre de luz

Para llamar la atención del usuario a los elementos de la interfaz de usuario que el usuario está manipulando actualmente con el mando del juego o el control remoto, UWP agrega automáticamente una capa de "humo" que cubre áreas fuera de la interfaz de usuario emergente cuando la aplicación se ejecuta en Xbox One. Esto no requiere trabajo adicional, pero es algo que debe tener en cuenta al diseñar la interfaz de usuario. Puedes establecer la LightDismissOverlayMode propiedad en cualquiera FlyoutBase para habilitar o deshabilitar la capa de humo; el valor predeterminado es Auto, lo que significa que está habilitado en Xbox y deshabilitado en otro lugar. Para obtener más información, consulte Modal frente a descartar suavemente.

Enfoque en la participación

La interacción con el foco está pensada para facilitar el uso de un controlador para juegos o un control remoto para interactuar con una aplicación.

Cuando la propiedad IsFocusEngagementEnabled de un objeto FrameworkElement se establece en True, marca el control como que necesita interactuar con el foco. Esto significa que el usuario debe presionar el botón A/Seleccionar para "activar" el control e interactuar con él. Cuando terminen, pueden presionar el botón B/Atrás para desenganchar el control y salir de él.

Captura de foco

La captura de foco es lo que sucede cuando un usuario intenta navegar por la interfaz de usuario de una aplicación, pero se "atrapa" dentro de un control, lo que dificulta o incluso hace imposible moverse fuera de ese control.

En el ejemplo siguiente se muestra la interfaz de usuario que crea la captura de foco.

Si el usuario quiere navegar desde el botón izquierdo hasta el botón derecho, sería lógico suponer que todo lo que tendría que hacer es presionar a la derecha en la cruceta o con el stick izquierdo dos veces. Sin embargo, si el control deslizante no requiere interacción, se produciría el siguiente comportamiento: cuando el usuario presiona a la derecha la primera vez, el foco se desplazaría a Slider, y, cuando presione a la derecha nuevamente, el controlador en Slider se movería a la derecha. El usuario seguiría moviendo la manija a la derecha y no conseguiría alcanzar el botón.

Hay varios enfoques para solucionar este problema. Uno es crear un diseño diferente, similar al ejemplo de la aplicación inmobiliaria en navegación e interacción con foco XY donde reubicamos los botones Anterior y Siguiente encima de ListView. Apilar los controles de forma vertical en lugar de horizontal, como en la imagen a continuación, resolvería el problema.

Ahora el usuario puede navegar a cada uno de los controles presionando hacia arriba y abajo en el D-Pad/palanca izquierda, y cuando Slider tiene el foco, puede presionar a la izquierda y a la derecha para mover la manecilla Slider, según lo previsto.

Otro enfoque para resolver este problema es requerir la participación en Slider. Si establece IsFocusEngagementEnabled="True", se producirá el siguiente comportamiento.

Cuando el Slider requiere enfoque de interacción, el usuario puede acceder al botón de la derecha simplemente presionando dos veces a la derecha en el panel direccional/el stick izquierdo. Esta solución es excelente porque no requiere ningún ajuste de la interfaz de usuario y genera el comportamiento esperado.

Controles de elementos

Aparte del control Slider , hay otros controles que es posible que desee requerir interacción, como:

• ListBox
• ListView
• GridView
• Vista volteada

A diferencia del Slider control, estos controles no interceptan el foco dentro de sí mismos; sin embargo, pueden causar problemas de facilidad de uso cuando contienen grandes cantidades de datos. A continuación se muestra un ejemplo de que ListView contiene una gran cantidad de datos.

Al igual que en el Slider ejemplo, vamos a intentar navegar desde el botón de la parte superior hasta el botón situado en la parte inferior con un controlador para juegos o remoto. A partir del foco en el botón superior, al presionar el panel D/stick se colocará el foco en el primer elemento de ListView ("Elemento 1"). Cuando el usuario vuelve a presionar hacia abajo, el siguiente elemento de la lista obtiene el foco, no el botón de la parte inferior. Para llegar al botón, el usuario debe navegar por todos los elementos del ListView primero. ListView Si contiene una gran cantidad de datos, esto podría ser inconveniente y no una experiencia de usuario óptima.

Para solucionar este problema, establezca la propiedad IsFocusEngagementEnabled="True" en ListView para requerir la implicación en él. Esto permitirá al usuario omitir rápidamente el ListView simplemente presionando hacia abajo. Sin embargo, no podrán desplazarse por la lista ni elegir un elemento de ella, a menos que lo interactúen presionando el botón A/Select cuando tenga el foco y, a continuación, presionando el botón B/Atrás para desconectarse.

ScrollViewer (Visor de desplazamiento)

Ligeramente diferente de estos controles es scrollViewer, que tiene sus propias peculiaridades que se deben tener en cuenta. Si tiene un ScrollViewer con contenido enfocable, de forma predeterminada, navegar a la ScrollViewer le permitirá moverse a través de sus elementos enfocables. Al igual que en un ListView, debe desplazarse por cada elemento para navegar fuera de ScrollViewer.

Si ScrollViewer no tiene contenido enfocable (por ejemplo, si solo contiene texto), puede establecer IsFocusEngagementEnabled="True" para que el usuario pueda interactuar con ScrollViewer mediante el botón A/Seleccionar. Después de haber activado, pueden desplazarse por el texto mediante el stick D-pad/left y, a continuación, presionar el botón B/Atrás para desconectarse cuando hayan terminado.

Otro enfoque sería establecer IsTabStop="True" en el ScrollViewer de manera que el usuario no tenga que interactuar directamente con el control; simplemente puede enfocar en él y luego desplazarse utilizando el pad direccional/palanca izquierda cuando no haya elementos enfocados dentro de ScrollViewer.

Valores predeterminados de enfoque de compromiso

Algunos controles hacen que el bloqueo del foco sea lo suficientemente común como para garantizar que su configuración predeterminada requiera la interacción de foco, mientras que otros tienen la interacción de foco desactivada de forma predeterminada, pero pueden beneficiarse de activarla. En la tabla siguiente se enumeran estos controles y sus comportamientos de interacción de foco predeterminados.

Todos los demás controles de Windows no producirán ningún cambio visual o de comportamiento cuando IsFocusEngagementEnabled="True".

Resumen

Puedes crear aplicaciones de Windows optimizadas para un dispositivo o experiencia específicos, pero la Plataforma universal de Windows también te permite crear aplicaciones que se pueden usar correctamente en todos los dispositivos, tanto en experiencias de 2 pies como de 10 pies, e independientemente de la capacidad del usuario o del dispositivo de entrada. El uso de las recomendaciones de este artículo puede asegurar que tu aplicación sea tan buena como puede ser tanto en el televisor como en un PC.

Artículos relacionados

• Diseño para Xbox y televisión
• Guía de dispositivos para aplicaciones de Windows