Interactions avec manette de jeu et télécommande

De nombreuses expériences d’interaction sont partagées entre le boîtier de commande, le contrôle à distance et le clavier

Créez des expériences d’interaction dans vos applications Windows qui garantissent que votre application est utilisable et accessible via les types d’entrée traditionnels des PC, ordinateurs portables et tablettes (souris, clavier, tactile, etc.), ainsi que les types d’entrée typiques de l’expérience TV et Xbox 10 pieds , comme le boîtier de commande et le contrôle à distance.

Consultez Conception pour Xbox et TV pour obtenir des conseils généraux sur la conception des applications Windows dans l’expérience de 10 pieds .

Aperçu

Dans cette rubrique, nous abordons ce que vous devez prendre en compte dans votre conception d’interaction (ou ce que vous ne faites pas, si la plateforme s’occupe de celle-ci) et fournissez des conseils, des recommandations et des suggestions pour la création d’applications Windows agréables à utiliser, quel que soit le type d’appareil, le type d’entrée ou les capacités et préférences des utilisateurs.

En bas, votre application doit être aussi intuitive et facile à utiliser dans l’environnement de 2 pieds que dans l’environnement de 10 pieds (et vice versa). Prenez en charge les appareils préférés de l’utilisateur, rendez le focus de l’interface utilisateur clair et indémable, organisez le contenu afin que la navigation soit cohérente et prévisible, et donnez aux utilisateurs le chemin le plus court possible pour ce qu’ils veulent faire.

Optimiser pour les expériences de 2 pieds et de 10 pieds

Au minimum, nous vous recommandons de tester vos applications pour vous assurer qu’elles fonctionnent bien dans les scénarios de 2 pieds et de 10 pieds, et que toutes les fonctionnalités sont détectables et accessibles au boîtier de commande Xbox et à distance.

Voici d’autres façons d’optimiser votre application pour une utilisation dans une configuration à 2 pieds et à 10 pieds et avec tous les appareils d’entrée (chacun renvoie à la section appropriée de cette rubrique).

Manette et télécommande

Tout comme le clavier et la souris le sont pour le PC, et l'écran tactile l'est pour les téléphones et les tablettes, la manette de jeu et la télécommande sont les principaux périphériques d’entrée pour l’expérience à 10 pieds. Cette section présente les boutons matériels et ce qu’ils font. En navigation et interaction avec le focus XY et en mode Souris, vous allez apprendre à optimiser votre application lors de l’utilisation de ces appareils d’entrée.

La qualité de la manette et du comportement de la télécommande que vous obtenez prêt à l'emploi dépend de la qualité de la prise en charge du clavier dans votre application. Un bon moyen de s’assurer que votre application fonctionne bien avec le boîtier de commande/la télécommande est de s’assurer qu’elle fonctionne bien avec le clavier sur PC, puis de tester avec le boîtier de commande/remote pour trouver des points faibles dans votre interface utilisateur.

Boutons matériels

Tout au long de ce document, les boutons sont référencés par les noms indiqués dans le diagramme suivant.

Comme vous pouvez le voir dans le diagramme, certains boutons sont pris en charge sur le boîtier de commande qui ne sont pas pris en charge sur le contrôle à distance, et inversement. Bien que vous puissiez utiliser des boutons pris en charge uniquement sur un appareil d’entrée pour accélérer la navigation dans l’interface utilisateur, sachez que l’utilisation de ces boutons pour les interactions critiques peut créer une situation où l’utilisateur ne peut pas interagir avec certaines parties de l’interface utilisateur.

Le tableau suivant répertorie tous les boutons matériels pris en charge par les applications Windows et l’appareil d’entrée qui les prend en charge.

Prise en charge de boutons intégrés

UWP mappe automatiquement le comportement d'entrée du clavier existant à la manette de jeu et à la télécommande. Le tableau suivant répertorie ces mappages intégrés.

*Lorsque ni les événements KeyDown ni KeyUp pour le bouton B ne sont gérés par l’application, l’événement SystemNavigationManager.BackRequested est déclenché, ce qui doit entraîner une navigation arrière dans l’application. Toutefois, vous devez implémenter cela vous-même, comme dans l’extrait de code suivant :

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

Les applications Windows sur Xbox One prennent également en charge l’appui sur le bouton Menu pour ouvrir les menus contextuels. Pour plus d’informations, consultez CommandBar et ContextFlyout.

Prise en charge de l’accélérateur

Les boutons accélérateurs sont des boutons qui peuvent être utilisés pour accélérer la navigation via une interface utilisateur. Toutefois, ces boutons peuvent être uniques à un appareil d’entrée donné. N’oubliez pas que tous les utilisateurs ne pourront pas utiliser ces fonctions. En fait, le boîtier de commande est actuellement le seul appareil d’entrée qui prend en charge les fonctions accélérateurs pour les applications Windows sur Xbox One.

Le tableau suivant répertorie la prise en charge de l’accélérateur intégrée à UWP, ainsi que celle que vous pouvez implémenter par vous-même. Utilisez ces comportements dans votre interface utilisateur personnalisée pour offrir une expérience utilisateur cohérente et conviviale.

Navigation et interaction du focus XY

Si votre application prend en charge la navigation du focus appropriée pour le clavier, cela se traduit bien avec la manette de jeu et la télécommande. La navigation avec les touches de direction est mappée au pavé D (ainsi que le stick gauche sur le boîtier de commande) et l’interaction avec les éléments d’interface utilisateur est mappée à la touche Entrée/Select (voir Boîtier de commande et contrôle à distance).

De nombreux événements et propriétés sont utilisés par le clavier et la manette de jeu : les événements KeyDown et KeyUp se déclenchent, et ils ne naviguent que vers les contrôles qui ont les propriétés IsTabStop="True" et Visibility="Visible". Pour obtenir des conseils sur la conception du clavier, consultez interactions clavier.

Si la prise en charge du clavier est correctement implémentée, votre application fonctionne raisonnablement bien ; Toutefois, il peut y avoir un travail supplémentaire nécessaire pour prendre en charge chaque scénario. Réfléchissez aux besoins spécifiques de votre application pour offrir la meilleure expérience utilisateur possible.

Problèmes de mise au point de débogage

La méthode FocusManager.GetFocusedElement vous indique l’élément qui a actuellement le focus. Cela est utile pour les situations où l’emplacement du visuel focus peut ne pas être évident. Vous pouvez enregistrer ces informations dans la fenêtre de sortie de Visual Studio comme suit :

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

Il existe trois raisons courantes pour lesquelles la navigation XY peut ne pas fonctionner comme prévu :

• La propriété IsTabStop ou Visibility est incorrecte.
• Le contrôle recevant le focus est vraiment plus grand que vous le pensez : la navigation par XY examine la taille totale du contrôle (ActualWidth et ActualHeight), pas seulement la partie du contrôle qui affiche un élément intéressant.
• Un contrôle focusable se trouve au-dessus d’une autre : la navigation XY ne prend pas en charge les contrôles qui se chevauchent.

Si la navigation XY ne fonctionne toujours pas comme prévu après la résolution de ces problèmes, vous pouvez pointer manuellement vers l’élément que vous souhaitez concentrer à l’aide de la méthode décrite dans Substitution de la navigation par défaut.

Si la navigation XY fonctionne comme prévu, mais qu’aucun visuel de focus n’est affiché, l’un des problèmes suivants peut être la cause :

• Vous avez réinitialisé le modèle du contrôle et n'avez pas inclus de visuel de mise au point. Définissez UseSystemFocusVisuals="True" ou ajoutez manuellement un visuel de mise au point.
• Vous avez déplacé le focus en appelant Focus(FocusState.Pointer). Le paramètre FocusState contrôle ce qui arrive à l'indicateur de focus. En règle générale, vous devez définir cette valeur sur FocusState.Programmatic, ce qui conserve le focus visible s’il était visible avant, et masqué s’il était masqué avant.

Le reste de cette section décrit en détail les défis courants liés à la conception lors de l’utilisation de la navigation XY et offre plusieurs façons de les résoudre.

Interface utilisateur inaccessible

Étant donné que la navigation au focus XY limite l’utilisateur à monter, descendre, gauche et droite, vous pouvez finir par des scénarios où certaines parties de l’interface utilisateur sont inaccessibles. Le diagramme suivant illustre un exemple du type de disposition de l’interface utilisateur que la navigation au focus XY ne prend pas en charge. Notez que l’élément au milieu n’est pas accessible à l’aide du boîtier de commande/distant, car la navigation verticale et horizontale sera hiérarchisée et l’élément central ne sera jamais suffisamment prioritaire pour se concentrer.

Si, pour une raison quelconque, la réorganisation de l’interface utilisateur n’est pas possible, utilisez l’une des techniques décrites dans la section suivante pour remplacer le comportement de focus par défaut.

Substitution de la navigation par défaut

Bien que la plateforme Windows universelle tente de s’assurer que la navigation en stick D-pad/gauche est logique pour l’utilisateur, elle ne peut pas garantir le comportement optimisé pour les intentions de votre application. La meilleure façon de s’assurer que la navigation est optimisée pour votre application consiste à la tester avec un boîtier de commande et à confirmer que chaque élément d’interface utilisateur est accessible par l’utilisateur de manière logique pour les scénarios de votre application. Si les scénarios de votre application appellent un comportement non obtenu via la navigation de focus XY fournie, envisagez de suivre les recommandations des sections suivantes et/ou de remplacer le comportement pour placer le focus sur un élément logique.

L’extrait de code suivant montre comment vous pouvez remplacer le comportement de navigation du focus 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>

Dans ce cas, lorsque le focus se trouve sur le Home bouton et que l’utilisateur accède à gauche, le focus se déplace vers le MyBtnLeft bouton ; si l’utilisateur accède à droite, le focus se déplace vers le MyBtnRight bouton, et ainsi de suite.

Pour empêcher le focus de passer d’un contrôle dans une certaine direction, utilisez la propriété XYFocus* pour la diriger vers le même contrôle :

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

À l’aide de ces XYFocus propriétés, un parent de contrôle peut également forcer la navigation de ses enfants lorsque le prochain candidat au focus est en dehors de son arborescence visuelle, sauf si l’enfant qui a le focus utilise la même XYFocus propriété.

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

Dans l’exemple ci-dessus, si le focus est sur Button Deux et que l'utilisateur déplace le curseur vers la droite, le meilleur candidat au focus est Button Quatre. Toutefois, le focus est déplacé vers Button Trois, car le parent UserControl oblige à y naviguer lorsqu'il est hors de son arborescence visuelle.

Chemin avec le moins de clics

Essayez d’autoriser l’utilisateur à effectuer les tâches les plus courantes dans le nombre minimum de clics. Dans l’exemple suivant, TextBlock est placé entre le bouton Lecture (qui obtient initialement le focus) et un élément couramment utilisé, afin qu’un élément inutile soit placé entre les tâches prioritaires.

Dans l’exemple suivant, textBlock est placé au-dessus du bouton Lecture à la place. Réorganisez simplement l’interface utilisateur afin que les éléments inutiles ne soient pas placés entre les tâches prioritaires améliore considérablement la facilité d’utilisation de votre application.

CommandBar et ContextFlyout

Lorsque vous utilisez une barre de commandes, gardez à l’esprit le problème de défilement d’une liste, comme indiqué dans Problème : éléments d’interface utilisateur situés après une longue liste de défilement/grille. L'image suivante montre une disposition d'interface utilisateur avec le CommandBar en bas d'une liste/grille. L’utilisateur doit faire défiler tout le chemin vers le bas jusqu’à la liste/grille pour atteindre le CommandBar.

Que se passe-t-il si vous placez CommandBar de la liste/grille ? Alors qu’un utilisateur qui a fait défiler la liste ou la grille doit revenir en arrière pour atteindre le CommandBar, cela nécessite légèrement moins de navigation que la configuration précédente. Notez que cela suppose que le focus initial de votre application est placé en regard ou au-dessus du CommandBar; cette approche ne fonctionnera pas aussi bien si le focus initial se trouve sous la liste/grille. Si ces CommandBar éléments sont des éléments d’action globaux qui n’ont pas besoin d’être consultés très souvent (comme un bouton Synchroniser ), il peut être acceptable de les avoir au-dessus de la liste/grille.

Bien que vous ne puissiez pas empiler les CommandBaréléments verticalement, les placer sur la direction de défilement (par exemple, à gauche ou à droite d’une liste de défilement verticalement, ou en haut ou en bas d’une liste de défilement horizontalement) est une autre option que vous pouvez envisager si elle fonctionne correctement pour votre disposition d’interface utilisateur.

Si votre application a une CommandBar dont les éléments doivent être facilement accessibles par les utilisateurs, vous pouvez envisager de placer ces éléments à l’intérieur d’un ContextFlyout et de les supprimer du CommandBar. ContextFlyout est une propriété d’UIElement et est le menu contextuel associé à cet élément. Sur PC, lorsque vous cliquez avec le bouton droit sur un élément avec un ContextFlyoutmenu contextuel s’affiche. Sur Xbox One, cela se produit lorsque vous appuyez sur le bouton Menu pendant que le focus est sur un tel élément.

Défis liés à la disposition de l’interface utilisateur

Certaines dispositions de l’interface utilisateur sont plus difficiles en raison de la nature de la navigation au focus XY et doivent être évaluées au cas par cas. Bien qu’il n’y ait pas de méthode « appropriée » unique et que la solution que vous choisissez correspond aux besoins spécifiques de votre application, il existe certaines techniques que vous pouvez utiliser pour faire une grande expérience tv.

Pour mieux comprendre cela, examinons une application imaginaire qui illustre certains de ces problèmes et techniques pour les surmonter.

Voici une application imaginaire d’immobilier qui affiche une liste de maisons disponibles à vendre, une carte, une description d’une propriété et d’autres informations. Cette application pose trois défis que vous pouvez surmonter à l’aide des techniques suivantes :

• Réorganiser l’interface utilisateur
• Concentration de l'engagement
• Mode souris

Problème : éléments d’interface utilisateur situés après une longue liste de défilement/grille

ListView des propriétés affichées dans l’image suivante est une liste de défilement très longue. Si l’engagementn’est pas obligatoire sur le ListView, lorsque l’utilisateur accède à la liste, le focus est placé sur le premier élément de la liste. Pour que l’utilisateur atteigne le bouton Précédent ou Suivant , il doit parcourir tous les éléments de la liste. Dans les cas comme celui où l’utilisateur doit parcourir toute la liste est douloureux, c’est-à-dire lorsque la liste n’est pas suffisamment courte pour que cette expérience soit acceptable, vous pouvez envisager d’autres options.

Solutions

Réorganiser l’interface utilisateur

Sauf si votre focus initial est placé en bas de la page, les éléments d’interface utilisateur placés au-dessus d’une longue liste de défilement sont généralement plus facilement accessibles que s’ils sont placés ci-dessous. Si cette nouvelle disposition fonctionne pour d’autres appareils, la modification de la disposition pour toutes les familles d’appareils au lieu d’effectuer des modifications spéciales de l’interface utilisateur uniquement pour Xbox One peut être une approche moins coûteuse. En outre, placer les éléments d'interface utilisateur dans le sens contraire à la direction de défilement (c'est-à-dire horizontalement par rapport à une liste défilant verticalement, ou verticalement par rapport à une liste défilant horizontalement) permettra une meilleure accessibilité.

Engagement de focus

Lorsque l’engagement est nécessaire, l’ensemble ListView devient une cible de focus unique. L’utilisateur pourra contourner le contenu de la liste pour accéder à l’élément focusable suivant. En savoir plus sur les contrôles qui prennent en charge l’engagement et comment les utiliser dans Focus engagement.

Application immobilière : définir l’engagement comme requis pour qu'un seul clic suffise à atteindre les boutons Précédent/Suivant

Problème : ScrollViewer sans éléments focusables

Étant donné que la navigation au focus XY s’appuie sur la navigation vers un élément d’interface utilisateur focusable à la fois, un ScrollViewer qui ne contient aucun élément focusable (tel qu’un seul avec un seul texte, comme dans cet exemple) peut entraîner un scénario où l’utilisateur ne peut pas afficher tout le contenu dans le ScrollViewer. Pour obtenir des solutions à ce sujet et à d’autres scénarios connexes, consultez Focus engagement.

Problème : interface utilisateur de défilement libre

Lorsque votre application nécessite une interface utilisateur de défilement libre, telle qu'une surface de dessin ou, dans cet exemple, une carte, la navigation par focus XY ne fonctionne tout simplement pas. Dans ce cas, vous pouvez activer le mode souris pour permettre à l’utilisateur de naviguer librement à l’intérieur d’un élément d’interface utilisateur.

Mode de la souris

Comme décrit dans la navigation et l’interaction du focus XY, sur Xbox One, le focus est déplacé à l’aide d’un système de navigation XY, ce qui permet à l’utilisateur de déplacer le focus d'un contrôle à un autre en se déplaçant vers le haut, le bas, la gauche ou la droite. Toutefois, certains contrôles, tels que WebView et MapControl, nécessitent une interaction semblable à la souris où les utilisateurs peuvent déplacer librement le pointeur à l’intérieur des limites du contrôle. Il existe également certaines applications où il est judicieux pour l’utilisateur de pouvoir déplacer le pointeur sur toute la page, en ayant une expérience avec le boîtier de commande/remote similaire à ce que les utilisateurs peuvent trouver sur un PC avec une souris.

Pour ces scénarios, vous devez demander un pointeur (mode souris) pour l’intégralité de la page ou sur un contrôle à l’intérieur d’une page. Par exemple, votre application peut avoir une page qui possède un WebView contrôle utilisant le mode souris uniquement lorsqu'on est à l'intérieur du contrôle, et la navigation au focus XY partout ailleurs. Pour demander un pointeur, vous pouvez spécifier si vous le souhaitez lorsqu’un contrôle ou une page est engagé ou lorsqu’une page a le focus.

Pour les applications web XAML et hébergées s’exécutant sur Xbox One, le mode souris est activé par défaut pour l’ensemble de l’application. Il est vivement recommandé de désactiver cette fonctionnalité et d’optimiser votre application pour la navigation XY. Pour ce faire, définissez la propriété Application.RequiresPointerMode de sorte que vous activez uniquement le WhenRequested mode souris lorsqu’un contrôle ou une page l’appelle.

Pour ce faire dans une application XAML, utilisez le code suivant dans votre App classe :

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

Pour plus d’informations, notamment l’exemple de code pour HTML/JavaScript, consultez Comment désactiver le mode souris.

Le diagramme suivant montre les mappages de boutons pour le boîtier de commande/la télécommande en mode souris.

Utilisez la propriété RequiresPointer sur un contrôle ou une page pour activer le mode souris sur celui-ci. Cette propriété a trois valeurs possibles : Never (la valeur par défaut), WhenEngagedet WhenFocused.

Activation du mode souris sur un contrôle

Lorsque l’utilisateur engage un contrôle avec RequiresPointer="WhenEngaged", le mode souris est activé sur le contrôle jusqu’à ce que l’utilisateur le désactive. L’extrait de code suivant illustre un simple MapControl qui active le mode souris lorsqu'il est enclenché :

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

Lorsqu’un contrôle est en mode souris, ses contrôles imbriqués sont également en mode souris. Le mode demandé de ses enfants sera ignoré : il est impossible qu’un parent soit en mode souris, mais qu’un enfant ne le soit pas.

En outre, le mode demandé d’un contrôle est inspecté uniquement lorsqu’il obtient le focus, de sorte que le mode ne change pas dynamiquement pendant qu’il a le focus.

Activation du mode souris sur une page

Lorsqu’une page a la propriété RequiresPointer="WhenFocused", le mode souris est activé pour toute la page lorsqu’elle obtient le focus. L’extrait de code suivant illustre l’attribution d’une page à cette propriété :

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

Désactivation du mode souris pour le contenu plein écran

En règle générale, lors de l’affichage de vidéos ou d’autres types de contenu en plein écran, vous souhaiterez masquer le curseur, car il peut distraire l’utilisateur. Ce scénario se produit lorsque le reste de l’application utilise le mode souris, mais que vous souhaitez le désactiver lors de l’affichage du contenu plein écran. Pour ce faire, placez le contenu en plein écran sur son propre Page, et suivez les étapes ci-dessous.

1. Dans l’objet App , définissez RequiresPointerMode="WhenRequested".
2. Dans chaque Page objet , à l’exception de l’écran Pagecomplet , définissez RequiresPointer="WhenFocused".
3. Pour l’écran Pagecomplet, définissez RequiresPointer="Never".

De cette façon, le curseur n’apparaît jamais lors de l’affichage du contenu plein écran.

Mise au point visuelle

L'indicateur de focus est la bordure autour de l’élément d’interface utilisateur qui est actuellement en focus. Cela permet d’orienter l’utilisateur afin qu’il puisse facilement naviguer dans votre interface utilisateur sans se perdre.

Avec une mise à jour visuelle et de nombreuses options de personnalisation ajoutées à l'élément visuel de mise au point, les développeurs peuvent être sûrs qu'un seul élément visuel de mise au point fonctionnera bien sur les PC et Xbox One, ainsi que sur tous les autres appareils Windows qui prennent en charge le clavier et/ou la télécommande.

Bien que le même visuel de focus puisse être utilisé sur différentes plateformes, le contexte dans lequel l’utilisateur rencontre le visuel est légèrement différent pour l’interface utilisateur de 10 pieds. Vous devez supposer que l’utilisateur ne porte pas entièrement attention à l’écran de télévision entier, et par conséquent, il est important que l’élément actuellement concentré soit clairement visible pour l’utilisateur à tout moment afin d’éviter la frustration de la recherche du visuel.

Il est également important de garder à l’esprit que le visuel focus est affiché par défaut lors de l’utilisation d’un boîtier de commande ou d’un contrôle à distance, mais pas d’un clavier. Ainsi, même si vous ne l’implémentez pas, il apparaît lorsque vous exécutez votre application sur Xbox One.

Positionnement initial de la représentation de mise au point

Lors du lancement d’une application ou de la navigation vers une page, placez le focus sur un élément d’interface utilisateur qui est logique comme premier élément sur lequel l’utilisateur prendra des mesures. Par exemple, une application photo peut placer le focus sur le premier élément de la galerie, et une application musicale a accédé à une vue détaillée d’une chanson peut placer le focus sur le bouton de lecture pour faciliter la lecture de la musique.

Essayez de placer le focus initial dans la région supérieure gauche de votre application (ou en haut à droite pour un flux de droite à gauche). La plupart des utilisateurs ont tendance à se concentrer sur ce coin en premier, car c’est là que le flux de contenu de l’application commence généralement.

Rendre le focus clairement visible

Un visuel de focus doit toujours être visible sur l’écran afin que l’utilisateur puisse reprendre là où il s’est arrêté sans rechercher le focus. De même, il doit y avoir un élément focusable à l’écran à tout moment, par exemple, n’utilisez pas de fenêtres contextuelles avec uniquement du texte et aucun élément focusable.

Une exception à cette règle concernerait des expériences en plein écran, telles que l’observation de vidéos ou l’affichage d’images, auquel cas il ne serait pas approprié d’afficher le visuel de focus.

Effet Révéler focus

Révéler le focus est un effet d’éclairage qui anime la bordure des éléments focusables, tels qu’un bouton, lorsque l’utilisateur déplace le boîtier de commande ou le focus clavier vers eux. En animant la lueur autour de la bordure des éléments ciblés, Reveal focus offre aux utilisateurs une meilleure compréhension de la position actuelle du focus et de sa direction.

La fonctionnalité de mise au point est désactivée par défaut. Pour une expérience utilisateur à distance de 10 pieds, optez pour révéler le focus en définissant la propriété Application.FocusVisualKind dans le constructeur de votre application.

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

Pour plus d’informations, consultez les instructions pour révéler le focus.

Personnalisation de la mise au point visuelle

Si vous souhaitez personnaliser le visuel focus, vous pouvez le faire en modifiant les propriétés associées au visuel de focus pour chaque contrôle. Il existe plusieurs propriétés de ce type que vous pouvez tirer parti de la personnalisation de votre application.

Vous pouvez même ne pas utiliser les visuels de focus fournis par le système en créant les vôtres à l'aide d'états visuels. Pour en savoir plus, consultez VisualState.

Superposition d’arrière-plan clair

Pour appeler l’attention de l’utilisateur aux éléments de l’interface utilisateur que l’utilisateur manipule actuellement avec le contrôleur de jeu ou le contrôle à distance, UWP ajoute automatiquement une couche « fumée » qui couvre les zones en dehors de l’interface utilisateur contextuelle lorsque l’application s’exécute sur Xbox One. Cela ne nécessite aucun travail supplémentaire, mais c’est quelque chose à garder à l’esprit lors de la conception de votre interface utilisateur. Vous pouvez définir la LightDismissOverlayMode propriété sur n’importe quelle FlyoutBase option pour activer ou désactiver la couche de fumée ; par défaut Auto, ce qui signifie qu’elle est activée sur Xbox et désactivée ailleurs. Pour plus d’informations, consultez Modal vs light dismiss.

Accent sur l'engagement des utilisateurs

L’engagement de concentration est destiné à faciliter l’utilisation d’une manette de jeu ou d’une télécommande pour interagir avec une application.

Lorsque la propriété IsFocusEngagementEnabled d’un objet FrameworkElement est définie sur True, elle marque le contrôle comme nécessitant une prise de focus. Cela signifie que l’utilisateur doit appuyer sur le bouton A/Select pour « engager » le contrôle et interagir avec lui. Lorsqu’ils sont terminés, ils peuvent appuyer sur le bouton B/Précédent pour désengager le contrôle et sortir de celui-ci.

Piégeage du focus

Le piège de focus est ce qui se passe lorsqu’un utilisateur tente de naviguer dans l’interface utilisateur d’une application, mais devient « piégé » dans un contrôle, ce qui rend difficile ou même impossible de se déplacer en dehors de ce contrôle.

L'exemple suivant montre une interface utilisateur qui permet de créer la capture du focus.

Si l’utilisateur souhaite naviguer du bouton gauche au bouton droit, il serait logique de supposer que tout ce qu’il aurait à faire est d’appuyer à droite sur le stick D-pad/gauche deux fois. Toutefois, si le curseur ne nécessite pas d’engagement, le comportement suivant se produit : lorsque l’utilisateur appuie une première fois sur la touche droite, le focus se déplace vers le Slider, et lorsqu’il appuie à nouveau, la poignée du Slider se déplace vers la droite. L’utilisateur continuerait à déplacer la poignée à droite et ne serait pas en mesure d’accéder au bouton.

Il existe plusieurs approches pour contourner ce problème. Il s’agit de concevoir une disposition différente, similaire à l’exemple d’application immobilière dans la navigation et l’interaction de focus XY où nous avons déplacé les boutons Précédent et Suivant au-dessus de la ListView. L’empilement des contrôles verticalement plutôt que horizontalement comme dans l’image suivante résout le problème.

À présent, l’utilisateur peut accéder à chacun des contrôles en appuyant vers le haut et le bas sur le stick D-pad/gauche, et lorsque le Slider focus est activé, il peut appuyer sur gauche et droite pour déplacer la Slider poignée, comme prévu.

Une autre approche pour résoudre ce problème est d’exiger l’engagement sur le Slider. Si vous définissez IsFocusEngagementEnabled="True", cela entraîne le comportement suivant.

Lorsque l'interaction Slider nécessite une attention particulière, l'utilisateur peut accéder au bouton à droite en appuyant simplement deux fois sur la droite du D-pad ou du stick gauche. Cette solution est excellente, car elle ne nécessite aucun ajustement de l’interface utilisateur et produit le comportement attendu.

Contrôles d’éléments

Outre le contrôle Slider, il existe d’autres contrôles pour lesquels vous souhaiterez peut-être prévoir une interaction, tels que :

• ListBox
• ListView
• GridView
• FlipView

Contrairement au Slider contrôle, ces contrôles ne piègent pas le focus. Toutefois, ils peuvent entraîner des problèmes d'ergonomie lorsqu’ils contiennent de grandes quantités de données. Voici un exemple de ListView qui contient une grande quantité de données.

À l’instar de l’exemple Slider , essayons de naviguer du bouton en haut vers le bouton en bas avec un boîtier de commande/une télécommande. À partir du focus sur le bouton supérieur, appuyer sur le pavé directionnel/stick déplacera le focus sur le premier élément de l’élément ListView (« Élément 1 »). Lorsque l’utilisateur appuie de nouveau sur le bas, l’élément suivant de la liste se concentre, et non le bouton situé en bas. Pour accéder au bouton, l’utilisateur doit d'abord parcourir chaque élément du ListView. Si ListView contient une grande quantité de données, cela peut être gênant et ne pas offrir une expérience utilisateur optimale.

Pour résoudre ce problème, définissez la propriété IsFocusEngagementEnabled="True" sur le ListView pour exiger une interaction. Cela permettra à l'utilisateur d'ignorer rapidement ListView en appuyant simplement sur la flèche vers le bas. Toutefois, ils ne pourront pas faire défiler la liste ou choisir un élément à partir de celui-ci, sauf s’ils l’engagent en appuyant sur le bouton A/Select lorsqu’il a le focus, puis en appuyant sur le bouton B/Précédent pour désengager.

Défilement

Légèrement différent de ces contrôles, le ScrollViewer a ses propres particularités à prendre en compte. Si vous avez un ScrollViewer avec du contenu focusable, par défaut, naviguer vers le ScrollViewer vous permettra de parcourir ses éléments focusables. Comme dans un ListView, vous devez parcourir chaque élément pour naviguer en dehors du ScrollViewer.

Si le ScrollViewer n’a aucun contenu focalisable—par exemple, s’il ne contient que du texte—vous pouvez configurer IsFocusEngagementEnabled="True" pour que l’utilisateur puisse interagir avec le ScrollViewer à l’aide du bouton A/Select. Une fois qu’ils se sont engagés, ils peuvent faire défiler le texte à l’aide du stick D-pad/gauche, puis appuyer sur le bouton B/Précédent pour se désengager lorsqu’ils sont terminés.

Une autre approche consisterait à définir IsTabStop="True" sur le ScrollViewer point de sorte que l’utilisateur n’ait pas à engager le contrôle , il peut simplement placer le focus sur celui-ci, puis faire défiler à l’aide du stick D-pad/gauche lorsqu’il n’y a pas d’éléments focusables dans le ScrollViewer.

Valeurs par défaut de l’engagement de focus

Certains contrôles retiennent le focus assez souvent pour justifier que leurs paramètres par défaut nécessitent l’activation du focus, tandis que d’autres ont l’activation du focus désactivée par défaut, mais peuvent tirer parti de son activation. Le tableau suivant répertorie ces contrôles et leurs comportements d’engagement de focus par défaut.

Tous les autres contrôles Windows n’entraînent aucune modification comportementale ou visuelle quand IsFocusEngagementEnabled="True".

Résumé

Vous pouvez créer des applications Windows optimisées pour un appareil ou une expérience spécifique, mais la plateforme Windows universelle vous permet également de créer des applications qui peuvent être utilisées avec succès sur les appareils, dans les expériences de 2 pieds et de 10 pieds, et indépendamment de la capacité de l’utilisateur ou de l’appareil d’entrée. L’utilisation des recommandations de cet article peut vous assurer que votre application est aussi bonne que sur la télévision et sur un PC.

Articles connexes

• Conception pour Xbox et TV
• Primeur d’appareil pour les applications Windows