Interactions entre le boîtier de commande et la 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 .

Vue d’ensemble

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 les expériences de 2 pieds et de 10 pieds et avec tous les appareils d’entrée (chaque lien vers la section appropriée de cette rubrique).

Fonctionnalité	Description
Navigation et interaction du focus XY	La navigation au focus XY permet à l’utilisateur de naviguer dans l’interface utilisateur de votre application. Toutefois, cela limite l’utilisateur à naviguer vers le haut, vers le bas, vers la gauche et vers la droite. Recommandations pour traiter cette question et d’autres considérations sont décrites dans cette section.
Mode de la souris	La navigation au focus XY n’est pas pratique, voire possible, pour certains types d’applications, comme les cartes ou les applications de dessin et de peinture. Dans ce cas, le mode souris permet aux utilisateurs de naviguer librement avec un boîtier de commande ou un contrôle à distance, comme une souris sur un PC.
Visuel du focus	Le visuel focus est une bordure qui met en surbrillance l’élément d’interface utilisateur actuellement axé. Cela permet à l’utilisateur d’identifier rapidement l’interface utilisateur avec laquelle il navigue ou interagit.
Engagement de focus	L’engagement focus nécessite que l’utilisateur appuie sur le bouton A/Select sur un boîtier de commande ou un contrôle à distance lorsqu’un élément d’interface utilisateur a le focus pour interagir avec celui-ci.
Boutons matériels	Le boîtier de commande et le contrôle à distance fournissent des boutons et des configurations très différents.

Manette de jeu et télécommande

Tout comme le clavier et la souris sont pour PC, et tactile est pour téléphone et tablette, le boîtier de commande et le contrôle à distance sont les principaux périphériques d’entrée pour l’expérience de 10 pieds. Cette section présente les boutons matériels et ce qu’ils font. En mode navigation et interaction avec le focus XY, vous allez apprendre à optimiser votre application lors de l’utilisation de ces appareils d’entrée.

La qualité du boîtier de commande et du comportement à distance que vous obtenez out-of-the-box dépend de la façon dont le clavier est pris en charge 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.

Bouton	Boîtier de commande	Télécommande
Bouton A/Sélectionner	Oui	Oui
Bouton B/Précédent	Oui	Oui
Pavé directionnel (D-pad)	Oui	Oui
Bouton Menu	Oui	Oui
Bouton Afficher	Oui	Oui
Boutons X et Y	Oui	Non
Manche gauche	Oui	Non
Manche droit	Oui	Non
Déclencheurs gauche et droit	Oui	Non
Bosses gauche et droite	Oui	Non
Bouton OneGuide	Non	Oui
Bouton Volume	Non	Oui
Bouton Canal	Non	Oui
Boutons de contrôle multimédia	Non	Oui
Bouton Muet	Non	Oui

Prise en charge du bouton intégré

UWP mappe automatiquement le comportement d’entrée du clavier existant au boîtier de commande et à l’entrée de contrôle à distance. Le tableau suivant répertorie ces mappages intégrés.

Clavier	Boîtier de commande/télécommande
Touches de direction	D-pad (également à gauche sur le boîtier de commande)
Espace	Bouton A/Sélectionner
Entrée	Bouton A/Sélectionner
Caractère d'échappement	Bouton B/Précédent*

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

Interaction	Clavier/souris	Boîtier de commande	Intégré pour :	Recommandé pour :
Page haut/bas	Page haut/bas	Déclencheurs gauche/droit	CalendarView, ListBox, ListViewBase, ListView, ScrollViewerSelector, LoopingSelector, ComboBox, FlipView	Vues qui prennent en charge le défilement vertical
Page gauche/droite	Aucune	Bosses gauche/droite	ListBox, ListViewBase, ListView, ScrollViewerSelector, LoopingSelector, FlipView	Vues qui prennent en charge le défilement horizontal
Faire un zoom avant/arrière	Ctrl +/-	Déclencheurs gauche/droit	Aucune	ScrollViewer, vues qui prennent en charge le zoom avant et arrière
Ouvrir/fermer le volet de navigation	Aucune	Affichage	Aucune	Volets de navigation
Recherche	Aucune	Bouton Y	Aucune	Raccourci vers la fonction de recherche principale dans l’application
Ouvrir le menu contextuel	Cliquez avec le bouton droit sur	Bouton Menu	ContextFlyout	Menu contextuels

Navigation et interaction du focus XY

Si votre application prend en charge la navigation de focus appropriée pour le clavier, cela se traduit bien par le boîtier de commande et le contrôle à distance. 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 le boîtier de commande : ils se KeyDown déclenchent et KeyUp les événements, et ils accèdent uniquement aux 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 focus 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 focus sur le contrôle est en fait plus grand que vous ne le pensez : la navigation XY examine la taille totale du contrôle (ActualWidth et ActualHeight), pas seulement la partie du contrôle qui affiche quelque chose d’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 recréé le contrôle et n’avez pas inclus de visuel de focus. Définissez UseSystemFocusVisuals="True" ou ajoutez manuellement un visuel focus.
• Vous avez déplacé le focus en appelant Focus(FocusState.Pointer). Le paramètre FocusState contrôle ce qui arrive au visuel focus. En règle générale, vous devez définir cette FocusState.Programmaticvaleur sur , ce qui conserve le visuel de 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 l’plateforme Windows universelle tente de s’assurer que la navigation du stick D-pad/left 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 XYFocus* propriété pour la pointer 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 candidat focus suivant est hors 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 accède à droite, le meilleur candidat au focus est Button Quatre. Toutefois, le focus est déplacé vers Button Three, car le parent UserControl force à naviguer là-bas lorsqu’il est hors de son arborescence visuelle.

Chemin d’accès des clics minimum

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 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 au-dessus CommandBar de la liste/grille ? Alors qu’un utilisateur qui a fait défiler la liste ou la grille doit faire défiler vers le haut pour atteindre le CommandBar, il est 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. ContextFlyoutest 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
• Engagement de focus
• Mode de la 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’engagement n’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 la direction de défilement (autrement dit, vers une liste de défilement verticalement ou verticalement vers une liste de défilement 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 l’engagement Focus.

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 navigation de focus XY ne fonctionne pas simplement. 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 du contrôle au contrôle en déplaçant vers le haut, le bas, la gauche et 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 a un WebView contrôle qui utilise le mode souris uniquement lors de l’intérieur du contrôle et la navigation de 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é WhenRequested de sorte que vous activez uniquement le Application.RequiresPointerMode 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 mode simple MapControl qui active le mode souris lorsqu’il est engagé :

<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 plein écran sur son propre Pagecontenu 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.

Visuel du focus

Le visuel focus est la bordure autour de l’élément d’interface utilisateur qui a actuellement le 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 au visuel focus, les développeurs peuvent approuver qu’un seul visuel focus fonctionnera bien sur les PC et Xbox One, ainsi que sur tous les autres appareils Windows qui prennent en charge le clavier et/ou le boîtier de commande/distant.

Bien que le même visuel de focus puisse être utilisé sur différentes plateformes, le contexte dans lequel l’utilisateur rencontre est légèrement différent pour l’expérience 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 du visuel focus

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.

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 ananimant la lumière autour de la bordure des éléments ciblés, révéler le focus donne aux utilisateurs une meilleure compréhension de l’endroit où se concentre et où se concentre.

Révéler le focus est désactivé par défaut. Pour 10 pieds d’expérience, vous devez choisir de révéler le focus en définissant la propriété Application.FocusVisualKind dans votre constructeur d’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 du visuel focus

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 refuser les visuels de focus fournis par le système en dessinant vos propres é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 l’affichage modal ou clair.

Engagement de focus

L’engagement de focus est destiné à faciliter l’utilisation d’un boîtier de commande ou d’une télécommande pour interagir avec une application.

Lorsque la propriété IsFocusEngagementEnabled d’un objet FrameworkElement est définie Truesur , elle marque le contrôle comme nécessitant un engagement 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 l’interface utilisateur qui crée l’interruption 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 à droite la première fois, le focus se déplace vers le Slidercurseur et, lorsqu’il appuie à droite, la poignée de l’utilisateur Sliderse 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’engagement Slider du focus est nécessaire, l’utilisateur peut accéder au bouton sur la droite en appuyant simplement sur la droite sur le stick D-pad/gauche deux fois. 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 que vous souhaiterez peut-être exiger de l’engagement, tels que :

• ListBox
• ListView
• GridView
• FlipView

Contrairement au Slider contrôle, ces contrôles ne interceptent pas eux-mêmes le focus. Toutefois, ils peuvent provoquer des problèmes d’utilisation lorsqu’ils contiennent de grandes quantités de données. Voici un exemple de ListView données 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. À compter du focus sur le bouton supérieur, appuyer sur le pavé D/stick place 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 parcourir chaque élément du ListView premier. Si la ListView quantité de données contient une grande quantité de données, cela peut être gênant et non une expérience utilisateur optimale.

Pour résoudre ce problème, définissez la propriété IsFocusEngagementEnabled="True" sur celle-ci ListView pour exiger l’engagement. Cela permet à l’utilisateur de passer rapidement au-dessus en ListView appuyant simplement sur 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.

ScrollViewer

Légèrement différent de ces contrôles est le ScrollViewer, qui a ses propres bizarres à prendre en compte. Si vous disposez d’un ScrollViewer contenu focusable, par défaut, accédez au ScrollViewer contenu qui vous permet 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 contenu n’est pas focusable( par exemple, s’il contient uniquement du texte), vous pouvez définir IsFocusEngagementEnabled="True" afin que l’utilisateur puisse engager le ScrollViewer contenu à 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 provoquent un piège de focus assez souvent pour justifier leurs paramètres par défaut pour exiger l’engagement de focus, tandis que d’autres ont l’engagement de focus désactivé par défaut, mais peuvent tirer parti de l’activation. Le tableau suivant répertorie ces contrôles et leurs comportements d’engagement de focus par défaut.

Control	Engagement de focus par défaut
CalendarDatePicker	Activé
FlipView	Désactivé
GridView	Désactivé
ListBox	Désactivé
ListView	Désactivé
ScrollViewer	Désactivé
SemanticZoom	Désactivé
Curseur	Activé

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’appareil d’entrée ou de l’utilisateur. 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